SECFORCE          
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 the ‘Tools’ Category
 

Tunna v1.1a SOCKS!

Monday, November 24th, 2014

Tunna is a set of tools which will wrap and tunnel any TCP communication over HTTP.

Due to popular demand, in this new version, Tunna (v1.1a) can be set up to be a local SOCKS proxy, that will accept any TCP traffic and send over to the webserver using HTTP requests. The traffic will be unwrapped at the server and forwarded to the specified address/port. Tunna effectively pivots connections through a webserver; thus bypassing firewall restrictions.

 

Secondary functionality added in the new version:

  • Tunna is now able to connect to the local proxy (if exists) and through the internal proxy, then tunnel the connection to the webserver.
  • A standalone Tunna webserver has been added for situations were a webserver is not available.
  • Windows compiled binaries for both “Tunna Client” and “Tunna webserver” have been added.
  • Ping delay increases (up to 60 sec) whenever data is not received. This minimises network traffic to the webserver with a small hit on waiting time that should be unnoticeable.

Tunna v1.1a Changelog:

  • Added SOCKS4a support
  • Tunna webserver
  • Windows binaries
  • Support for UpStream Proxy
  • Removed Ruby version of Client

Usage:

  • python proxy.py -u <remoteurl> -l 8000

This will set up Tunna and start a SOCKS4a proxy server on port 8000

 

SOCKS Operation Details:

Tunna SOCKS

 

Local ports are “mapped” to remote ports. For this, a header is added in every HTTP packet sent to/from the webserver that shows the originating/remote port. Once the packet is received, the header port is read and the rest of the data gets redirected to the correct port on the local side.

Limitations:

The SOCKS server is a simple implementation based on SOCKS protocol version 4 RFC. Currently “SOCKS BIND” method is not supported and protocols such as FTP cannot be used.

 

Bypassing Firewall restrictions:

Tunna SSH

 

Inbound restrictions:

As in the previous version if inbound HTTP traffic is allowed a webshell or Tunna webserver can be used to pivot connections.

For example, an external user can upload a Tunna webshell (or use Tunna webserver) on a remote webserver and request a service on the local host or any other host that will normally be blocked by the firewall. The request will be forwarded to the webserver in the form of an HTTP request (must be allowed by the firewall). The webserver is going to establish the connection for the user and redirect all traffic to that service. Response data will be transferred back to Tunna’s client in the form of HTTP responses.

Outbound restrictions:

Tunna can be used in situations where the firewall restricts access to certain hosts or services.

A user controlled Tunna webserver is needed as well as HTTP access to the remote webserver.

For example, an internal user can set Tunna (client) as his system’s proxy and request any website/service that is blocked. The request will be forwarded to the webserver in the form of an HTTP request. The webserver will establish the connection to the requested service and redirect all traffic to that service. Response data will be transferred back to Tunna’s Client in the form of HTTP responses.

 

Up-stream proxy:

In many companies, internal connections to the internet go via an internal proxy that restricts access to certain services or websites. Tunna can be configured to use that proxy for requests to Tunna’s webserver.
Tunna will get the proxy settings from the system (internet) options and use them for all requests. If this is not possible, then the proxy parameters can be set up as an argument (currently DIGEST and BASIC authentications are supported)

 

Tunna webserver:

This is a python standalone webserver for Tunna. The functionality is the same as a webserver that has a Tunna webshell.

Usage:

  • python webserver.py -r 0.0.0.0:8000

Will start a Tunna webserver listening on port 8000

Append –ssl to add SSL support (https)*

* In Windows (webserver.exe) the certificate file (certificate.pem) needs to be present in the same folder as the executable

 

Tunna SOCKS webshells:

For Tunna to be used as a SOCKS server when webshells are used, an executable that will handle the SOCKS traffic will be uploaded to the remote webserver and executed.

 

Disclaimer:

