May 272015
 

Recently our team was tasked with creating a demo to illustrate the effects of Denial of Service (DoS) attacks. As I was particularly interested in how the available attack tools work I studied the sourcecode of one of them – the Low Orbit Ion Cannon. In this post is will cover the surpising simplicity of the implementation. However to get a context let’s start first  with discussing how DoS attacks generally work, illustrated on the basis of the following setup:

dos (1)

In our simple demo network there are only three participants: A central webserver as victim, a legitimate user that wants to connect to the webserver and an attacker. In the beginning the legitimate user can browse the webpage hosted on the webserver smoothly. However as soon as the attacker starts his DoS attack the legitimate user’s requests either take very long to finish or even fail completely. This instability is caused by the attack overloading either the webserver’s connection or the server process itself.

One tool an attacker could use for these kind of attack is the free and open source Low Orbit Ion Cannon. It is a very easy to use application with a nice graphical user interface. The video embedded below contains a short walk though.

Now let’s get our hands dirty: To find out how the application attacks the victim’s server in detail we have to download and analyse the source. Below is a cleaned up and simplified version of the method responsible for carrying out the actual HTTP Denial of Service attack.

byte[] buf = System.Text.Encoding.ASCII.GetBytes(String.Format("GET {0} HTTP/1.0{1}{1}{1}", Subsite, Environment.NewLine));
var host = new IPEndPoint(System.Net.IPAddress.Parse(IP), Port);

while (this.IsFlooding) {
	byte[] recvBuf = new byte[64];
	var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);

	socket.Connect(host);
	socket.Send(buf, SocketFlags.None);

	socket.Receive(recvBuf, 64, SocketFlags.None);
}

To my surprise the method was a lot shorter and less complex than I expected. I will now try to walk you trough the functionality so that you also understand what is going on even if you are not a developer .

In the first two lines the application prepares the attack’s underlying HTTP request and sets the target IP address and the target port. Although it’s done in an rather unusual way it’s a legitimate implementation for an application requesting data from an external HTTP service. In the following third line the while command tells the system to repeat all enclosed and indented further commands. Within this section the actual attack is launched. However to do so two more things need to be prepared: At first in line 5 a buffer called recvBuf is created that is used to store the subsequential answer from the victim and in line 6 further connection details like the use of the TCP protocol are specified. Finally in line 8 the network connection to the victim’s server is established and in line 9 the HTTP request that was created in the beginning is sent. The subsequent receive method call in line 10 stores the first 64 byte of the server’s reply in the previously created receive buffer recvBuf. This forces the application to wait for the server to reply before it moves on. Until now we behaved like a normal web browser. However as the last command within the while loop was reached the whole process beginning at line 5 is repeated. Again and again and again …

What that means is we didn’t really use any service and just created unnecessary load on the server and the network connection. As the attack requests are generally repeated as fast as possible and are executed in parallel this load can render services unusable or even bring them down completely. This is especially true for Distributed Denial of Service (DDoS) attacks where many attackers or their bots join forces to attack a target as happend to the Playstation Network in 2014.

To recap: The sourcecode contains no nasty little tricks or algorithms that require any special knowledge. That means you don’t need to be a genius to write an effective and widely used Denial of Service attack tool. For me that is somewhat frightening!

May 122015
 

The first and most important thing you need to know about the Pass the Hash (PtH) attack is, that it is not a single attack but actually a whole group of attacks that should correctly be called Pass the X. In any of these, the attacker obtained some kind of user identifying information (like the plaintext user password, a password hash or a Kerberos ticket) and uses them to impersonate as that user. This post focuses on the NTLM hash and the Kerberos tickets as they are the most interesting one’s from the Pass the X’s point of view. This attack is possible not because of a security vulnerability or design issue but because of the infrastructure necessary to enable single sign on (SSO). Although it can be used on any operating system and any version, Windows networks are the primary target.

At TechEd North America 2014 Mark Russinovich and Nathal Ide gave a great talk on the technical background of Pass the Hash styled attacks. It’s available on Youtube and I really encourage you to watch it.

