Parsero v0.75 has been included in the Kali Linux repository

Some days ago a friend told me, "Ey! Why you didn't write a post talking about how Parsero has been included in the Kali Linux repository?" "Seriously? I forgot it..." So here it is...

As you already know, Kali Linux is one of the most advanced and versatile penetration testing distribution ever made. Kali Linux originally started with earlier version of live Linux distribution named BackTrack. It is a GPL-compliant Linux distribution built by penetration testers for penetration tester. With millions of downloads, it has become the most widely adopted penetration testing framework in existence and is used by the security community all over the world.

That is the reason why I am really proud of announcing that my tool Parsero has been included in the Kali Linux repositories: http://tools.kali.org/information-gathering/parsero

Parsero is a free script written in Python which reads the Robots.txt file of a web server and looks at the Disallow entries. The Disallow entries are the URL path of directories or files hosted on a web server which the administrators don't want to be indexed by crawlers. For example, "Disallow: /portal/login" don't allow to search engines like Google, Bing, Yahoo to index  www.example.com/portal/login  so nobody can locate it by searching on them.

Sometimes these paths typed in the Disallows entries are directly accessible by the users (without using a search engine) just visiting the URL and the Path. Sometimes they are not available to be visited by anybody... Because it is really common that the administrators write a lot of Disallows and some of them are available and some of them are not, you can use Parsero in order to check the HTTP status code of each Disallow entry in order to check automatically if these directories are available or not.

Also, the fact that the administrator write a Robots.txt doesn't mean that the files or directories typed in this file will not be indexed by Bing, Google, Yahoo... For this reason, Parsero is capable of performing searches in Bing to locate content indexed without the web administrator authorization.

Now, you can run Parsero v0.75 directly from this awesome distribution. So, what do you need to use Parsero in Kali Linux?

Installing Parsero in Kali Linux

First of all, you need to execute:

root@kali:~# apt-get update

Then, you can search directly Parsero in the Kali Linux repositories by using the command bellow:

root@kali:~# apt-cache search parsero

Finally run the following command to install it.

root@kali:~# apt-get install parsero

Now you can have fun by checking the directories or files which could have sensitive information and should be "anonymous" to the search engines...

Currently, I'm working on developing the new release which will have another feature. It will be available here: https://github.com/behindthefirewalls/Parsero

Read More

Have I bought these clothes? Another spread malware campaign.

When I was reading one of the last FireEye's post, I was struck by the binary they said it came in the form of phished email (MD5:7c00ba0fcbfee6186994a8988a864385) purportedly from Armani regarding an order. I believe it is interesting to analyze because it could be a real example of an APT or maybe just another spread malware  campaign. The techniques used in this real case, could be used in both scenarios...

But FireEye shared the mail's MD5 checksum and they didn't provide us with a copy of the message. Thanks to the last ContagioDump post, we are able to download all samples and a little more FireEye previously mentioned.

After downloading and opening the message, we can see the details of this mail in the picture bellow. It appears to have been sent by confirmation(at)armani[.]com and contains what appears to be an order with a file attached.

 Analysing the SMTP headers

Before opening the file attached, let's see the mail headers to get deep into who really sent the message.

We can see the IP (which sent the mail) comes from Paris and the WHOIS description tells us that this IP belongs to a "Wifi Address Pool". Maybe it is a free Wifi or a hacked Wifi where the hackers were connected to send the email, or maybe the host which delivered the mail was infected and was connected to this Wifi when the mail was sent...

By reading the mail headers, we can get more information like the mail's hops. Notice the second one has been blacklisted.

If we continue analyzing the headers we can see something weird...

In the pictures above we can see that the X-sender and the Return-Path belong to a hotel mail account. These fields mean:

• X-Sender: Tell us the real sender directly in the message headers. 
• Return-Path: Denotes the real sender but only "post factum".

I've checked that the SMTP servers from which the mail was sent need authorization to send e-mails. Also, the hotel mail account which delivered the mails used the SMTP servers which are hosted in the same hosting provider that the hotel web site is hosted on. So we could assume that this hotel is using these servers to send mail and the mail account could have been stolen. The hackers sent the phished mail from the hotel account but changing the "from" to confirmation(at)armani[.]com

Also we can see that the domain name of the company spoofed doesn't have a SPF record. That means that it is easier to send an email with the "from" faked. A SPF record prevent spammers from sending messages with forged From addresses. Here you can get more valuable info about SPF.