As well as Tunna generating a massive overhead for every TCP packet, theconnections are tunnelled through a single channel using HTTP requests. Consequently, large amounts of traffic translate to large amounts of HTTP requests. When a Tunna webshell is used, then this can lead to a Denial of Service condition where the webserver will not be able to cope with all the requests.The standalone Tunna webserver is significantly less prone to DOS.

Some functionality is still experimental; therefore it is recommended that Tunna webshells are not to be used as a permanent solution.

Although the mechanisms for clean-up and graceful shutdown are in place, in certain situations,when a Tunna webshell is used andthe “SOCKS Server” executable is not properly stopped and/or removed from the disk; then it will require a manual clean-up.

 

Presentation: Tunna Presentation.pdf

Download: SECFORCE::Tunna

 

Reverse Engineer Router Firmware – Part 1

Thursday, April 3rd, 2014

This series will follow the process of reverse engineering router firmware with the purpose of discovering any vulnerabilities that could be used either remotely or locally to compromise the router. In this section I will mainly be covering how to extract/download the firmware alongside a very basic way to get a root shell on the firmware in this tutorial.

Firstly the firmware being analysed in this tutorial can be found here (for v8 of the TP-Link WR841N). In some cases, the firmware for your device of choice can be found by using your preferred search engine due to a lot of manufacturers making the firmware freely available for download, however due to the growing interest in the exploitation of embedded devices, it is becoming common practice to only have the firmware accessible by accessing the device physically i.e.. using a serial port or by manually dumping the flash memory.

General Linux RE Tools

  •  file – To determine if it is a valid file/file type.
  •  hexdump – a hex dump naturally.
  •  strings – similar to hexdump however presented in a readable format if possible.
  •  dd – To scrape data out of the bin file
  •  lzma – to decompress any LZMA files

3rd Party Tools

  • binwalk – to analyse the file for firmware headers and file systems.
  • Firmware Mod Kit – Bundle of scripts to automate the extraction process.
  • squashfs-tools – Can apt-get squashfs-tools for this. Bundle of tools to enable you to play with the squashfs in this tutorial

Initial Analysis

Generally the normal start to reverse engineering is to dump as much information on the file you can get using the standard Linux tools listed above. This should give enough information to determine where to go next for example in the hexdump you may find sqsh meaning that there is a squashfs on the file or perhaps spot U-Boot which is a well documented boot loader used frequently within firmware packages.

File Tool

The file tool essentially just tells us whether or not the file is a known file type and in some cases what kind of file it is e.g. data file.

You should see something similar to this:

Filetool

Which will confirm whether it is a readable/known file type or whether further investigation is needed. In this case we can see that it is (naturally) a data file.

hexdump

The hexdump tool is invaluable as it allows you to inspect the dump for any key phrases or words that can tell you what kind of system you are reversing as previously mentioned. The hexdump for this file should look like this:

Hexdump

The command above will pipe the results of the hexdump into a file (hexTP.txt) for further analysis. The -C sets hexdump to format the dump in Canonical hex+ASCII display making it easier to read. In this case we don’t gain all that much from the hexdump other than the manufacturer being TP-Link (which we already know) so the next step would be to try running strings on the .bin file to see if it gives us a more informative result.

strings

Strings is probably the most used and one of the best tools to start with as it displays all the printable data within the file. This can allow you to analyse the header of the file etc. Like we did with the hexdump, it is worthwhile piping the result of strings into a file for your own convenience to save having to re run strings every time you want to check something.

We find a few interesting phrases within the strings results:

stringsuboot

 

This was done just by opening the strings result file we found and searching for common boot loader names of file system names e.g. U-boot. This could also be done by grepping the file should you prefer. Now we know that the embedded device is using the U-boot boot loader and the version meaning that we can look up the documentation for it to gain a better understanding of the how the embedded device is designed.

Binwalk

Binwalk is a valuable tool to have considering it will scrape the bin file for any firmware headers or file systems that it may contain and then show you the offset of each of these sections should you wish to dd them. The binwalk output should produce:

Binwalkresults

Which gives us a wealth of information relating to the firmwares structure, from the boot loader it is using to the file system type. From these results we know that the firmware runs a Linux system on MIPS architecture, with a Squashfs file system that has been compressed using LZMA. It also confirms that the boot loader is indeed U-Boot as found in the strings results.

Extracting the Filesystem

Now comes the interesting section where we get to extract the contents of the file system held in the firmware image. With it being a Linux system it is safe to assume that the file system should contain the standard linux default folders where we could find some sensitive information e.g. the passwd or shadow file.

One of the ways that a lot of people will extract the FS is by using dd. However for the sake of time and ease, there are two main ways I would recommend for extraction.

The first is to use the -e parameter of binwalk which will automatically extract everything from the firmware image for you.

user@host$ binwalk -e <input file>

The second, and more efficient way of extracting is to use the extract-firmware.sh script that can be found in the Firmware Modification Kit. The reason for this is due to the fact that should you wish to modify the firmware and repack it, you can use the other script build-firmware.sh to do so. It saves a lot of time than manually extracting and handles all the offsets etc for you. The extract script will create a new set of folders within the fmk directory whereby you can find all the contents of the file system, the path should be /fmk/rootfs.

 

Coming Soon…

In the next part I will show you how to emulate the router architecture so you can try and run files that you extracted from the file system as well as how to get a root shell on the router!

 

Sparta – a Network Infrastructure Penetration Testing Tool

Tuesday, March 25th, 2014

What is it?

It is a known fact that all hackers like terminals but most (good) hackers also like efficiency and automating repetitive tasks. This is where SPARTA comes in.

SPARTA is a python GUI application which simplifies network infrastructure penetration testing by aiding the penetration tester in the scanning and enumeration phase. It allows the tester to save time by having point-and-click access to his toolkit and by displaying all tool output in a convenient way. If little time is spent setting up commands and tools, more time can be spent focusing on analysing results.

Have a look:

What are the goals?

– One of the most important goals of the project is the ability to fully customise what tools/commands you run from SPARTA. Every penetration tester has his/her own methods and toolkit and we do not want to change that. SPARTA tries to simplify the way you run tools and centralises their outputs, displaying them in a meaningful way.
– Automation of repetitive tasks is a must. You will always need to check for default credentials. You will always need to enumerate users. You always run certain tools when you find certain services. You can now perform these actions (on several hosts) in one click.

Any cool features?

– Nmap XML output importer
– Any tool that can be run from a terminal, can be run from SPARTA
– Default credentials check for most common services
– If any usernames/passwords are found by Hydra they are stored in internal wordlists which can then be used on other targets in the same network (breaking news: people reuse passwords)
– Ability to mark hosts that you have already worked on so that you don’t waste time looking at them again
– Screenshot taker so that you don’t waste time on less interesting web servers

What are the requirements?

– A Linux OS preferably Kali Linux as all the tools are already there
– A few extra python libraries

This project is very much a work in progress but hopefully the first release will be out in a few months. So stay tuned! :)

SECFORCE will be presenting at OWASP

Monday, March 17th, 2014

SECFORCE will present Tunna framework and a number of techniques penetration testers can benefit from to bypass network firewalls.

The presentation will include common scenarios in which HTTP tunnels can be use to bridge the gap between web application testing and infrastructure testing.

Please find information about the conference here.

Making Tunna (… or bypassing firewall restrictions with HTTP tunneling)

Friday, August 9th, 2013

A couple of months ago SECFORCE was set to create the ultimate webshell. The idea behind it was to include all the tools a pentester needs in one webshell and make our lifes easier by for example dropping a meterpreter shell on the remote webserver with as less user interaction as possible.

Soon it was apparent that it would be much “cooler” for the webshell to communicate with a meterpreter shell without the need for meterpreter to expose or bind an external port. The benefits of it are obvious – this would effectively bypass any firewall rules in place.