In the following paragraphs I will try to give an overview about the different Pass the Hash attacks and scenarios. However this is not a tutorial and so I will not document the specific commands. Please see the section “Your Toolbox” for further details, tutorials and the necessary tools.

Where To Obtaining User Identifying Information From?

Before an attacker can start a Pass the X attack he has to obtain something to pass along. There are two ways to do so. Either he gains local administrator rights on a client and dumps the hashes of all currently logged in users from the so called Local Security Authority or he gains access to a Domain Controller and dumps possibly all user hashes from the AD.

Dumping from a Client

Let’s start with the somewhat less severe scenario of a client overtaken by an attacker with access to a local administrator. In Windows the Local Security Authority or lsass.exe is the process responsible for enforcing the security policy on the system. Furthermore it is also responsible for transparently authorizing the users to the services they want to use. For example if a user connects to a file server the system negotiates the protocol to use and the Local Security Authority transparently tries to sign the user in. It supports many different protocols like NTLM, Digest and Kerberos and it can also be extended by plugins.

The important thing is that depending on the protocol, the system has to cache a varied of user identifying data in order to successfully reauthorize the user. For example the Digest module needs to cache the user password in reversible encrypted form. An attacker can use any of this user idenfitiying information for this Pass the X attack.

2015-04-27_16h02_07

With that knowledge any local administrator can dump the memory of the lsass process (with for example mimikatzWCE or Task Manager’s Create Dump File) and thereby obtains the cached user identifying information of all currently signed in users. Depending on the enabled modules this at least reveals some password hashes but it might also already dump their plaintext password.

Dumping from Active Directory

The second way of dumping user identifing information can only be used by an attacker that already gained access to a Domain Controller. There he can dump the LM and/or the NTLM hashes of all users as they are stored in the Active Directory. Again it does not really matter which one he captures as both can be misused.

You may ask why an attacker with Domain Admin access still leverages Pass the Hash styled attacks? Well, it allows him to impersonate as any user on the domain without knowing or resetting the user password. Thereby he can easily access the user’s Exchange and Sharepoint account as well as connect to any file share the user has access to. This approach is especially great when giving presentations to C level executives. They may not care about an attacker being Domain Admin but they will care for sure if it allows them to access their mailbox or calendar.

2015-04-29_09h11_06

As it is a little more complex to dump the hashes out of the Active Directory I will cover this process briefly. Generally there are two steps: At first an attacker creates an offline copy of the registry and the AD. This can be done with the help of ntdsutil and VSS. Then he moves the files off the Domain Controller to his local machine. There he uses a tool like secretsdump to extract the hashes as shown in the picture above.

Using the Hashes

Although you already know that the hashes allow an attacker to impersonate as that owner of the hash, we will now cover this is more detail. If you are interested in a live demonstration I recommend you to watch the first 26 minutes of the talk “Still Passing the Hash 15 Years Later” from Black Hat USA 2012.

As discussed in the beginning the Local Security Authority is responsible for caching the user identifying information. To use the stolen hashes an attacker now simply replaces the user identifying information within the lsass.exe process on his own computer (again with for example mimikatz or WCE) with a stolen one. From the network’s point of view he thereby basically transformed his account to someone else’s. Mark Russinovich and Nathal Ide also talk about this process in their presentation “Pass-the-Hash: How Attackers Spread and How to Stop Them” starting at minute 7:10.

By doing so he also gains the single sign on (SSO) capabilities of the original account because the is what the hashes are intended for. That in turn allows him to use any service and application that builds upon the Windows Integrated Authentication including but not limited to:

  • Microsoft Exchange
  • SMB Filesharing (NTLM authentication over IP, Kerberos authentication over DNS)
  • Microsoft SQL Server
  • Microsoft Navision
  • Microsoft Sharepoint
  • Many business critical web applications
  • Any SAP Application

