An IPv6 Introduction for Pen Testers // Part 4

 Network, Security, Tipps  1 Response »
Jul 262015
 

In this last part of the series IPv6 for pen testers we will now cover how address autoconfiguration works without the need for a central DHCP server. I really encourage you to read part 1, 2 and 3 of this series as they cover the IPv6 fundamentals needed to understand the following paragraphs.

In IPv4 a central DHCP server was used to autoconfigure the IP addresses and the standard gateways for all clients. In IPv6 however, routers advertise the on-link networks and the available routes on their own using multicast. That means that as soon as a new client is connected to a network, all the available routers advertise all the avilable network prefixes. The client then assigns itself an IPv6 address within each on-link network and adds all other prefixes to his routing table. The full IPv6 addresses for the on-link networks are created by appending the host portion as generated by the  EUI-64 algorithm as discussed in part 3 to the advertised network prefixes. We will now discuss this process in more detail with the help of the following image: 

In IPv6 all routers on a network join the so called All-Routers multicast address FF02::2. This group is then used to periodically advertise all available on-link network prefixes and all routable destinations. However as it takes up to two minutes to receive all information a recently booted system can trigger a full re-advertisement of all prefixes by sending a Router Solicitation message to the All-Routers multicast group. After that all routers directly reply with Router Advertisement messages with all on-link and all routable destinations. As already mentioned the client than adds a new IPv6 address for each prefix by appending its EUI-64 host ID. This process allows a client to join a network without any prior configuration.

If it is necessary to provide more information to the clients (like DNS servers) the special “Other configuration” bit can be set in the Router Advertisement message.  It indicates that other configuration information is available via DHCPv6. This type of DHCP server is called stateless because it only hand out static configuration and does not track its clients.

Beyond using Stateless Address Autoconfiguration (SLAAC), as this process is called, it is still possible to use a fully featured DHCPv6 server instead.

Router Advertisement Flood

A pen tester specific IPv6 technique was discovered by Sam Bowne, a well known IT security expert. He developed a Denial of Service exploit for all up-to-date operating systems (Linux, Windows and OS X) based on Router Advertisement messages. It works by flooding the network with new route advertisements that get processed by the attacked clients. During this processing the systems get practically unusable. Sam captured several videos to showcase the result of the flood on this website.

Further Reading

Before rounding this series up here are some references for your further reading:

Roundup

Although already standardized in 1998 IPv6 still has not fully reached the end customers. Only very few ISPs in Europe by default even provide IPv6 address to their customers and even less companies use IPv6 within their networks. However as IPv4 addresses will eventually run out in the not too distant future companies have to prepare their equitement and train their employees. This is especially important as virtually every new network component is IPv6 capable and most of them even have it pre-enabled. As we have learned in this series IPv6 introduces many new concepts and some of them can be misused. I currently advise everyone to disable the IPv6 stack on their network components if not used and I highly recommened companies to train their administrators so that they know how IPv6 works and what challenges it brings with it.

An IPv6 Introduction for Pen Testers // Part 3

 Network, Security, Tipps  No Responses »
Jul 142015
 

Welcome back at part three of my blog post series about IPv6 for pen testers. In part 1 we already covered the advantages of IPv6 and how IPv6 addresses look like and in part 2 we discussed the three different IPv6 address types and how Link Local adresses are generated. I encourage you to read both posts before continuing as they cover the basics for this entry. We will now take a closer look at IPv6 multicast and how Layer 2 address discovery is implemented.

Multicast

Although already available in IPv4 almost nobody ever heard of multicast before. What it does is, it enables a one-to-many communication pattern on a network level. To do so, so called multicast groups are formed. These groups are basically special IP adresses within the so called IP multicast range (224.0.0.0/4 in IPv4 and ff00::/8 in IPv6). A client that is interested in joining the communication in such a group instructs the network to send this group specific communication to its network port. All clients that are not interested do not even receive the traffic as they did not join the group. If you are interested in what multicast groups a system is joined you can use the following commands:

Linux: netstat -g
Windows: netsh interface ipv6 show joins

With IPv6, multicast will be a fundamental part of every network  and will even replaced all broadcasts.  This is especially important as broadcasts have been a problem for years in large networks as they are sent so all systems in the whole network and thereby cause a lot of unnecessary network traffic. Furthermore every broadcast has to be processed by the end device and thereby wastes processing power.

Neighbour Discovery

However without broadcasts a problem arises: ARP the Address Resolution Protcol used for resolving IPv4 to MAC addresses and thereby enabling the necessary OSI Layer 2 communication can not be used anymore and a replacement has to be defined.

This replacement is called Neighbour Discovery (ND) and is built on ICMPv6 and IPv6 multicast. It works by sending a Neighbour Solicitation (NS) request to the address dependent Solicited-Node multicast address while listening for the correspoding Neighbour Advertisement (NA) answer. Before covering this process in detail here are the commands used for showing all known neighbours similar to the ARP table:

Linux: ip -6 neigh
Windows: netsh interface ipv6 show neighbors

Layer 2 Address Discovery

By enabling IPv6 and by configuring an address the system not only allows you to communicate using this address but also automatically joins two IPv6 multicast groups. The first is the already mentioned Solicited-Node multicast group. It is dynamically generated by taking the last 24 bits of the corresponding IPv6 address while prepeding the ff02::1:ff00:0/104 Solicited-Node multicast prefix. The second is the IPv6 All-Nodes multicast group ff02::1 that is joined by all IPv6 capable systems.

Now let us recap using an example: By setting up the IPv6 address 2000::9999:1111 on System A it will join the Solicited-Node multicast address ff02::1:ff99:1111 and the All-Nodes multicast address ff02::1.

If in turn System B wants to send data to System A (2000::9999:1111) it needs both the IPv6 address and the corresponding MAC address. To get the MAC address, it sends a Neighbour Solicitation (NS) message to the Solicited-Node multicast address ff02::1:ff99:1111. System A will reply with a Neighbour Advertisement (NA) containing its MAC directly to System B. After that System B has all the necessary information and can send data to System A. The image below illustrates the process.

Duplicate Address Detection

Beside the discovery of Layer 2 addresses this process is is also used to avoid address collisions. Before a new IPv6 address is assigned to an interface the systems sends a Neighbour Solicitation message to the corresponding Solicited-Node multicast address. However instead of using the interface’s IPv6 address – which has not been set up yet – the unspecified address :: is used instead. If the address is already in use the owner replies with a Neighbour Advertisement to the IPv6 All-Nodes multicast address and the setup process is aborted. If no answer is received within a given time frame it is assumes that no-one else is using it and the setup continues. This process is called Duplicate Address Detection (DAD).

Before summing up let us briefly cover a good trick that can be used by pen testers to detect all IPv6 capable devices. As we already discussed there is the All-Nodes IPv6 multicast group. In contrast to IPv4’s broadcast you can ping this group while getting a reply from all IPv6 devices on the network. This is a great way to find your targets! The following commands show how to ping the All-Nodes IPv6 group:

Linux: ping6 -I eth0 ff02::1
Windows: ping ff02::1

To summarize, we covered what IP multicast is and what it is used for. Furthermore we talked about IPv6’s ARP replacement namely Neighbour Discovery and how it works in detail. In the next and final part we will then cover how IPv6 Addresses are managed without the need for a DHCP service and why you still need one.

An IPv6 Introduction for Pen Testers // Part 2

 Network, Security, Tipps  1 Response »
Jul 082015
 

Welcome to part two of my introduction to IPv6 for pen testers. If you did not read the first part I really encourage you to do so before reading any further. In the next paragraphs we will briefly discuss the different IPv6 address types and cover Link Local addresses in detail.

IPv6 Address Types