It was realised that this could be a nice tool on its own so the project was forked and development started. Some time later a set of webshells and the client proxies were created. The task was not as easy as it seems, mostly because it is hard to keep it simple and at the same time make the same code work across different languages. Still there are some “programming language” quirks that could not be bypassed or made transparent to the end user. Given the different technologies in play (web servers / web languages / client languages) and all the possible combinations it would be very hard to tackle some of the issues and make it seamless to the end user without loosing some of the tools flexibility. Having said that, Java proved to be the most problematic language of the whole bunch – this needs to be said. Java was eating bytes in large packets – reasons for this are still not obvious – making both debugging and optimisation a pain. Apart from that, the PHP webshell also works in a somehow different way where it stalls a thread on the remote server to keep the connection alive. However, the latter is seamless to the user.

Tunna Framework - Penetration Testing

Tunna Framework - Penetration Testing

What Tunna does is to open a TCP connection (socket) between the webserver (webshell) and a socket on the local machine (webserver). It is also possible to open a connection to any other machine but lets keep this example simple. The client also opens a local socket and starts listening for connections. When a connection is established on the local client any communication would be sent over to the webshell in an HTTP request. The webshell will extract the data and put write them its local socket (remote socket for the client). Now the problem with HTTP is that you cannot really have asynchronous responses. The easiest way to tackle this issue was to keep querying the webshell for data. This creates a lag but it is nothing a pentester cannot live with – at this point it must be noted once more that this is a tool “to get a remote meterpreter shell if the firewall is blocking external connections” and not for critical/real-time applications.

After that, we went back to the original idea and created the metasploit module. It is still under development and should be used with extreme caution. It is still recommended to upload a meterpreter shell and use Tunna main module to connect to it. The metasploit module can be summarised as a “half rewrite of the existing code to work with or around metasploit API” (mostly around). This means that “code hacks” were created as needed to make it work. To be architecturally correct with metasploit, the original idea was to create a new metasploit “handler” … however, this proved to be harder than expected and what you get is a bastardisation of handler-exploit … but it works.

Lastly, any comments, bugs or improvement ideas are welcome.

For more information, visit our Tunna Framework page.

Download: Tunna v0.1

Scanning SNMPv3 with nmap vs unicornscan

Wednesday, June 19th, 2013

Many penetration testers rely on unicornscan’s speed to perform UDP portscans. Sometimes, a first pass is made with unicornscan to detect open UDP ports and then a second pass is made with nmap on those ports to find additional information about the service.

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.

Wireshark - portscans with unicornscan and nmap

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! :)

VMInjector – DLL Injection tool to unlock guest VMs

Wednesday, November 14th, 2012

Overview:

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

CVE-2011-3368 PoC – Apache Proxy Scanner

Monday, October 10th, 2011

A recent Apache vulnerability has been made public whereby an attacker could gain unauthorised access to content in the DMZ network:

The mod_proxy module in the Apache HTTP Server 1.3.x through 1.3.42, 2.0.x through 2.0.64, and 2.2.x through 2.2.21 does not properly interact with use of (1) RewriteRule and (2) ProxyPassMatch pattern matches for configuration of a reverse proxy, which allows remote attackers to send requests to intranet servers via a malformed URI containing an initial @ (at sign) character.

SECFORCE has developed a proof of concept for this vulnerability, available for download from our security tools section on our website. The script exploits the vulnerability and allows the user to retrieve arbitrary known files from the DMZ. The tool can also be used to perform a port scan of the web server using the Apache proxy functionality, and therefore bypassing any firewall.

The following output shows the usage of the tool:

python apache_proxy_scanner.py
CVE-2011-3368 proof of concept by Rodrigo Marcos

http://www.secforce.co.uk

usage():
python apache_scan.py [options]
 [options]
    -r: Remote Apache host
    -p: Remote Apache port (default is 80)
    -u: URL on the remote web server (default is /)
    -d: Host in the DMZ (default is 127.0.0.1)
    -e: Port in the DMZ (enables 'single port scan')
    -g: GET request to the host in the DMZ (default is /)
    -h: Help page
