Auditing CSP headers with Burp and ZAP

Content Security Policy (CSP)  is a HTTP header that instruct the browser to limit resource loading of media, styles and scripts.

As you may know, CSP is not adopted yet by industry. Multiple surveys have already been made about the adoption of the security header [1] [2] [3]. Even so, it does not mean that we cannot prepare ourselves for the technology. For this purpose, we have built a Burp and ZAP extension to automate the most common validations called CSP Auditor.


The extension

The first component is the passive scanning that find various issues around the CSP configuration. The issues are visible from the Target tab when selecting the targeted host.

CSP Auditor Burp: Description of the weakness
Description of the weakness
CSP Burp Auditor : The weakness is highlight in the Raw Response Tab
The weakness is highlighted in the Raw Response Tab.

For manual review of the CSP header(s), an additional tab is available to display a readable version of the CSP configuration. It will display inherited properties. Those properties occur for example if script-src is missing but default-src is defined. The weak configurations are also colored according to the impact (orange for low severity and red for medium). This tab is available in most contexts such as History, Repeater and Intruder.

Detail view tab

The extension was submitted to the BApp Store and should be available in the next months. If you want to try it now, you can grab the plugin from the GitHub repository.


The passives rules

Now, what are the actual validations done by the extension? Here is the complete list. It can also be used as a checklist if a manual review is needed.

1. Unsafe inline

script-src: 'unsafe-inline'

In order to contain the JavaScript being executed, CSP allows only the execution of JavaScript within separate files.  With this directive enabled, an attacker will be able to use script html tag (<script></script>) or event handlers (onload, onerror, etc.) to load malicious JavaScript code.

2. Unsafe eval

script-src: 'unsafe-eval'

By default, CSP does not allow the execution of eval or setTimeout functions. The 'unsafe-eval' directive disable this protection. An attacker might be able to take advantage of those risky scripts using eval to trigger a XSS. The directive’s presence is not a confirmation that eval() or setTimeout() are used. Old JavaScript libraries are often the reason why ‘unsafe-eval’ is added.

3. Wildcards

script-src: *

By specifying a wildcard, an attacker will be able to load a script from any server. Having this sort of directive eradicate the XSS protection capability from CSP.

4. Risky hosts with known vulnerable JavaScript

script-src: *

Some libraries – namely AngularJS – have known payloads that allow the execution of script without using typical script html tag or event handler. In the case of Angular, CSP does not limit angular custom template syntax.

5. Allowing hosts that allow users’ content

script-src: *

Content delivery network (CDN) and software as a service (SAAS) are widely used. It is easy to introduce a permissive directive mistakenly. In the example above, the developer could have wanted to allow the hosts :, and Unfortunately, the wildcard cannot be used because anybody can register its own appspot subdomain (AppEngine).

6. Deprecated header name

X-Content-Security-Policy: ... / X-Webkit-CSP: ...

Some browsers have supported an experimental implementation of CSP with different header names. Now that the CSP specification 1.0 is out the older header should not be used.



This extension can be added to your web application assessment arsenal. However don’t expect to find a majority of sites implementing an efficient protection against XSS. Inline scripts are still widely used.

We cannot expect applications to be rewritten completely but, we can expect that the web frameworks will eventually adopt the standard. CSP Level 3 and its “nonce-source” are likely to make the adoption easier.



Content Security Policy Reference : A handy reference to quickly getting started

CSP 2015 by filedescriptor: Article describing the remaining attack vectors once CSP is configured properly.

XSS without HTML: Client-Side Template Injection with AngularJS by Gareth Heyes: One of the most common CSP bypass

CSP Auditor on GitHub : Get the source code of CSP Auditor

CSP Bypass (Burp plugin) by Joe Moloch : Burp extension similar to CSP Auditor written in Python.

Content Security Policy : Level 1

Content Security Policy : Level 2

Content Security Policy : Level 3

Detecting Hidden Backdoors in PHP OPcache

In this article, we will be looking at the strategies to detect and analyze malware hidden inside an OPcache file. If you haven’t read our previous article about hiding a binary webshell inside a PHP7 OPcache file, we suggest reading it before moving on.


Dangerous index.php.bin
PHP executing the malicious OpCache first

With the exploitation technique used in our last article, it is possible for an attacker to conceal malware inside OPcache files. In a real life scenario where a Web server has been compromised, it may be difficult to detect infected OPcache files as there is a multitude of obfuscation techniques that can be used in order to avoid detection. Not to mention that current tools are mostly made to scan source files. It is also strenuous for malware researchers and incident response teams to analyze cache files because of their peculiar format..