Again: By replacing the information within the Local Security Authority the attacker changed his identity to someone else’s without knowing the corresponding password. He can use any service the rightful account holder could use as long as it supports single sign on. This also works for accounts that use a two factor authentication like a smartcard as they still rely on the same single sign on infrastructur.

The Golden Ticket

A special case I want to highlight is the Golden Ticket attack. If an attacker obtained the NTLM hash of the KRBTGT domain account he can create a so called Golden Ticket. This is nothing else than a valid self created Kerberos Ticket Granting Ticket (TGT). With that ticket it is not only possible to impersonate as some else but it is also possible to authorise yourself. It is basically an attackers dream. The video below shows that attack in action.

Final Thoughts

For an attacker or pentester Pash the Hash styled attacks are a very valueable attack vector. Virtually all companies are prone to it as single sign on is used by many of the most business critical applications. Furthermore it often allows an attacker to rapidly elevate his priviledges after obtaining initial access to a low profile client.

Although Microsoft already actively participates in the ongoing debate about Pass the Hash it is still a long road before all organisations understand the associated risks. I have commited myself to actively point people to Microsoft’s Pass-the-Hash portal so that the words spreads a little faster.

If you have any questions or additional input please leave a comment below.

Your Toolbox

Finally here is a list of applications and the corresponding documentation for your further reading. All this links really helped me to deeply understand Pass the Hash styled attacks and to write this summary. Hereby I want to thank all the authors for their great job!

Applications

General Documentation

mimikatz Specific Documentation

Apr 272015
 

Recently some colleagues and I discussed the possibility to obfuscate known malware samples so that they successfully pass a virus scan. This works because most scanning engines detect threats due to their signature. These signatures in turn are based on the program code of the malware. An attacker can now modify or obfuscate the source code of already known malware and thereby avoids detection.

As we were unsure about the real-world feasability and the ease of use of the available obfuscation tools I decided to test one of them: The Veil-Framework. To do so I set up a fully patched Windows 7 Professional 32Bit VM secured with AVG AntiVirus FREE 2015 with the goal to modify a previously detected and blocked malware so that it sucessfully executes.

Creating the malware

The first thing I had to do was to create a malware for this test. As I wanted a “safe” malware, I decided to use the Metasploit windows/messagebox payload. It only opens a messagebox but it is detected as malicious by many scanners.

To ensure that we use exactly the same source for all further tests I used the msfpayload command line utility to create a Windows application (malware.exe) and to dump the corresponding raw shellcode (malware.raw)

msfpayload windows/messagebox TITLE="Malware" TEXT="Malware executed" ICON="WARNING" X >malware.exe
msfpayload windows/messagebox TITLE="Malware" TEXT="Malware executed" ICON="WARNING" R >malware.raw

As expected, the unobfuscated malware (malware.exe) was immediately detected by the AVG scanning engine:

2015-04-25_21h54_35So let’s move on to modify our malware by …

Obfuscating the Shellcode

To do so we use Veil-Evasion that is part of the Veil-Framework. The following command creates an obfuscated python script that contains the original AES encrypted shellcode with the help of the python/shellcode_inject/aes_encrypt payload.

./Veil-Evasion.py -p python/shellcode_inject/aes_encrypt -c compile_to_exe=no --overwrite -o obfuscated_malware

Before the obfuscation progress starts we have to provide the previously created raw shellcode of our malware:

2015-04-24_22h11_14

Veil-Evasion supports many different programming languages (C, CS, Powershell, Python, …) and methods (shellcode injection, different meterpreter payloads, …) for obfuscation. For an up-to-date list browse the payloads subfolder in the source code repository.

Although the Veil-Framework is capable of directly creating a Windows application I had some problems with the thereto necessary Wine installation. As a workaround I simply copied the obfuscated malware to my Windows computer and used PyInstaller to convert it there to a self contained application.

C:\Temp>C:\Python27\Scripts\pyinstaller.exe --onefile obfuscated_malware.py

In the background PyInstaller analyses the Python script and packs all the necessary modules and libraries including the Python Runtime into a single and redistributable Windows application.

Playing Hide & Seek

