Monthly Archives: October 2014

Malicious Documents – Word with VBA and Powershell

E-mail continues to be the weapon of choice for mass delivering malware. The tools and techniques used by attackers  continue to evolve and bypass all the security controls in place. These security controls  could be a simple home based UTM device or a big corporation security infrastructure with all kinds of technology. Social engineering methods, combined with latest encoding and obfuscation techniques allow e-mails to be delivered straight to the end user mailbox. These phishing e-mails attempt to steal confidential data such as credentials using all kinds of deception techniques to lure users to click on links or open documents or give their information. In the last days I came across some of these documents. The below steps describe the mechanism behind one of these documents (MD5: 4a132e0c7a110968d3aeac60c744b05a)  that when opened on Microsoft Office lure the victim to enable macros to view its content. Even with macros disable many users allow the macro to execute. What happens next?

  1. The malicious document contains a VBA macro.
  2. The macro is password protected. The protection can be bypassed using a hex editor and replacing the password hash with a known password hash to see its contents.
  3. When executed the VBA macro writes 3 files on disk. A batch file”ntusersss.bat”, a VBS script “ntuserskk.vbs” and a powershell script “ntusersc.ps1”.
  4. It invokes cmd shell and executes the batch file which calls the VBS script
  5. Microsoft Script Host (cscript.exe) is invoked and the VBS script is executed which calls the powershell script
  6. Power shell script is executed and it downloads the malicious EXE
  7. The malicious file is stored on disk and renamed to crsss2.exe
  8. The trojan is executed and the machine is infected.

The following picture illustrates the previous steps.

feodo-docmechanics

The downloaded malware is very sophisticated and is known to be a variant of the Feodo ebanking trojan (aka Cridex or Bugat). This trojan contains advanced capabilities but the main feature is to steal credentials by performing men in the browser attacks. These credentials are then used to commit ebanking fraud . After execution, the malware contacts the Command and Control server and the machine becomes part of a botnet and starts capturing and stealing confidential data.

Another new document used recently in several phishing campaigns it also uses a VBA macro inside the word document (MD5: f0626f276e0da283a15f414eea413fee). But this time the VBA code is obfuscated. Using the Microsoft macro debugger its possible to execute in a step-by-step fashion and determine what it does. Essentially it downloads a malicious executable file from a compromised website and then it executes it.

feodo-vba

Again, after execution it contacts its Command and Control via HTTP. The computer will be part of a Botnet and it will start to steal credentials and other confidential data.

Below a visual analysis of the malware behavior starting with the Winword execution. This graph was made using ProcDOT which correlates Sysinternals Procmon logfiles with packet captures to create an interactively graph. A great tool created by Christian Wojne from the Austrian CERT. This can be of great help for a faster malware behavior analysis. It is also unbelievable to visualize how complex is malware these days. I will leave a how-to on how to produce these graphs for other blog post.

ProcDot
From a defense perspective, the US-CERT put together excellent tips for detecting and preventing this type of malware and to avoid scams and phishing attempts applicable to home users and corporations. Note that these documents were not detected by the AV engines at the time the phishing campaign was seen. Virustotal was reporting less than 5% detection rate. Even running on a limited privileges user account the attack would still be successful. A key recommendation is to use Enhanced Mitigation Experience Toolkit 5.0 from Microsoft as part of your layered defense.

feodo-emetThis is a free product from Microsoft for the endpoint and will prevent the execution of the attacks described previously and many others. Exploit mitigation technologies do not guarantee that vulnerabilities cannot be exploited. However, they raise the bar and increase the costs for the attacker to make exploitation successful by making it harder to be executed. On a windows 7 SP1 with EMET 5, when opening the documents and running the malicious VBA macros, EMET would prevent its execution.

Email attachments can be dangerous. Use caution with Email attachments!

Tagged , , , , ,

ShellShock – Hands-On