In IPv6 there are three different kinds of address:

  • Unicast: These addresses are used for direct one-to-one communication. There are global and local unique unicast and Link Local addresses. Global one’s are managed by IANA and right now all are within the 2000/3 network. Local one’s can be used within organisations to for example identify the location of a system and can either use the FC00/8 or FD00/8 network. Finally, Link Local one’s use the FE80/10 network and are only valid for the directly connected network segment. We will dicuss those shortly.
  • Multicast: These special reserved addresses in the FF00/8 network are used for one-to-many communication. IPv6 multicast completely replaced the need for broadcasts and are used extensivly during IPv6 operation.
  • Anycast: Any unicast address can be used for anycast as soon as it is assigned to multiple systems. Thereby a client automatically connects to the closest anycast server. This enables load balancing on the network layer.

A system in an IPv6 world will almost ever have multiple addresses assigned to its interfaces. For example as soon as IPv6 is used on an interface a Link Local address is generated and assigned, furthermore the network will provide one or more unicast addresses used for communicating with the outside world or the company network.

Link Local Addresses

We will now cover Link Local addresses in more detail. As already briefly discuessed they are automatically generated and are only valid for the directly connected network segment. Any device that claims to speaks IPv6 supports and uses them. As soon as a new device is connected it can be reached using its Link Local IPv6 address. The following steps (based on RFC2464) show how to generate the IPv6 Link Local address from a NIC’s MAC:

  1. Get the 48bit MAC address of the NIC
  2. Convert the MAC to binary and flip the 7th bit. This is necessary as in the MAC address if set, this bit identifies a locally administrated and thereby modified address. However in the desired EUI-64 format the bit is interpreted in the the exact opposite way, so that a set bit indicates a globally unique address as burned in by the manufacturer (again see RFC2464).
  3. In the middle of the MAC address with the already flipped bit add FFFE.
  4. Finally, the Link Local FE80 network prefix has to be prepended while filling everything in between with zeros so that a valid IPv6 address is generated.

The following example shows how to apply this algorithm:

1.) Get the MAC address:
a4:52:6f:44:7e:69 => a4526f447e69
2.) Convert the MAC to binary:
10100100 01010010 01101111 01000100 01111110 01101001
3.) Flip the 7th bit:
10100110 01010010 01101111 01000100 01111110 01101001 => a6526f447e69
4.) In the middle add FFFE
a6526fffee447e69
5.) Add the Link Local FE80 network prefix and generate final IPv6 address
fe80::a652:6fff:fe44:7e69

I covered this algorithm in that much detail because it is the first really interesting IPv6 aspect from a pen tester’s point of view. Many systems already have IPv6 preenabled however most administrators only block access using IPv4 firewalls. That means that it is always worth a try to check if a server offers more services using IPv6 than it does over IPv4. To do so you simply ping the server using IPv4 to get its MAC address cached in your ARP table. Then you apply the above algorithm to this MAC and voilá you now have the server’s Link Local IPv6 address ready to be scanned. As I was tired of repeating this steps over and over again a colleage and I wrote IPv4_to_IPv6_address_generator. It is a small python tool that simply automates the above steps and it works on Windows and Linux.

After all that hard work of generating the Link Local IPv6 address we can now connect to the network and the device is ready to be used. If you are interesting if your computer already has IPv6 enabled just use one of the following commands. They will list all your currently assigned IPv6 addresses:

Linux: ip -6 addr
Windows: netsh interface ipv6 show addresses

Summing up we discussed the different IPv6 address types and generated a Link Local address from a NIC’s MAC. In the next post of this series we will take a closer look on IPv6 multicast and why it will completely replace broadcasts. Furthermore we will discuss how Layer 2 address discovery works with IPv6.

An IPv6 Introduction for Pen Testers // Part 1

 Network, Security, Tipps  3 Responses »
Jul 012015
 

Due to the shortage of IPv4 addresses IPv6 has been developed. It is the successor protocol that will be used in parallel to IPv4 to drive the Internet’s underlying infrastructure. In this series of four blog posts I will give a general introduction to the most important aspects of IPv6 with a focus on the pen tester’s point of view. Be aware that this series is about the fundamentals and thereby does not cover all the dirty little details.