With this in mind, we’ve developed two tools that could help find (1) and understand (2) hidden backdoors inside OPcache files. You can find the repository for these tools here.

1. OPcache Malware Hunter

As we’ve mentioned earlier, current tools only scan source files when it comes to detecting PHP malware. In a scenario where an incident response team doesn’t know where an attack came from, it might be useful to have a tool that also checks OPcache files for infections. In that manner, we’ve created a simple malware hunter which finds potentially infected OPcache files.

The malware hunter takes the cache directory and the system_id  and uses it to determine the location of the corresponding source code. Using the source code, the tool will compile its own OPcache file using the settings defined in the php.ini, compare it to the original cache files and flag the files that differ. Using this technique, we can expect to have a high level of accuracy as any changes in an OPcache file will be caught by the tool, no matter how obfuscated the contents of the cache file is.

Here’s an output sample showing the hunter in action currently parsing both the production cache files as well as the ones generated by the malware hunter  :

OPcache Malware Hunter
OPcache Malware Hunter

If a potentially infected file is found, the malware hunter will generate an HTML report containing more information.

Potentially infected files
Potentially infected files

Browse to the generated hunt_report folder and open the index.html  page :

Main report page

Clicking on any link will open the report for that file showing the differences between the original file and the potentially infected file :

Example report
Example report

In the image above, the left column represents what the original cache file contained; the right column represents what the current cache file contains. We can see that our cache file has been replaced with a webshell.  This is the original code for the malware :

It is important to note that malware hunter is designed to be run on the system that generated the cache files. Malware hunter requires access to these cache files, source files and the same PHP configuration file to successfully detect compromise.

2. OPcache Disassembler

Disassemblers are extremely useful for malware analysis. In the case of OPcache files, these files are essentially bytecode representations of the corresponding source code, analogous to Java and Python bytecode. Because of the nature of OPcache files, it seems appropriate to introduce its own disassembler to help analyze the behavior of malicious code in the aftermath of an attack.

How It Works

The OPcache disasssembler provides two display options : syntax tree and pseudocode.

The syntax tree option provides a hierarchical view of every opcode, function and class in call order. Each opcode is then segmented into three parts (operand 1, operand 2 and result) as shown below :

Syntax tree extract
Syntax tree extract

Although the syntax tree view provides some information, the pseudocode display will make things a lot more readable. Running our disassembler with the -c option on the same file yields a friendlier output.

Pseudocode extract

With a little help from the official opcode documentation, the pseudocode becomes much simpler to understand. Here, our malicious file fetches the _GET  variable and checks if 'test' is set. We can assume the original PHP code was : isset($_GET['test']).

For OPcache files containing functions and classes, the disassembler outputs PHP-like syntax to improve readability. Syntax highlighting has also been added for the same reason:

Disassembled classes and functions

With malware analysis in mind, we can use our tool to roughly recreate what the original PHP file looks like. In the disassembled code above, at lines 7 to 13, we can see the opcodes used for the webshell:

  • Lines 7 to 9 stores the value of $_GET['test']  inside a variable called !1
  • Line 10 jumps to line 15 if a certain condition is not met
  • Line 11 to 13 calls the system function using the value of !1 as a parameter.

Here is the original source code for comparison, the webshell is shown in the last two lines:

Original Source Code


The disassembler and malware hunter can be quite useful in your Web server forensics toolkit. In the event of an attack, these tools can help detect the source of a breach and provide additional insight into how these malicious files operate.

It would be interesting to see how this could be applied to OPcache’s memory caching.


PHP Malware Finder by NBS System
PHP Backdoor Obfuscation Techniques by [email protected]
Understanding Opcodes by Sara Golemon
Zend Engine 2 Opcodes PHP Official Documentation

This blog post has been written by Ian Bouchard who is currently doing an internship with us before going to University. Ian has demonstrated extraordinary abilities and we are proud to offer him the opportunity to share his research with the world.

Oracle PeopleSoft: still a threat for enterprises

PeopleSoft_Ent_logoIn 2015, Alexey Tyurin from ERPScan presented at the Hack-In-The-Box Amsterdam conference [2][3] multiple attack vectors to defeat the widely used Oracle PeopleSoft (or PS) system. Many companies in various market verticals are relying on this massive and complex software to host confidential information about their employees, their students or even about the financial results of the company. Furthermore, many corporations are exposing this platform on the Internet, especially when relying on PS for career portals or student portals. A year later, I am still amazed to see publicly accessible systems or internal PeopleSoft deployments during our intrusion testing practice that are vulnerable to these common attack vectors. These deployments fail to deliver a useful result, putting the entire company workforce identity at risk. The following post will explain how to attack the PS_TOKEN, as well as describe our contributions to John the Ripper and oclHashcat in order to speed up the cracking process.