Finally I copied the newly obfuscated malware to the test machine and double clicked it. To my pleasure, it passed the on-access virus scan and executed.

2015-04-25_22h29_17

As I was eager to know how well I masked my “malicious” intends I uploaded the file to VirusTotal. Although it was detected by 7 out of 56 scanners this is still a major improvement over the initial 35 detections.

Conclusion

With this demo I clearly showed that it is fairly easy for malware applications to avoid detection from off-the-shelf virus scanners by using obfuscation. This targeted attacks are hard to mitigate and they require special security tools with for example virtualisation and malware analysis capabilities to do so. The good thing is that modified malware will most likely be detected by virus scanners within days after their initial deployments. Additionally more and more engines already detect the obfuscation itself and also block the file.

This all boils down to the fact that virus scanners are only one tool in the ongoing fight for protecting your critical infrastructure.

Mar 262015
 

Cygwin is a great tool to run Linux application on Windows. I primarly use it to run my already written shell scripts. What I always missed was the ability to launch shell scripts with a simple double click. However this is very easy to setup. Just right click on a .sh file and select “Open with…”. Now browse to “C:\cygwin(64)\bin” and select mintty.exe. Don’t forget to check the checkbox at the bottom of the dialog to always use the selected application. From now on just double click any .sh file and it gets executed automatically.

openwith

Nov 272014
 

Connection DiagramI’m responsible for several VMware ESXi hosts that are secured using a Bastion host. These Bastion hosts help to protect our client’s infrastructure and only allow access over some specifically enabled network protocols.

It’s clear that they don’t allow traffic from the Internet to our VMware ESXi systems, so we have to go a different route to manage them. Fortunately we can connect to our Bastion host using SSH and then tunnel the vSphere connection from the client machine to the ESXi system. The diagram on the right shows the corresponding data flow. This post will focus on the necessary configuration as I always forget how to setup a new client machine.

Before we start, here’s a screenshot that summarises all the steps:
ESXi over SSH Steps

1.) hosts File

The first thing you need to do is to add a new localhost alias in your hosts file. If you don’t know where to find it or how to modify it, check out this great article. At the bottom of the file append the following line:

127.0.0.1	esxilocal

2.) Connect to your Bastion host

Now connect to your Bastion host using a client that supports SSH Tunneling. I always go with PuTTY.

3.) Tunnel Configuration

In the next step we have to configure the three necessary tunnels. For the vSphere Client to successfully connect we have to forward the TCP ports 443, 902 and 903. Please ensure that you use the same ports locally.

4.) Connect

If you have setup everything correctly you are now able to connect over the SSH connection. Be aware that you have to use the hostname that you configured in the first step (like esxilocal) not the machine’s real one.

Congratulation, that’s it!

Oct 232014
 

Screen Shot 2014-10-23 at 16.17.09Currently I’m busy building several automated workflows that run on our flow:rage Video Storage System and that move files and directories from A to B while processing them in some way.

During qualifying this workflows for production we discovered that moved items were not immediately visible for Windows clients connected using SMB. Sometimes it took several minutes for the files and directories to show up. Even manually refreshing the parent folder did not help. Linux and OS X clients were not affected by this issue and so it was clear that this had to be a client side caching problem.

My google-fu helped me to find the TechNet article SMB2 Client Redirector Caches Explained that explains the Windows SMB2 Cache and it’s configuration options. Based on the I created the following .reg file [download]:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters]
"DirectoryCacheLifetime"=dword:00000000

This configuration change disables the client side directory content cache. That means that file and directory changes are immediately visible for the client. This was exactly what I needed to solve my issue. However be aware that this change causes the client to contact the server more frequently.

Oct 072014
 

We have several smaller customers that use a VMware ESXi host with just a single Windows Server VM. To backup these VMs we often use either Windows Backup or a third party application running within the guest that saves all important data to an external USB drive. To be prepared for things like water damage we always suggest to use two rotating disks with one stored securely at another location.

