Testing Optionsbleed

Written on:September 23, 2017
Add One


I took a few minutes to test the Optionsbleed vuln (CVE-2017-9798), specifically to see whether modifying the length and/or quantity of Options/Methods in the .htaccess file would enable me to extract anything of substance from memory. Ultimately it seems that by modifying the length of the entries in the .htaccess file, I was able to gain access to hundreds of bytes of POST data of a different virtual host.

Note: Since originally publishing, I’ve added several updates to the end of this post.


My setup was simple…two virtual hosts running an an Apache server hosted on a Linux VM. Each virtual host ran on a different port and had separate directories and error logs. Virtual Host 1 (the running on port 80) was simply hosting a “hello” index.html. This was going to be my “attacker” site that would host the malicious .htaccess file. Virtual Host 2 (the “victim” site running on port 81) was hosting a php page that takes three inputs…username, password, and a third, variable length variable.

Throughout the remainder of this post, I’ll refer to them as Site1 (Attacker Site on Virtual Host 1) and Site 2 (Victim Site on Virtual Host 2).

I started with an .htaccess file on Site1 that looked as follows:

Making several OPTIONS requests for Site1 resulted in a modified but fairly innocuous Accept header:

Slight modifications in content and length did return a few varying bytes but nothing very different from the examples I had already seen online and nothing that was of particular interest. I started extending the length of each option/method in the .htacess file (using a simple numeric string of 0123456789) until I got to the following:

It’s three entries of different lengths: 100, 3000, and 2000.

After multiple OPTIONS requests I got this:

Definitely good length, but the content is uninteresting. I let Burp Intruder continue to make OPTIONS requests while I submitted a test POST request on Site2. While the POST on Site2 was successful, my OPTIONS requests running on Site1 began generating 500 errors. I looked at the error log on Site1 and saw multiple entries of varying content that looked like the following:

It appeared that some of the non-ASCII content it was grabbing from memory was making the request invalid to Apache, resulting in the 500 error. I figured it was a long-shot but I tried HttpProtocolOptions Unsafe to see if it could be returned to the client but some of the characters were still considered invalid. Nevertheless, I figured it didn’t matter much given the more viable attack vector would be a malicious actor modifying the .htaccess file on their virtual host of a shared hosting environment. It would stand to reason that they would also have access to their own web server error logs as well (and wouldn’t need to rely on data returned to the client).

So, now I wanted to see if it was possible to access the POST data from Site2 in the error log of Site1 by modifying the .htaccess file further.

After a bit of trial and error, I was able to consistently obtain POST data from Site2 in Site1’s error logs by doing the follow:

First, I used the earlier .htaccess file with the initial set of three varying length numerical strings (100, 3000, 2000) and made a few thousand OPTIONS requests via Burp Intruder. Then, I switched up the .htaccess file to read as follows:

I left Burp Intruder OPTIONS requests running on Site1 with this .htaccess file, which began to generate 500 errors. While that was running, I submitted the following request to the PHP page on Site2:

And here’s what I got in the error log on Site1:

If you try to replicate this, you may get different results, especially if you deviate in length for either the .htaccess entries or the POST request on virtual host 2. Obviously, in an attack scenario, only the .htacess file would be under the bad actor’s control and the POST request on another virtual host would be unpredictable in content and length. However, I did find that varying lengths still resulted in data captured in the error log…it just may not be consistent. Experiment to see for yourself.

UPDATE #1 (9/22): I intentionally didn’t speculate on whether these test results are in any way significant simply because I may be missing something that would make this impractical in un-patched environments. Most organizations aren’t likely going to have exposed shared hosting environments in their own network anyway (and if they do provide the ability for untrusted actors to modify .htaccess on their servers they have bigger problems). For those that have web applications hosted by external hosting providers, my test environment may have been too simple or I might be missing a key consideration regarding shared memory and the typical multi-tenant hosting environment. In any event, I figured I would share these results in case it’s helpful for others to investigate further and either replicate or disprove the results.

UPDATE #2 (9/23): I have been able to get the POST data from Site2 to return directly to the client without generating an error fairly consistently by swapping out the values in the .htaccess file multiple times while the OPTIONS requests are running. Here is what has been working for me:

  1. Start running the OPTIONS requests on Site1 using Intruder (I just let it run for 99,999 requests) using the 100, 3000, 2000 length values in .htaccess.
  2. Modify .htaccess to use the three smaller 0123456789, 0123456789, 0123456789 values as shown previously.
  3. Switch back to the 100, 3000, 2000 lengths.
  4. Modify the .htaccess file again ,this time using ten 0123456789 values.
  5. Submit the POST request on Site2. Below is the result in *most* cases

Again, keep in mind that this is partly dependent upon the length of the POST request submitted on site 2. You can adjust the length of the testdata string to see how your results vary.

UPDATE #3 (9/28): I heard from @WPScans that they had done their own testing and weren’t able to get any interesting data returned via the OPTIONS request.