TockenChpoken Attack

During the presentation, Tyurin explained and demonstrated a way to attack the SSO functionalities of the PeopleSoft deployments. In a nutshell, the idea behind this technique is to break the SHA1 signature contained in the PS_TOKEN, and gather the PeopleSoft node password. The node password is used as a trust entity, just like a pre-shared key system. An attacker gaining access to this information will give them the ability to generate a valid PS_TOKEN for any users of the platform, allowing them to completely bypass the need of authentication. In other words, it means a potential access to the default PS user or a DBA access level. Ouch! The worst part is there is a working tool available, and almost all phases of this attack can be conducted offline, so no obvious traces will be logged in the remote system. A nightmare for incident handlers to detect the breach in a timely manner.

Adding Brute-Force Capabilities

While the ERPScan tools are working perfectly to perform dictionary attacks on the node password, sometimes heavier attacks like brute force are required to break the signature. In a recent mandate, no word lists were effective, so our team had to roll up our sleeves and code a dynamic format for the popular John the Ripper software.

Based on the ERPScan’s tool source code, the algorithm used by PeopleSoft to hash the signature is fairly simple: SHA1(salt+utf16le(password)). In other words, the SHA1 signature is the hash of a salt (which is derived from the token variables) concatenated with the node password encoded in UTF-16. If you use John the Ripper with the jumbo patch you will notice that the code was recently fixed to support salts containing null bytes. Now, you can add this function in your “dynamic.conf” file :

Please also note, the SaltLen variable may need to be adjusted according to your setup. In our example, we tell John the salt has a maximum length of 150 bytes.

While this dynamic format can leverage CPUs to crack the password, the time required to break a long and complex password could take years. Obviously, that could not work for our assessments or intrusion tests, so we had to change our approach. The solution was to contribute a new mode in oclHashCat.

GPU Cracking With oclHashcat

The requirements to create a new mode for oclHashcat are quite simple: you need to build the parser for the proper hash/salt format, handle the core storage of the data, build the OpenCL kernels for the cracking algorithm, and code the unit tests. Martin Lemay and I were able to contribute PeopleSoft’s PS_TOKEN hash cracking to the oclhashcat project and make it work, of course, with the great guidance and the help of Jens Steube for the OpenCL kernels. It has been integrated in the project’s master branch. As a result, we can now achieve much higher cracking speed: 4.3 billion hash per second on a single cracking node.

Screen Shot 2016-05-02 at 2.23.26 PM

Now, with this new mode, you will be in a better position to brute force any PS_TOKEN SHA1!


There are no reasons to keep your enterprise at risk of such attack, especially when the workarounds are so easy to implement. Three options are available:

  1. Disable SSO completely on PeopleSoft. That way, you would no longer have any token. Unfortunately, sometimes SSO is required, this is a feature after all.
  2. Use a strong password for the node. No reason to keep the default or use a dictionary based word. The system allows a maximum of 24 characters, you should take this opportunity and create a strong and complex password.
  3. Use certificates. Using certificates as trust entities would add robustness to your setup.

What We Observed In The Wild

Unfortunately, many corporations do not implement any of the recommendations outlined above. You can find a lot of Oracle PeopleSoft deployments simply by using Google. Also, you will notice that a quick and naïve testing of the PS_TOKEN will reveal the use of very weak node passwords, even the default is still in use at times. Of course, I did not try the last piece of the attack which is to generate a valid token because of the legal impacts, and I do not recommend the readers to do it either. That being said, these companies or entities are exposing themselves to huge risks even if the mitigation measures are very simple to implement. A successful breach could leak hundreds or thousands of employees’ personal identities. The impact would be devastating for them, and also for the company’s reputation. So, if you are using PeopleSoft in your company, now you know how to mitigate your risks, and what could happen if you don’t!

About the author

François Gaudreault manages the team of Ethical Hacking at GoSecure. He specializes mainly on methodology and improving practices. He also ensures management and test execution, as well as delivery of projects for customer satisfaction. You can follow him on LinkedIn.

Binary Webshell Through OPcache in PHP 7

In this article, we will be looking at a new exploitation technique using the default OPcache engine from PHP 7.  Using this attack vector, we can bypass certain hardening techniques that disallow the file write access in the web directory. This could be used by an attacker to execute his own malicious code in a hardened environment.


Speeding up the web with PHP7 by Rasmus Lerdof

OPcache is the new built-in caching engine with PHP 7.0. It compiles PHP scripts and sets the resulting bytecode in memory.

It also offers caching in the filesystem when specifying a destination folder in your PHP.ini :

