Tuesday, July 15, 2014

You already know what the most common way of getting a job is. You usually look for vacancies in a job web portal and when you think you could be selected, you apply for it... Then, most of the companies look at your resume and start reading about your previous experience and your studies...

But if you are looking at getting a new job in the security field, take a moment to look around before sending your resume... Maybe the company is giving you an advantage against the other candidates and you have no idea about it.

Have you looked at the web code source?

Yes, you have read well. Maybe you are using a well known security scanner and maybe you would like to work for them. You should research the company a little bit more. For example, visit their website and look at their web code source... Sometimes you have some surprises as you can see in the picture bellow...

Looking at your network traffic

Here, another real example... While I was studying in order to improve my technical skills, I found a hint in the PCAP network capture by using Wireshark... I never would have imagined that I could find a new job by reading a network traffic capture...


Looking into the HTTP headers

What we really discovered before was that the company changed the HTTP header in order to show you a "secret" message. So, instead of getting a traffic capture to read the "secret" message, we could use wget to try to look for a new oportunity.

wget -S example.com -O /dev/null


Looking for a job in Shodan

You already know that Shodan grab and index the HTTP headers they scan... So we can get a lot of results as the previous one by using Shodan.

Here, more examples....

http://www.shodanhq.com/search?q=x-hacker+work


http://www.shodanhq.com/search?q=x-hacker+job


http://www.shodanhq.com/search?q=hiring



Posted on Tuesday, July 15, 2014 by Javier Nieto

No comments

Tuesday, July 01, 2014

Introduction

In this post I'd like to introduce you to an awesome tool focused on taking advantage of an OpenSSH vulnerability. I'd like to thank @cor3dump3d for letting me participate in his project. Before starting, just a brief introduction...

OpenSSH is a well-known tool to remotely manage *nix systems. It has replaced to telnet, rlogin, and ftp. Using these tools, the data (even passwords) is transmitted across the network unencrypted. OpenSSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other attacks... But will not eliminate all kinds of attacks, for example, the OpenSSH User Enumeration Time-Based Attack. Osueta has been developed to take advantage of that OpenSSH bug and offers us a way to improve our Brute Force attacks against an OpenSSH server.

In a Brute Force attack, we try different usernames and passwords in combination until the attack is successful. It is successful when we get access to the system by using the credentials guessed.  So, we need to know two fields to be authenticated on a OpenSSH server: Username and Password.

Thanks to Osueta, we are able to guess the usernames available on the OpenSSH server. So if the usernames have been guessed, we have 50% of the credentials and the time needed to perform the Brute Force attack (by using Username Password combinations) will be reduced because we already know the username.

How does this bug work?

With the scenarios below, I will show you how this attack works. When we want to connect to an OpenSSH server, we need to type a username and password.
 
Scenario 1

If the username doesn't exist, the password is not compared to the original one.

Scenario 2

If the username exists, the password is compared with the original one. If the hash compared is the same, you are granted access to the system. If not, you are rejected.

Scenario 3

If the username exists and the password typed is for example 40.000 A's (40000 bytes), the fact of generating the hash of this long password in order to compare it with the original one, makes the system slow down and the time measurement is increased. So if the delay is increased when we use this long password, the username exists.

The picture below shows the performance of my computer when I tried an invalid username:


And now, that is the performance while it was being tested with a valid username and a password of 40000 bytes:


Find more info about this bug OpenSSH User Enumeration Time-Based Attack  

Notice that OpenSSH 5.* 6.* servers are affected...

Working with Osueta

Ok. We have learned a little bit more from this bug and now it is the time to take advantage of it.

Before starting, we need to install the packages below:

# apt-get install python-ipy python-nmap python-paramiko

Then, we can download Osueta from Github:

$ git clone https://github.com/c0r3dump3d/osueta.git

Notice the first thing Osueta does when it is executed, is to test 10 random users to check the server delay in order to know how much time we can expect to wait (in normal conditions) until a reply is received  from the server. Osueta establishes a rate limit and if it is exceeded, the user exits.

Example 1. Guessing if a single user if it is available.

./osueta.py -H 127.0.0.1 -U jnieto -p 22



Example 2. Guessing usernames from a list.

./osueta.py -H 127.0.0.1 -L users.txt -p 22



Example 3. Trying a DOS of the OpenSSH service. Notice you need to know or to guess a username to perform a DOS attack.

./osueta.py -H 127.0.0.1 -p 22 -U jnieto -v no --dos yes


You can see the result of this attack in the picture below... The CPU is up to 100% and there are a lot of connections to the OpenSSH server.


When the number of sessions is reached, the machine starts to reject the rest of connections causing a DOS.



Posted on Tuesday, July 01, 2014 by Javier Nieto

3 comments