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/her 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.
SPARTA tries to simplify the way you run tools and centralises their outputs, displaying them in a meaningful way:
Apart from running tools across several hosts with a single click, you can also define automated tasks for services (ie: run Nikto on every HTTP service as soon as it is found) and have SPARTA do all the work for you:
– Run nmap from SPARTA or import nmap XML output.
– Transparent staged nmap: get results quickly and achieve thorough coverage.
– Configurable context menu for each service. You can configure what to run on discovered services. Any tool that can be run from a terminal, can be run from SPARTA.
– You can run any script or tool on a service across all the hosts in scope, just with a click of the mouse.
– Define automated tasks for services (ie. Run nikto on every HTTP service, or sslscan on every ssl service).
– Default credentials check for most common services. Of course, this can also be configured to run automatically.
– Identify password reuse on the tested infrastructure. 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: sysadmins reuse passwords).
– Ability to mark hosts that you have already worked on so that you don’t waste time looking at them again.
– Website screenshot taker so that you don’t waste time on less interesting web servers.
For more information and to download SPARTA, go to:
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
Support for UpStream Proxy
Removed Ruby version of Client
python proxy.py -u <remoteurl> -l 8000
This will set up Tunna and start a SOCKS4a proxy server on port 8000
SOCKS Operation Details:
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.
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:
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.
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.
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)
This is a python standalone webserver for Tunna. The functionality is the same as a webserver that has a Tunna webshell.
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.
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.
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.
squashfs-tools – Can apt-get squashfs-tools for this. Bundle of tools to enable you to play with the squashfs in this tutorial
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.
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:
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.
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:
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 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:
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 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:
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.
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!
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! 🙂
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
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.
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.
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:
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.
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 (https://github.com/batistam/VMInjector)
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.
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:
CVE-2011-3368 proof of concept by Rodrigo Marcos
python apache_scan.py [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
Â - 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
- 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:
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.
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
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
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
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.