Since this was an Apache vuln, I wasn’t sure how WordPress (or another similar CMS) would be a significant factor but I happened to have another (considerably older) Apache server available with WordPress and Drupal instances already installed so I fired it up and gave it a test. This server was pre-CVE-2016-8743 so no 5XX errors caused by invalid characters which meant all of the data was being returned directly to the client on the OPTIONS request. Just as in my prior testing, I was able to get interesting data returned:

To make testing easier, I also automated the .htaccess modification via the following python script:

It will simply rewrite the .htaccess file with alternating long/short options values every X seconds. Keep in mind it will overwrite the file with only the Limit declaration contents. To try this on your own test server simply:

  1. Start running the python script in the designated folder where the .htaccess file should exist
  2. Start successive OPTIONS requests against that site (e.g. via Burp Intruder)
  3. Execute interesting POST requests (logins, etc.) on the same site or another virtual host on the same server and monitor the responses from your OPTIONS requests.

For step 3, you may need to play with the length of the POST requests, though at times I was definitely able to obtain data from shorter requests.

Until next time,


























ASK/L(OOK)/Listen! – Basic Signal Decoding and Replay

Written on:September 1, 2017
are closed

Introduction It’s been quite a while since my last post and I figured it was time to start contributing again so I’m kicking it off with a quick-and-dirty method to decode and replay ASK On-off keying (OOK) signals. A couple of notes before I delve in… First, this is not intended to be an intro to SDR/RF hacking. If you’re new to the subject, I highly recommend you go through Michael Ossmann’s free video…


Phishing with Macros and Powershell

Written on:May 22, 2015
are closed

Over the past 6 months, it seems we’ve been experiencing a resurgence of macro-based malware, possibly because it’s such a simple and proven means of delivering a phishing payload to large organizations. If you’re performing a penetration test against an organization and you have reason to believe untrusted macro execution is enabled, they can also be a good means to test user awareness and gain a foothold via social engineering. Regardless of their popularity,…


Offensive Security’s CTP and OSCE – My Experience

Written on:May 13, 2015
are closed

Overview I had been wanting to take the Cracking The Perimeter (CTP) course for some time but my schedule was pretty hectic. I finally forced myself to start it at the beginning of the new year and I’m really glad I did. As promised, here is my review… Prerequisites Offsec states the following: Many pre-requisites are required, such as good familiarity with a Ollydbg, and a general mastery of offensive network security techniques. Definitely sound advice….


An Analysis Of MS15-034

Written on:April 18, 2015
are closed

Introduction By now you’ve undoubtedly heard about MS15-034. The following is a collection of my cursory research and thoughts on this vulnerability. In addition, here is a small list of related resources, some of which I also reference in the sections that follow: Microsoft Security Bulletin MS15-034 (Microsoft) The Delicate Art of Remote Checks – A Glance Into MS15-034 (Beyond Trust) MS15-034: HTTP.sys (IIS) DoS And Possible Remote Code Execution. PATCH…


peCloak.py – An Experiment in AV Evasion

Written on:March 9, 2015
are closed

Introduction I just wrapped up the Offensive Security Cracking The Perimeter (CTP) course and one of the topics was AV evasion. Although I write a lot of custom scripts and tools, when it comes to AV evasion, I typically rely on the tools and methods of others (Veil, powershell, python, custom shellcode). That said, the great thing about courses like CTP is they give me an excuse to investigate a topic that I haven’t…


EggSandwich – An Egghunter with Integrity

Written on:February 12, 2015
are closed

Introduction A while back I introduced the EggSandwich in my tutorial on Egghunting as a means to implement some basic integrity checks into the traditional Egghunter and overcome the problem of fragmented / corrupted shellcode. I recently took the opportunity to update my implementation so it could accomodate shellcode of any size. The code and a brief explanation follows. What is the EggSandwich? I ran into a situation when developing an exploit for an…


Developing a Security Assessment Program

Written on:December 19, 2014
are closed

Introduction Most organizations and are deploying new applications and technologies at a high rate and without a means to adequately assess them prior to implementation, it’s difficult to accurately gauge your organization’s risk. No matter what the size or industry, it’s imperative that an organization has a standardized and repeatable process for assessing the security of the IT solutions it implements.  My goal with today’s post is to provide some recommendations on…


Exploiting MS14-066 / CVE-2014-6321 (aka “Winshock”)

Written on:November 29, 2014
are closed

Introduction I think enough time has passed now to provide a little more detail on how to exploit MS14-066 schannel vulnerability (aka “Winshock”). In this post I won’t be providing a complete PoC exploit, but I will delve into the details on exactly how to trigger the heap overflow along with some example modifications to OpenSSL so you can replicate the issue yourself. This vulnerability was announced while I was on…


Windows OLE RCE Exploit MS14-060 (CVE-2014-4114) – Sandworm

Written on:October 22, 2014
are closed

This recent exploit (dubbed “Sandworm”) took advantage of a vulnerability in which a specially crafted OLE object could allow remote code execution. In the case of the live sample exploit PPSX file I examined, it automatically downloaded the payload from a remote SMB share. I won’t rehash much of the details that others have covered but if you want to read more, here are some resources: Microsoft Security Bulletin: https://technet.microsoft.com/en-us/library/security/ms14-060.aspx Original Discovery by…