In my previous post I gave an overview about the key events that happened during the week that GNU Bash vulnerability – Shellshock – got disclosed. In this post would like to demonstrate a hand’s on scenario that will allow one to have a better practical understanding on how someone could exploit the Shellshock vulnerability using HTTP requests to CGI scripts.

In order to better understand how this vulnerability can be exploited trough CGI scripts, below a short summary about what is CGI. CGI stands for Common Gateway Interface as formally defined in the RFC 3875. It is a gateway between the Web server and CGI scripts. You can write CGI programs in almost any programming language. The process of viewing a document on the Web starts when a Web browser sends a request to a Web server. The Web browser sends details about itself and the file it is requesting to the Web server in HTTP request headers. The Web server receives and reviews the HTTP request headers for any relevant information, such as the name of the file being requested and sends back the file with HTTP response headers. When a Web browser requests a CGI script in the cgi-bin directory from a Web server, the server knows is it is a CGI script and it executes. All the relevant data sent to the Web server from the Web browser, such as form input, plus the HTTP request headers are sent from the server to the CGI script in either environment variables or by standard input (stdin). This means the Web server makes available  all the HTTP request headers received from the Web browser to the CGI script using environment variables all of which have the HTTP_ prefix. At this states the CGI script takes over, it parses and processes all the information.  When the CGI script completes the execution, it sends the results back fo the Web server. The Web server formats the HTTP response header and returns the data to the Web browser.

shellshock-hands-1

Lets create a short example of a CGI script based on Perl that will pass back to the web browser the HTTP headers that were received trough the usage of CGI envronment variables. This was made on a CentOS machine running Apache has HTTP deamon.

shellshock-hands-code1

The same example can be done in Shell scripting using BASH.

shellshock-hands-code2

Now that we have a CGI bash script we can try out Shellshock!

The vulnerability can be easily exploited by introducing malformed HTTP headers in the request that will be processed by the CGI script as being code.  In the following scenario I have Kali Linux box and a Web Server running CentOS with Apache with mod_cgi enable.  This will be a manual attack in order to have a better practical understanding, however all this can be automated.

First we make a HTTP request to the Web Server CGI script bash.cgi using NetCat. The server answered with a HTTP 200 OK response and is respective results that were produced by the script. Next, the second HTTP request is much more interesting. As you can see we make a HTTP request to the same CGI script but now in the User-Agent field we crafted a string that will allow code execution. Because bash does not separate code from data this string will be part of environment variables. The code will be execute with the user permissions of the web server which in this case is the apache user account. In this case we just run the /usr/bin/id and as you can see the Web Server answered with the output of the id command.

shellshock-hands-2

So what can an attacker do?

This remote code execution attack vector is pretty serious because it allows to execute commands on the operating system, change configuration files and many other nasty stuff. The following picture demonstrate a scenario where an attacker via this attack vector can fully compromise a system.  The attacker opens 2 shell commands (attacker shell 1 and 2).

shellshock-hands-3

  1. Evil starts a HTTP deamon that will serve Evil stuff. It compiles a local escalation privilege exploit for Linux machines. Using Metasploit it creates a reverse shell that will connect back to the attacker on port 8080. Then it will put a NetCat listener accepting request on TCP port 8080.
  2. Then, Evil starts creating the malicious HTTP requests to the CGI script using the User-Agent field as payload for the commands. It start by downloading the local privilege escalation exploit camouflaged as JPG file to the /tmp folder which is writable by the user apache.
  3. Next it downloads the reverse shell binary.
  4. It assigns execution permissions to the reverse shell binary.
  5. It executes the reverse shell.
  6. On the NetCat listener the attacker will receive the reverse shell and will have a command line open to the system. Now he can execute the local privilge escalation exploit.
  7. Evil got root access to the system!

As you could see this was pretty easy to execute and Evil got root access into the system. Following that, Evil could retrieve the passwd and shadow file and crack the credentials accounts or he could find a way to maintain persistence and cover his tracks.