Inside the above folder, OPcache stores its compiled PHP scripts under the same folder structure as its corresponding PHP script. For example, the compiled version of /var/www/index.php will be stored in /tmp/opcache/[system_id]/var/www/index.php.bin

The system_id  shown above is an md5 hash comprised of PHP’s version, Zend’s extension build ID and the size of various data types. In Ubuntu’s latest distribution (16.04), the system_id produced by the current version of Zend and PHP (7.0.4-7ubuntu2 at the time) is 81d80d78c6ef96b89afaadc7ffc5d7ea. The hash is most likely used to ensure binary compatibility between installations. The directory is created by OPcache when caching its first file.

As we’ll see later on, each OPcache file will also have a copy of that system_id  stored in a header field.

What’s interesting about the OPcache folder, is that all the folders/files generated by OPcache (everything under /tmp/opcache/) will have write permissions as the user running the service.

Here are the permissions inside the OPcache folder:

As you can see above, the folders generated by OPcache are writable by the  www-data  user. If we have write access to the OPcache directory, we could execute arbitrary code by overriding cached files with a compiled webshell.

Attack Scenario

First, we must obtain the location of the cache folder ( /tmp/opcache/[system_id]) and the location of the targeted PHP file ( /var/www/...).

For the sake of simplicity, let’s assume that the website has left a phpinfo() file, from which we can obtain the cache folder location, the file source code location, and all the fields necessary to calculate the system_id. (We’ve created a tool which calculates the system_id  from a website’s phpinfo(). You can find it on our GitHub repository).

It is important to note that the targeted website must also be vulnerable to unrestricted file upload.

Let’s assume that the default  php.ini  settings are used in addition to:

Here’s how the attack works:

We have found an unrestricted file upload vulnerability on a website where the  /var/www/ permissions have been hardened. Our goal is to replace /tmp/opcache/[system_id]/var/www/index.php.bin with our own code which includes a backdoor.

Vulnerable website example
Vulnerable website example
  1. Create a malicious PHP file locally named index.php containing a webshell :
  2. Set the opcache.file_cache  setting in your PHP.ini file to the destination of your choice.
  3. Run a webserver using php -S and then send a request for the index.php  file to trigger the caching engine. A simple wget  will do the job.
  4. Navigate to the cache folder specified in step #1; you’ll find a file called index.php.bin . That’s the compiled version of our webshell.

    index.php.bin generated by OPcache
  5. Since the local system_id  will most likely be different from the target’s, we have to open index.php.bin  and modify our system_id to replace it with the target’s. As previously mentioned, system IDs can be guessed, bruteforced or computed from phpinfo() ‘s server information.  The system_id to replace is located right after the file signature:

    Location of the system_id
    Location of the system_id
  6. Using the unrestricted file upload vulnerability, we upload our file to /tmp/opcache/[system_id]/var/www/index.php.bin.
  7. Refreshing the website’s  index.php  will run our webshell.

Final result

Going Deeper

There are at least two configurations in the  php.ini settings that would create alternate behaviors.

  • Disabling file_cache_only
  • Enabling validate_timestamp

Bypassing memory cache (file_cache_only = 0)

If memory cache is prioritized before file cache, overwriting the OPcache file will not execute
our webshell. This restriction can be bypassed if the server running our vulnerable website is restarted. Since the memory cache will have been emptied, OPcache will use the file cache to fill the memory cache, thus executing our webshell.

With this behavior in mind, it is still possible to execute our webshell without the need of a restart.

Under frameworks like WordPress, there are some deprecated files that are still publicly accessible (for example : registration-functions.php).

Since these files are deprecated, they are never loaded and do not have a cached version in memory or in the filesystem. After uploading our malicious payload ( registration-functions.php.bin ) and requesting the associated webpage ( /wp-includes/registration-functions.php), OPcache will run our binary webshell.

Bypassing timestamp validation (validate_timestamps = 1)

If timestamp validation is enabled, OPcache will check the timestamp of the requested PHP source file and compare it to the timestamp header field of the cache file. If they do not match, the cache file is discarded and a new one is created. To successfully bypass this restriction, an attacker must know the timestamp of the targeted source file.

That being said, under frameworks like WordPress, the timestamps for the source files are available as they remain intact upon extracting the zip or tar archive.

WordPress’ /wp-includes folder

What’s interesting about this, is that some files haven’t been modified since 2012 (notice the  registration-functions.php  and registration.php files). Therefore, these timestamps will be the same across multiple versions of WordPress. Knowing the timestamp, an attacker can then modify his payload accordingly and successfully override the cache, complying with the  validate_timestamps  setting. The timestamp is located 34 bytes from the beginning of the file:




Here’s a quick demo showing how the attack works :


As we’ve mentioned briefly, we also have a GitHub repository. This repository contains our 010 editor template, the system_id scraper tool and a copy of the demo website shown in this article. Feel free to help in the development of these tools and to submit pull-requests.


In summary, this new attack vector is an additional exploitation technique tailored to specific hardened environments. It is not a universal vulnerability affecting PHP applications. With the arrival of PHP 7.0 in major distributions such as Ubuntu 16.04, this attack vector reinforces even more the need to audit your code for file upload vulnerabilities and to be wary of potentially dangerous server configuration.

A new post will be coming soon where we will present a more in-depth view of OPcache files.


This blog post has been written by Ian Bouchard who is currently doing an internship with us before going to University. Ian has demonstrated extraordinary abilities and we are proud to offer him the opportunity to share his research with the world.

Your credentials at risk with Lansweeper 5

Lansweeper website

As a penetration testers, we rarely have to find ‘zero day’ vulnerabilities or perform ‘bug hunting’ in order to compromise Windows Active Directory Domains. However, in one of these rare cases while performing an internal penetration test for a client, we had to do so.  Lansweeper is an inventory software that scans your network in order to gather system information such as patch level, network interfaces, resources status, etc.   We were fairly surprised during this test when we were able to access Lansweeper 5’s dashboard with a regular user account.  Our customer was actually shocked and swore that he had configured only Domain Admin access on this Web interface.  According to him, a recent update must have reset the login permission on the dashboard.  At first, we were doubtful that explanation would hold up to scrutiny. Our curiosity increased when we realized that Domain Admin accounts, SSH keys, Linux root passwords and all the “juicy stuff” one normally finds in a password vault is stored on a Lansweeper server.  The result of our experimentation: Three vulnerabilities were identified that led to the full compromise of our customer’s network infrastructure. Later that week, our client sent us a copy of an email exchange with Lansweeper (formerly Hemoco) confirming the issues reported and that everything should be fixed by version 6.

Responsible Disclosure Attempt

We contacted Lansweeper and tried to engage in a responsible disclosure agreement with them. We couldn’t reach a formal agreement in a timely fashion but in order to protect the public we decided to publish all the details in this blog post. Because Lansweeper seemed convinced their new version would address existing security issues, since version 6 has been released, we believe the potential for harm in release these vulnerabilities to be much lower than the benefits to users of the product.

Vulnerabilities discovered

Lansweeper 5 was installed on a Windows Server machine and was using an MSSQL database. With the objective of recovering the credentials from the Lansweeper database, the following exploitable vulnerabilities were discovered from the dashboard Web access;

  • Default Database credentials
  • Leakage of sensitive information from MSSQL Error Messages
  • Broken encryption for credential storage

Note that other vulnerabilities may exist in the application, testing was performed and aligned with our customer’s needs and was not an extensive application security assessment.

Those three vulnerabilities could lead to the compromise of your stored credentials from two different vectors: the Web interface and the exposed MSSQL database. All captures from the following analysis originates from my lab and reflects our customer’s installation.


Default Database credentials

Default installation of Lansweeper 5 using an MSSQL Server as a back-end uses default, static credentials to store and query data from its database. The connection string can be recovered from the web.config file in the web folder of the application. There are no easily accessible means to change these database credentials other than updating the web.config flat file.

If an attacker has access to port TCP 1433 of the MSSQL Server hosting the lansweeperdb database, he can simply put these credentials in order to gain full access to the lansweeperdb database.

“lansweeperuser” privileges

The table where credentials are stored is: tsysCredentials. The capture below shows generic example of the table schema and content.

tsysCredentials table

These stored credentials are not salted cryptographic hashes, they are using a “reversible” encryption scheme that will be discussed later. Although accessing MSSQL database directly from the network is really convenient for the attacker, it would be much harder to access if the database socket is bound locally to localhost. This is in fact the scenario we had to deal with in this particular customer mandate and we will show you an alternative way of retrieving these passwords from the Web user interface.

Leakage of sensitive information from MSSQL Error Messages

The application offers a rich reporting mechanism with SQL scripting capabilities. Developers did take special care to avoid any request that would output the content of the tsysCredentials table into a report or query results.  However, the SQL scripting feature (Configuration->Database scripts) displays verbose error messages which can be abused in the same way you would for an Error-Based MSSQL injection. An example is shown in the following screenshot:

Exploiting MSSQL Errors
SQL Server Error Message