USB Pass-throughThe problem here is that many of our customers are not very tech savvy and they generally don’t want to change anything on the server. That means I had to find a way so that they just have to replace the physical USB backup drive and don’t have to think about how the USB drive is forwarded to the VM.

To solve this I use the PCI pass-through option on the ESXi server. The screenshot on the right shows how that looks on an ESXi 5.0. After shutting down the VM add a new PCI device and select the USB controller of the host system. After switching the VM back on you can connect any device to any USB interface on the host and everything is forwarded automatically. However be aware that only a single VM can access the USB ports because you can forward a PCI device only once.

Another solution regarding USB devices is discussed in the VMware KB entry “USB support in ESXi/ESX 4.1 and ESXi 5.x“.

Jul 302013
 

It sounds like a simple task to configure a Windows client to connect to a L2TP/IPsec server hosted by Mac OS Server. However it’s not.

Requirements

To setup the connection you need the following informations:

  • Username and password of a VPN enabled account
  • the L2TP/IPsec shared secret
  • official IP or hostname of the VPN server
  • Administrator account on the Windows machine

Setup

The first step it the most important one. Open the registry editor (regedit) on the Windows PC as administrator and add the DWORD AssumeUDPEncapsulationContextOnSendRule with a hex value of 00000002 within HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PolicyAgent. To apply the changes you have to reboot.

Then add a new VPN connection using the Set up new connection or network assistant in the Network and Sharing Center. Be sure to enable the checkbox Don’t connect now, just set it up so I can connect later.

To finish the last step open the Properties dialog of your newly created VPN connection. Within the Security tap change the type to L2TP/IPsec and set the shared secret within the Advanced settings. Furthermore change the dropdown menu Data encryption to Optional encryption.

Now you are able to connect to the VPN service!

Dec 212012
 

Mac OS X extensively uses file metadata. As this post explains there are two fallback mechanisms if a volume is not able to handle this data.

On the one hand .DS_Store files are created to store mostly Finder specific settings. On the other hand metadata like resource forks or creator types are stored in “Dot Underscore” Files. For example the metadata for the file “Demo.avb” is stored in “._Demo.avb”. Both mechanisms are great in an all Mac environment but can cause troubles in mixed setups. Luckily there are ways to at least minimize the pain.

.DS_Store

Even Apple thought that this files are not always necessary and build in a setting to disable the creation on network drives.

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Furthermore the guys from BinaryAge (the creators of the epic TotalFinder) build a tool called Asepsis. It is used to redirect all .DS_Store files into a folder buried in the depth of the system. Thereby the Finder is still able to store folder specific settings but external drives aren’t effected anymore.

Dot Underscore Files…

… cause more trouble. As they eventually store application specific data there is no official way to disable them. A possible workaround is to schedule a script to delete them (every night). This is exactly what I did for Windows (Powershell script) and Unix (Bash script) operating systems. On Windows the script can be scheduled using the “Scheduled Tasks” system setting. On Mac OS X a launchd configuration should be used – it can easily be created using Lingon. Other Unix operating systems can use a cronjob!

The script recursively searches a given folder for Dot Underscore Files and deletes them. Be aware they will most likely be recreated! You can download the Windows and Unix version using this link.

Aug 012012
 

The following problem can be reproduced on all Mac OS X Lion clients:

When you set your Adobe After Effects CS5.5 render output path to a folder on an NFS volume shared by an Windows 2008 R2 server the render process stalls. After that the machine has to be hard reset!

While doing some server and network protocol performance tests we discovered the described problem. We also set up a dedicated Windows NFS test server and a Mac OS Lion client to verify it. Other NFS servers are working as expected.

It looks like that After Effect tries to set a lock on the render destination file. During that something (??) goes wrong and the process stalls. After that the NFS kernel extension is still dead locked (??) and you need to hard reset your Mac.

To work around this issue the “sync” mount command line option can be used! This causes a big performance loss but at least it allows you to render to the NFS volume.

mkdir mountpoint
mount -t nfs -o sync server:/sharepoint mountpoint

Further details about the sync/async operation can be found in the exports man page.