How could one increase its protection against this?

Three key recommendations : Patching , Egress traffic filtering and Hardening. By not using the latest patches and security recommendations you are exposed to this kind of scenarios. Patching is one of the most effective recommendations that someone should take. Egress filtering is extremely important nowadays, not filtering outgoing traffic to the Internet allows your internal systems to communicate with any IP address from the Internet which significantly increases the risk of downloading malicious code and be compromised. Finally, fortify your systems using the security best practices and vendor recommendations e.g. SELinux in this case would not allow Evil to initiate a socket using the apache account limiting Evil ability to download its malicious code.

The tools and tactics used are not new. However, they are relevant and used in today’s Shellshock attacks. With this kind of scenarios one can learn, practice and look behind the scenes to better know them and the impact they have.

Tagged , , , , , , ,

ShellShock – Highlights

shellshock-tweetWednesday, 24 of September, Florian Weimer from Red Hat security team publicly announced on Open Source Security Maillng list  a vulnerability in GNU Bash discovered by Stephane Chazelas. 1 hour later he released a patch  and the technical details about the vulnerability – “an environment variable with an arbitrary name can be used as a carrier for a malicious function definition containing trailing commands makes this vulnerability particularly severe; it enables network-based exploitation“. Essentially a command injection vulnerability that allows remote code execution. Meanwhile some news sites were already publishing details. This situation was not altogether confortable when it was known that details were disclosed before the embargo that was putted together in order to give vendors to patch it before it went public. This vulnerability got CVE-2014-6271 with a CVSS score of 10 and low score on complexity which means its easy to exploit. It affected all Bash versions prior to 4.3. The vectors of attack as described by the US-CERT include:

  • Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash, or spawn GNU Bash subshells, or on any system where the /bin/sh interface is implemented using GNU Bash.
  • Override or Bypass ForceCommand feature in OpenSSH sshd and limited protection for some Git and Subversion deployments used to restrict shells and allows arbitrary command execution capabilities. This data path is vulnerable on systems where the /bin/sh interface is implemented using GNU Bash.
  • Allow arbitrary commands to run on a DHCP client machine.

From the previous described attack vectors the HTTP requests to CGI scripts were identified as the major concern.  While the news were still spreading, on the 25th of September when people were rushing to patch, Tavis Ormady proved that the patch was incomplete and the vulnerability was still exploitable. This got identified as CVE-2014-7169 with a CVSS score of 10. This got patched on Friday the 26th. Meanwhile another two vulnerabilities were discovered by Todd Sabin. Harder to pull off but still critical. They got CVE-2014-7186 and CVE-2014-7187. in the meantime Michal Zaleski who is another brilliant security researcher and works with Tavis on Google security team found two additional vulnerabilites. He gave the details privatelly in order to give time to patch. On 1st of October, Michal disclosed the details. These last two vvulnerabilities got CVE-2014-6277 and CVE-2014-6278.  The last patchs from the vendors mitigate all the 6 vulnerabilities. Below is a timeline of the key dates during this rush week.

shellshock-timeline

During the rush hours of the disclosure, Robert Graham from Errata Security started to massivelly scan the internet looking for vulnerable hosts.  The results were impressive. Troy Hunt also wrote a nice summary about it. While security researchers, vendors and corporations were working together to assess and mitigate the risk of this vulnerability Evil started to show is fingers. Attacks started attempting to exploit the vulnerability. Rapid7 weaponized the exploit into Metasploit.  Due to the wide amount of attacks seen SANS raised its INFOCON level to Yellow on the 26th. Johannes Ulrich wrote a great summary about it. Among the exploitation techniques seen were automated click fraud, reverse shell attempts, all kinds of recon activity, PERL bots and others. Trend Micro released a comprehensive.technical report. FireEye wrote a great summary on the exploit techniques seen in the wild.

Tagged , , , , , , , , , , ,