Usernames and passwords can be retrieved just by querying the database with the proper values. A simple division by 0 does the trick to display the content of the SELECT statement. In order to access the SQL Scripts feature you need to authenticate to the dashboard and specific roles need to be enabled for your account. However, in the case of our customer, the Lansweeper access control settings have been cleared out by a recent update so default credentials with default roles allowed us to extract the passwords.  It should be noted that we were not able to confirm with the vendor if Lansweeper’s management access control settings are usually cleared on update.  The advice here is that you should review and test your Lansweeper access control settings after every Lansweeper update. Now that we have extracted the encrypted passwords from the database lets try to recover them.

Broken encryption for credential storage

When storing credentials with a use case like Lansweeper’s – the remote management of computers and servers – passwords need to be reversible by design.  However, special care should be taken when storing those passwords and, in the case of Lansweeper, that might have been overlooked.  We always recommend dealing with a qualified security expert when designing, implementing and testing a cryptographic solution.

The main problem here is the key location. From the capture of the tsysCredentials table scheme and the above content, no keys were extracted or so it seemed.  Neither in the web.config file.  Since the application is compiled with the .NET framework, it did not take long to find out that part of the encryption key is stored with the ciphertext.  The remaining part of the key is hard-coded and obfuscated in the code itself.  This turns out to be a bad key handling solution because it is tied to the software itself and not the specific installation or the specific password entry. Furthermore both the key and the ciphertext can be extracted via the aforementioned SQL injection. A better design would have required both the Web management interface and the server host to be compromised in order to steal these credentials. In plain terms the impact is that any encrypted password from any Lansweeper 5 instance can be decrypted without any other requirement.

Here is a capture of our C# proof of concept tool that was used to recover the password in our lab as well as our customer’s passwords:

Lansweeper Password Recovery Tool

That’s about it!  In a nutshell, if you are using Lansweeper 5, remember that password recovery is possible to anyone having direct access to the database (via default hidden credentials) or the Web user interface (via SQL injection).  It would have been much better if keys were stored on the Windows system using native cryptographic APIs.

This issue has been fixed in version 6 of Lansweeper. There is a changelog entry that states: More secure password encryption thanks to an on-server encryption key.

EDIT: The following link was brought to our attention which we missed during our (too) quick look on the web: Good job at Rapid7 guys for providing the public with the best security tool set!


As stated by Lansweeper, Lansweeper 6 should include new security design and security fixes. We will take a look at the solution now that it is released. Meanwhile, here are some guidelines to protect your credentials:

  1. Review your access control settings on your Web user interface now! Especially if you upgraded. Make sure only authorized people have access to the web interface and force TLS usage.
  2. Do not use the default database credentials. You can change the password for a strong one, and update your web.config file in your Lansweeper installation folder. You should contact support if help is required.
  3. Do not expose your database connection on the network without any access control.

Of course, the same recommendations would apply to any other software vendor where critical assets such as high privilege credentials are digitally stored.

About me

Mr. Martin Lemay, CISA, OSCP, OSCE, GXPN, GMOB

Security Consultant & Penetration Tester @ GoSecure Canada Inc.

E-Mail: [email protected]

Mr. Martin Lemay is a full time security consultant and penetration
tester for the security firm GoSecure Canada Inc.  He is actively
involved in all aspects of security validation mandates including
internal and external infrastructure testing, application security
assessment, social engineering and physical access intrusion.  Since his
enrollment at GoSecure Canada Inc., he performed numerous mandates in
the banking, insurance, airline, energy, telecoms and mid to large scale
retail industries.  Involved in the security world, he also
spoke and trained security topics for schools, colleges and participated
in various security events in Canada.

On the road to AtlSecCon

AtlSecCon is almost there! Philippe and I are pretty excited to be speaking there this year!

Atlantic Security Conference

Here’s a quick rundown of our presentations:

The new wave of Deserialization Bugs

Philippe will demystify Java deserialization flaws.

The new wave of Deserialization Bugs

Recently, there have been several deserialization bugs released. In 2015, many Java softwares – including WebLogic, Jenkins and JBoss – were found vulnerable because of a common bug pattern. This talk will present the risk associated with deserialization mechanism and how it can be exploited. While a fix is available for some of the known vulnerable applications, your enterprise might be maintaining a proprietary application that is at risk. A tool will be presented to identify the vulnerable pattern. This vulnerability can be applied to any languages. Examples will be given for PHP and Python.

Update: Here are the slides for Philippe’s presentation.

Internet of {Things,Threats}

ESET‘s Thomas Dupuy and I are covering real-world malware encountered in the Internet of Things space. Spoiler alert: Internet of Things malware is actually Linux malware targeting embedded systems through Telnet or SSH protocols.

Internet of {Things,Threats}