examples:
 - Port scan of the remote host
    python apache_scan.py -r www.example.com -u /img/test.gif
 - Port scan of a host in the DMZ
    python apache_scan.py -r www.example.com -u /img/test.gif
	-d internalhost.local
- Retrieve a resource from a host in the DMZ
    python apache_scan.py -r www.example.com -u /img/test.gif
	-d internalhost.local -e 80 -g /accounts/index.html

The tool can be used to perform a portscan of the target host in the following way:

python apache_proxy_scanner.py -r <target> -u <uri>

The following screenshot shows the result of the command above:

Apache proxy port scan results

Apache proxy port scan results

The script can be used to perform a bounce scan of a host in the DMZ or in the Internet:

python apache_proxy_scanner.py -r 192.168.85.161
	-u /rewrite/test -d internalhost
python apache_proxy_scanner.py -r 192.168.85.161
	-u /rewrite/test -d www.example.com

Apache_proxy_scanner will report open/filtered/closed ports in internal and external hosts.

GUI manipulation and penetration testing

Friday, July 15th, 2011

Whilst in the web application development world it is becoming very well understood that “you should never trust the data from the client side”, this is not always the case in local applications.

In web environments any restriction enforced at the client side can be easily bypassed with the use of a web proxy. However, security mechanisms enforced in desktop applications sometimes can be manipulated to perform unauthorised actions.

During a recent penetration test we found a desktop application which needed to be assessed in regard to security. GUI manipulation was used to conduct a number of attacks.

The tool of choice for this particular attack was “DARKER’s Enabler“:

Denabler used for GUI manipulation

Denabler used for GUI manipulation

DARKER’s enabler is a tool which allows showing and enabling objects in Windows applications.

The application to be tested had a number of disabled fields that required to be modified for the purpose of the penetration test. Specifically the “Encrypt” checkbox needed to be unchecked, however the application showed the field disabled:

Original application window

Original application window

With Denabler we dragged-and-dropped the red square to the target application in order to identify de Windows handler of the field and then enabled it:

Denabler in action

Denabler in action

The action enabled the field and allowed the penetration testers to disable the encryption in the application, which resulted vital in the outcome of the penetration test:

Window after enabling the fields

Window after enabling the fields

As shown above, GUI manipulation can lead to unwanted consequences. Extra caution needs to be exercised during the planning and development process to minimize the risk of GUI manipulation.

SECFORCE invited to present at Athcon

Saturday, June 18th, 2011

SECFORCE was invited to present at Athcon conference, held in Athens during 2nd and 3rd June 2011.

AthCon is an annual IT security conference that takes place in Athens Greece designed to give a technical insight to the world of IT security. A realistic, practical view of current and evolving threats and security trends presented by top international security experts.

Athcon

SECFORCE presented a talk called “What you didn’t know about Metasploit”, covering the history of the Metasploit Framework, architecture, exploitation and post-exploitation features.

The Metasploit Framework is mainly used for exploitation purposes during penetration testing engagements.

You can download the slides from the talk from our security research area.

 
   
 
BLOG

Archives

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

Categories

Aircraft security (1)
Business Continuity (2)
CREST (1)
cyber security (2)
Embedded devices security (2)
exploit (9)
Fuzzing (1)
Penetration Testing (42)
Phishing (3)
Risk Management (5)
SECFORCE (18)
Security architecture (2)
Security Books (1)
Security Compliance (1)
Security research (10)
social engineering (1)
social media (1)
sql injection (3)
SQL Server (3)
Tools (14)
Uncategorized (3)
Vulnerabilities (10)
 
SECFORCE - penetration testing
  SECFORCE - penetration testing Aegon House, 13 Lanark Square
Canary Wharf - E14 9QD, 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) 2014 SECFORCE Ltd · All Rights Reserved