Tricking the end user

After spending some time digging into the SMTP headers to have further information about the sender, is time to focus on the attachment.

It seems an attempt has been made to disguise this file as a PDF file but we noticed that  the extension is actually ".7z". If we unzip the file inside the ".7z" file to our Desktop...

...we see that the icon appears to be a PDF file with a weird extension: "pdf%%". We can't see the .exe extension because the "hide extensions for known file types" option is enabled in our Windows. FireEye said that this this file is using RTLO to trick the user but we can't see this technique in the attachment, at least the extension doesn't change... By using RTLO it would be expected to have an extension "exe.pdf" instead of "pdf.exe" which runs as an application, but the attachment doesn't work in this way in our Windows 7. But it doesn't matter, maybe in my next post I will talk about how easy is using RTLO and icon changing to trick a user into opening a file which appears to be a valid document but it is actually malware. That kind of techniques are really used in really attacks like in Siesta Campaign or others ones used like WinRar File extension spoofing.

I would like to look at the executable before continuing about how the hackers are trying to trick the user. We notice that this executable is signed with a certificate which has been revoked.

This stolen certificate has been used to bypass the security system of so many security software and devices. Some of them, the first check they do is to discover if the executable is signed, and if it is with a valid certificate, no more security actions are made and the executable is allowed to get into the network. Of course, after the company realized this problem, they revoked the certificate...

So, what happens if we execute the file which looks like a PDF file?

While the malware is doing evil actions, a web browser is open with the supposed Armani order.

For security guys, these techniques do not go unnoticed to a trained eye, but we can see how it happens every day to the layman.

Conclusion

Thanks to Fireye and Contagiodump who shared their analysis and samples, we have been able to see how the hacker probably got access to a hotel mail account to start a SPAM campaign and sent a spear phishing attack. They spoofed a mail account of a well know clothes brand. That company doesn't have a SPF record to prevent from being spoofed.

Also, we have observed  how the hacker has tried to disguised the malicious executable as PDF by changing the icon to a PDF picture and maybe using RTLO. Also, after opening the file, a web browser is opened with the apparent order while the malware is doing evil actions.

Moreover, I've been researching a little more about that case and I've found an advertisement in Facebook https://www.facebook.com/Marnaque/posts/491122357681969 which talks about a similar phished mail. Notice that now they are trying to spoof another clothes brand and they are using a similar body mail using the same order number: 0801E376E15829. We can suspect the same guys are behind that...

Read More

Looking for a job in the security field in a different way

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

Read More

OpenSSH User Enumeration Time-Based Attack with Osueta

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.

Read More

XSS-game by Google exercises 4, 5 and 6.

In the previous post we talked about how to resolve the exercises 1, 2 and 3 of the XSS-game proposed by Google. Now, we are going to resolve the latest ones.

Exercise 4

This exercise is similar to the previous one (Exercise 3). The main difference is that now,  we have an input. 

It is expected that a number will be typed into the box, but... what will happen if we write a name instead of typing a number?

What happens is that our string has been included into the "img" tag...

So, if we use:  3');alert('Behindthefirewalls the result would be...

And the alert appears...

Exercise 5

I don't know what the reason for looking at "next=confirm" was at first because logic would dictate that the first attempt would be to try to exploit a XSS vulnerability in the input field...

But the first thing that I did was to replace "confirm" by "http://www.behindthefirewalls", reload the page, type my mail and click on "Next" and the result was that I was redirected to my blog...

https://xss-game.appspot.com/level5/frame/signup?next=http://www.behindthefirewalls.com

We have discovered another security issue but what we want to do is  locate a XSS vulnerability.

I was trying different options with no success so I decided to read the hints offered by Google. "If you want to make clicking a link execute Javascript (without using the onclick handler), how can you do it?"

So I tried to use:

next=javascript:alert("behindthefirewalls")

And the alert appeared.

Exercise 6 

The fourth hit says: "If you can't easily host your own evil JS file, see if google.com/jsapi?callback=foo will help you here."

If we change "foo" for "alert" www.google.com/jsapi?callback=alert will have included in its code:

So, if we use the link bellow, we can exploit the vulnerability.

frame#//www.google.com/jsapi?callback=alert 

I spent some time trying to solve this exercise in a different way. I tried a lot of possibilities to exploit a XSS vulnerability...

... until I remembered a post I read some months ago...

#data:text/javascript,alert('behindthefirewalls')

Read More