More and more devices are connected to the Internet. Under the moniker “Internet of Things” (IoT) these “things” generally run an embedded Linux system of the MIPS or ARM architecture. The unresolved problem of software updates and short vendor support cycle combined with the lack of effort into systems security and application security makes these devices an easy target. This last year we have analyzed several malware samples targeting these architectures. Internet accessible embedded systems are being compromised via
vulnerabilities (like Shellshock) or because of their weak default configuration.

Our presentation will cover some of the analysis we performed:

* Linux/Moose, a malware that propagates by itself and perform social network fraud on Twitter, Facebook, Instagram and more
* LizardSquad and foreign actors that are leveraging embedded systems to perform distributed denial of service attacks (DDoS)
* Win32/RBrute, desktop malware that changes router settings in order to infect more victims. This is distributed by the Sality botnet.
* An Exploit Kit that leverages router vulnerabilities through a Web browser to perform “DNS poisoning”

Finally, some advice will be given to the audience in order to help protect
themselves, their organizations and their families.

See you there!

Update: Here are the slides for our presentation. As usual all of our slides, talks PDFs and demos are available and indexed in our github presentations page.

XSS for developers

As a follow-up to the conference given at Confoo few weeks ago, we are doing a focus article on the same topic. The presentation was giving an overview of the modern XSS attack vectors and filter bypass. In this blog post, we will take a closer look at XSS in the context of .NET applications.

This article is intended to be a simple checklist for MVC developers or security auditors. Defensive measures can be put in place at various layers including the template files (Razor or ASPx Forms), the Request Validation feature and the client-side (browser) filters.



Lets remind ourselves that the root cause of Cross-Site Scripting is missing  encoding of user inputs. Having the right encoding at the source is obviously the true antidote to this class of vulnerabilities. Luckily, the template engine available in .NET is doing some encoding by default.

Here is a list of vulnerable templates using the Razor template engine. The examples assumes that the values displayed are controlled by the user.

  • Unsafe HTML

If direct binding was used (@ViewBag.Name), it would be encoded properly the value for the HTML context. In the HTML context, special characters are replaced by XML entities such as &lt; , &gt; and &quot;.

  • Unsafe Html.Raw in attributes