In part 1 we will cover IPv6 in general and how an IPv6 address look like.

IPv6 Overview

The easiest to spot change is that the IPv6 addresses are a lot longer than its IPv4 siblings. The additional bits increases the available address space and thereby allow us to address a lot more devices. Here are the numbers:

  • IPv4 address: 32bit (4294967296 available IP addresses)
  • IPv6 address: 128bit (340282366920938463463374607431768211456 available IP addresses – And yes, every single atom on the earth surface can be addressed with IPv6. You can even assign more than 100 addresses to each one – Reference)

Furthermore IPv6 has many great features built in like:

  • Mobility (you always use the same IP address wherever you are)
  • Security (IPsec is built in)
  • It eliminates the need to use NAT
  • …

Now let’s take a more close look at how an IPv6 address looks like:

How does an IPv6 address look like

Here is an IPv6 address in its full glory: fe80:0000:0000:0000:02aa:00ff:fe28:9c5a/64

As you can clearly see, IPv6 addresses are not as easy to write and remember as IPv4 addresses. They are composed of 8 sections each representing 16bits of the full 128bit address space written in hexadecimal notation. Furthermore it is compose of two parts: the network portion and the host portion. The network portion is defined using the CIDR notation (/64 in the above example) and is used for traffic routing. To make it a bit easier for us humans, there are three tricks that can be applied to make the address a little easier to handle:

  1. The first thing you need to know is that is does not matter if you use lower case or capital letters. You can even mix case if you like to. That means that the following examples are valid addresses and all three represent the same host: 
    Example 1: fe80:0000:0000:0000:02aa:00ff:fe28:9c5a
Example 2: FE80:0000:0000:0000:02AA:00FF:FE28:9C5A
Example 3: Fe80:0000:0000:0000:02Aa:00fF:fE28:9c5A
  2. Secondly, leading zeros can be removed for each section. However be aware that if a section contains only zeros at least one has to remain. Again the following examples are valid addresses for the same host: 
    Example 1: fe80:0000:0000:0000:02aa:00ff:fe28:9c5a
Example 2: fe80:0:0:0:02aa:00ff:fe28:9c5a
Example 3: fe80:0:0:0:2aa:ff:fe28:9c5a
  3. 3) Finally, rule number three allows you to replace consecutive sections of zeros with ::. However be aware that this is allowed only once. While parsing the address the computer knows that IPv6 addresses always have to have eight sections and simply replaces the :: with the correct number of sections filled with zeros. The following examples illustrate the process: 
    Example 1: fe80:0:0:0:2aa:ff:fe28:9c5a => fe80::2aa:ff:fe28:9c5a
Example 1: 2000:0:0:0:111:ffdc:0:8f21 => 2000::111:ffdc:0:8f21

In this post we discussed some advantages of IPv6, how addresses look like and what tricks can be used to shorten them. In the next one we will take a closer look at the different addresse types and IPv6 Link Local addresses.

Introducing lsdns

 Security, Tools  No Responses »
Jun 182015
 

Today I want to introduce a small helper tool, namely lsdns. I wrote it as I always struggle to find the correct IP and hostname mappings while writing my pentest reports. lsdns is a small python script that queries a DNS server for a given IP range and outputs the results in a CSV compatible format. In this post I will explain why it is useful to me, where you can get it and how to use it.
2015-06-03_11h05_56All our pentest reports document the found vulnerabilities, possible mitigation strategies and logically list all affected systems. To help our customers we always try to provide both, the IP address and the corresponding hostname for any computer mentioned. Although this is generally quite easy, it can be quite a pain if you can not access the original DNS server while documenting the findings either because it is only available from the internal company network (and you did not find a vulnerability that allows you to query it externally) or split DNS is used.

To at least partially solve this issue for me I wrote lsdns. It is a small application that uses reverse DNS to get all hostnames for a given IP range. The output can be redirected to a CSV file and can be used while writing the report to look up either the hostname or the IP address of a vulnerable system.

Installation