In this unsafe example, the developer might have disabled the encoding because he realizes that the default encoding to HTML entities is not appropriate for URLs. Special characters are replaced by entities (ie " becomes &quote;). A context specific function should have been used. Server.UrlEncode() can be used to encode safely a value in an URL.

  • Unsafe action link

With the first ActionLink, an attacker could use the URL “javascript:[...]” to trigger malicious JavaScript. A validation of the URL is needed in the controller.

The second ActionLink example could lead to an Open Redirect. It does not lead to arbitrary JavaScript execution but it could be used as an effective means for stealing credentials or phishing attacks.

  • Unsafe “unquoted” attribute

Attributes in Razor template can become vulnerable to XSS in two scenarios: when Html.Raw is used (see Unsafe Html.Raw in attributes) or when an attribute is not placed in quotes. Razor does not enforce the use of single or double quotes.

Here a malicious user controlling the ImageId variable could add a JavaScript event such as onload or onerror. The following snippet illustrate a basic injection.

  • Another example with unquote attribute that could lead to DOM clobbering

In this particular case, a form with the injected properties “name” and “id” can lead to shadow JavaScript global variables that are injected later in the DOM. It is a very capricious attack vector that works for very specific property names. If you want to know more about it, you can read Gareth Heyes article on DOM clobbering.

  • Script context

Finally, the script context is slightly more at risk because the value are escaped to HTML entities by default. In the example above, it is possible to inject JavaScript because HTML special characters are escaped but not blackslash (\).

In the previous example, the blackslash escape the terminating single quote. This cause the string to actually close on the following single quote. The second parameter can then be use by the attacker introduce malicious Javascript.

To summarize the correct guidelines, we have create a cheat sheet that include code examples  for the different contexts. It is intend to be a quick reminder for developers or security auditors doing code review. Feel free to share this cheat sheet to developers of your organisation.

Security Cheat Sheet @ GitHub

Request Validation

RequestValidation error message (input blocked)

Request Validation is a built-in filter to It is an additional layer of protection that is intended to block malicious requests. It will stop suspicious request if the parameters contains any HTML tag.

The Request Validation module is a feature that is integrated to framework. It is decoupled from the View ASP forms or Razor Templates. It can be view as a Web Application Firewall for XSS specifically.


Any transformation between the moment the request is received and the construction of the final HTML view can lead to filter bypass. If an HTTP parameter is URL decoded two times, it is enough to bypass the filter.

One of the common transformation is SQL server character conversion to ASCII. It can occurs if the column data type is not unicode (VARCHAR vs NVARCHAR). SQL Server will convert the Unicode character FF1C to 003C. This is sufficient to bypass RequestValidation to create a Stored XSS.

Character Character After storage
U+FF1C (%EF%BC%9C) U+003C (%3C)
U+FF1E (%EF%BC%9E) U+003E (%3E)

A malicious payload using this bypass would look like this:

Once the value would be output, it will be display as < (u+003C) and > (u+003E).

Nonetheless, it is still recommended to keep RequestValidation as a extra safe guard. As the official documentation stated, it is not a replacement to validation and proper encoding.


Client-side filters

Modern browsers also provide an additional layer of protection. Chrome, Internet Explorer and Edge have a filter mechanism that can detect some reflected XSS. The browsers will find some patterns were HTML tags are passed in the URL or POST parameters and are reflected in the page.

Browser XSS Filter
Mozilla Firefox None
Google Chrome Yes
Internet Explorer / Edge Yes

The filter can also be forced with the header X-XSS-Protection: 1. This has limited benefits because the filter is already enabled by default in Chrome, Internet Explorer and Edge. However, for some hosts (like localhost), IE/Edge will disable its filter by default.

Additional configurations

  • X-XSS-Protection: 1; mode=block : It is possible to block the loading of the page if a malicious pattern is detected. It is intended to avoid unwanted scripts being disabled.
  • X-XSS-Protection: 1; report= : With this directive the browser will report blocked parameters to the URL specified in the header.

Even though  the filters have been proved to be effective, there is no commitment from the Chrome and Edge teams to provide a complete coverage.


Browser filters do not cover stored XSS and some DOM XSS. They also have some known bypasses. Usually, a transformation will lead to filter bypass. In the following example, the value is properly HTML encoded. However, JavaScript will read the attribute and print it. It will trigger an XSS because once the attribute is read the entities are decoded.



This article should cover the key elements when it comes to safe HTML encoding and XSS prevention. You should now be aware of some of the limitations of each components. It should also stand out that security is not a silver bullet. Relying on a single protection will increase the probability of malicious payload passing through.

As mention previously, feel free to share this cheat sheet to developers of your organisation. The cheat sheet will evolve in the next month to include additional languages and frameworks. The project is open for contribution and reuse.


GoSecure proud to support AtlSecCon and NorthSec 2016

At GoSecure we believe that improving the security posture of Canadian companies has to happen through better security awareness and education of IT professionals.

This is why that, in addition of running our own conference GoSec in Montreal, we are major sponsors of top community conferences like AtlSecCon (Halifax, NS) and NorthSec (Montreal, QC).

We realize that running these important events for our communities requires dependable staff for a portion of the year. That is why GoSecure is proud to have volunteers on staff in order to contribute to these organizations with more than monetary means.

Looking forward to meet you at these events (or any other event)!

About AtlSecCon

Atlantic Security Conference

The only security conference in Atlantic Canada focusing on bringing some of the worlds brightest and darkest minds together with one common goal – to expand the pool of IT Security knowledge beyond its typical confines. Established 2011.

About NorthSec

NorthSec is the biggest applied security event in Canada, aimed at raising the knowledge and technical expertise of professionals and students alike. We are determined to create a high quality security forum composed of a two day single track conference by the brightest in their field of expertise, followed by an intense 48 hour on-site CTF contest.

Internet of Threats, an OWASP Montreal Presentation

Our own Olivier Bilodeau will be presenting with Thomas Dupuy of ESET Canada Reseach about malware affecting “Internet of Things” (IoT) devices. A free event hosted by OWASP Montréal in downtown Montreal.

The presentation will be in French with the slides in English.

Internet of Threats

Here is the abstract:

More and more devices are connected to the Internet. Under the moniker “Internet of Things” (IoT) these “things” generally run an embedded Linux system of the MIPS or ARM architecture. The unresolved problem of software updates and short vendor support cycle combined with the lack of effort into systems security and application security makes these devices an easy target. This last year we have analyzed several malware samples targeting these architectures. Internet accessible embedded systems are being compromised via vulnerabilities (like Shellshock) or because of their weak default configuration.

Our presentation will cover some of the analysis we performed:

  • – Linux/Moose, a malware that propagates by itself and perform social network fraud on Twitter, Facebook, Instagram and more
  • – LizardSquad and foreign actors that are leveraging embedded systems to perform distributed denial of service attacks (DDoS)
  • – Win32/RBrute, desktop malware that changes router settings in order to infect more victims. This is distributed by the Sality botnet.
  • – An Exploit Kit that leverages router vulnerabilities through a Web browser to perform “DNS poisoning”

Finally, some advice will be given to the audience in order to help protect themselves, their organizations and their families.