To install it you need to have python2 and the python setuptools already preinstalled. Then you can either clone the git repository or simply download the latest ZIP from GitHub. Before you can use it you have to manually install the dependencies from within the dependencies folder by running the corresponding setup.py scripts. After that you are ready to go.

Usage

dnsls is a very simple to use command line utility. The following example shows how to do so:

./lsdns.py <dns server to query> <IP address or range>
Example: ./lsdns.py 8.8.8.8 148.198.1.0/24

By redirecting stdout to a file a valid CSV file is created. To still give you feedback about the progress a dot is printed for each host. A sample is available here.

I hope someone else also sees a value in dnsls. If so, it is freely available for you under the terms of the MIT licence.

An Introduction to Pass the Hash

 Security, Tipps, Windows  No Responses »
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 mimikatz, WCE 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

How Malware Evades Antivirus Detection

 Linux, Security, Windows  No Responses »
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.

The Two Sides of a Security Bug Report

 Security  No Responses »
Mar 112015
 

coinWith my new job as IT security engineer in mind I now surf the web with completely different eyes. Thereby I already stumbled across some more or less severe security issues. I reported all of them to the responsible companies, however they handled them in completely different ways. Some companies simply ignored me while others invited me to visit their office for a chat and a coffee. This blog post is not about the technical details of any of these issues but about the risk the person takes that reports a security problem.

A good bug report nails down one specific problem by documenting a way on how to trigger it. For example if you find a bug that allows you to buy stuff for free the corresponding bug report must contain all the necessary steps to do so. However that is exactly the problem.

Think about the following scenario: You, as a company, receive a bug report that documents a SQL injection vulnerability and you decide to fix it soon (tm). A few weeks later your website is defaced by someone exploiting this specific vulnerability. Who do you think of first as possible suspect? Furthermore to document a problem in detail (and basically help to fix it more quickly) a security researcher has to perform several requests to the vulnerable part of the application. All of this “break-in attempts” are recorded in the log files of the webserver even strengthening the already existing evidence. Even if the researched documented everthing and never exploited the issue to gain any advantage this may now cause trouble for him. In the best case it will be just wasted time or a nice chat with a police officer.

The easiest way to minimize this risk is to openly communicate with the company responsible for the application. Thereby the researcher provides all information necessary to reproduce the bug directly to the responsible person(s). However that is only possible if the company is interesting in getting the issue resolved. Another way to protect himself might be to simply escalate the problem to the press. After being ignore for an extended period of time (several weeks not days!) this might be your only possiblity to finally get the issue noticed by the developers.

With this blog post I hope to raise the awarness for security vulnerabilities in a sense that they are not only a problem for the company responsible for the particular application but maybe also for the person that discovered and reported the issue. If you receive your next bug report please take the time to evaluate it in detail and please response in a timely manner. It’s also in your interest to talk to the person that discovered and reported it.

Time for Change

 Security  No Responses »
Feb 192015
 

Almost six years ago – on the 9th of March 2009 – I started my successful career at ToolsAtWork and ToolsOnAir. During that time I worked on many great things including but not limited to projects related to planing, installing and managing OS X, Windows and Linux servers, developing software in many different languages and recently I mostly designed and implemented large video storage and archiving systems all around the world. I learned a lot of new stuff not only on the technical side but also on how to plan, manage and implement new workflows and solutions. Most importantly, I meet very cool and inspiring people from all over the world working in many different industries. However, now it’s time for change!

Starting with March 2015 I will change my professional focus on IT Security and I will join the Security Audit & Assessment Team at Kapsch BusinessCom AG. With this job change I will also change the focus of this blog to something more security related.

data-security-vs-dave

I want to thank all my former colleagues at ToolsAtWork and ToolsOnAir, all our partners, the customers I worked with and all my readers here for their support and input. It was great fun working with you and I wish you all the best. I would love to hear from you in the comments or connect with you on either LinkedIn or Xing. Of course you are all invited to keep reading this blog to join me on my new journey.

 Newer Entries