Saturday, 6 August 2011

DNSWall, Rebinding and client attacks (Part 3).

Continuing from last nights post on DNS Rebinding as well as part 2 today, I will detail and endeavour to show a few defences.

A DNS WALL is a program, service or daemon that runs on or between the network DNS server.

Google has DNSWall, an open-source application with the stated purpose of preventing DNS servers inside your organisation from resolving public names to internal RFC1918 IP addresses. They state that:
By blocking outbound traffic on port 53, a firewall administrator for an organization can force all internal machines, including HTTP proxies and VPN clients, to use a DNS server that is configured not to resolve external names to internal IP addresses. To implement this approach, we developed a 300 line C program, dnswall, that runs alongside BIND and enforces this policy.

[…] Many consumer firewalls, such as those produced by Linksys, already expose a caching DNS resolver and can be augmented with dnswall to block DNS responses that contain private IP addresses. The vendors of these devices have an incentive to patch their firewalls because these rebinding attacks can be used to reconfigure these routers to mount further attacks on their owners


The DNSWall program from Google sits between the internal client host and their organisational DNS forwarder. It is in effect an intermediary proxy server for DNS traffic. By intercepting the DNS queries sent by clients, it can then forward the client’s query, modifying the information receives from the authoritative DNS server when an RFC 1918 request has been received. This means that it will only forward the reply (the destination server IP address) to the client when the IP address being returned is not an RFC1918 address. That is, it will filter private addresses and stop attackers being able to rebind your system to 192.168.x.y, 10.0.0.0/8 or 172.16.a.b addresses.

It is actually a little more complex than that, but any of the following

  •  Invalid IP address: an IP address in the 0.x.x.x range
  •  Node-Local IP address: 127.x.x.x
  •  Link-Local IP address: 169.254.x.x
  •  Site-Local IP address: 10.x.x.x, 172.x.x.x, 192.168.x.x
  •  Multicast IP address: 224.x.x.x 
Troubles with Google’s DNSWall
Google’s DNSWall application modifies the TXID of the original DNS query.

This is the means that they have used to map replies to the original query.

In DNSWall new TXID used is sequentially incremented leaving this open to poisoning attacks if an attacker can insert themselves or in selected other instances. As the TXID is issued starting from 0 and increases sequentially to 65536 before starting again, the poisoning attack is far simpler than it should be. The attacker can guess the TXID and inject a false response such that they could poison the DNS cache of the client’s host.

Not too difficult to fix with a little effort.

Where you can take this…
In coming weeks I will start to document a process to create more than a simple RFC1918 blocker, but to also allow this to be used to filter known block-lists, SPAM relays and also alter administrators when their users are being sent to malicious websites.

Nothing too hard and with minimal cost (other than some time).

DNSWall, Rebinding and client attacks (Part 2).

Continuing from last nights post on DNS Rebinding, I will detail this attack more and then start to show a few defences.

The attacker will start by either creating their own website or attacking and subverting another. The latter is more effective with many large and high profile sites having been compromised in the last 12 months and used for these types of attacks. Further, these sites are more trusted (ones such as News Ltd’s) being read by many existing subscribers and commonly whitelisted in companies.

In the incidence, the DNS server will be under the control of the attacker as well. This can be through attacking the organisations DNS, the end user’s DNS (and home routers can be very susceptible to this) or by injecting packets. The attacker who sets up their own site for this attack has an easier time as they will generally be in charge of their own DNS already. Hence, they can easily set the responses that the DNS resolves queries to for a site.

In stage 1, the victim goes to the attacker’s site. The DNS will initially return the correct IP Address for the webserver that the attacker has control of on the internet.

The TTL is set (this is the time to live) for the query at a value that suits the attacker’s purpose. Following the initial call to the website, the next response will be an IP address that the attacker wants to extend their access to. That is, they rebind the hostname of the webserver to another address.

For instance, if you have a system on IP address 10.1.1.2 and the attacker wants to gain access and information from an internal intranet system that is authenticated though IP address authentication (or using CSRF – more on this later) internet to your network and firewall on IP 10.1.1.100, the attacker will rebind their hostname that the DNS returns to 10.1.1.100.

Next time the victim’s browser makes a call to the hostname, it will be pointed not to the attacker’s website, but to the victim’s internal server at 10.1.1.100 bypassing the firewall and other controls.
You may ask how does this help the attacker?

This is one of many types of rebinding attack and is known as a “Firewall Circumvention” rebind attack.
The attacker would have already loaded script into their initial webpage. This can be JavaScript, Flash or a combination of both (and even other types of active code). The hostname call from JavaScript or Flash will be delayed so that a different name is obtained from the DNS server than the browser itself obtained. Using JavaScript and Flash together, an attacker can pull information from an internal site and feed it back to the attacker over standard HTTP queries bypassing the firerwall.

One of the biggest issues here is that Java, JavaScript, Flash and the browser itself all “pin” DNS queries differently and for different amounts of time. So the browser will remember an IP address (pin it) for a different amount of time than that of the script.

Java has a control that was designed to stop (or at least make this more difficult) here in the documentation they state “The positive caching is there to guard against DNS spoofing attacks

networkaddress.cache.ttl (default: -1)
 
The value of -1 designates "cache forever" where Java will remember the IP address it was first given for the life of the session (this is right to a reboot sometimes).

FLASH has the Socket class in the newer versions of FLASH Player (Version 9.0 and greater, ActionScript 3.0). That also make this attack more dangerous as the sockets that flash can bind can be anything within the organisation. That is, any port and any protocol, not just web.

The call to Java in the applet and that in Flash can be subverted by delaying the response from the DNS server that these applets make to after the initial page has loaded.

This way, the attacker can go from a webpage with an IP on the external Internet, a delay and then a response to the script on an internal RFC 1918 address (in our example 10.1.1.100) that will be cached forever. Once the script is cached, the attacker can return the IP address to the external IP of the Internet again to ensure that page reloads are maintained as well.

The script (such as the Java applet) will point at the internal Server (10.1.1.100) but the user and browser will again see the attacker as an external IP address and the attacker can use this to send information to or from the system they wish to attack that lies behind the firewall.

Craig Heffner used such a scenario in his BlackHat presentation “How to Hack Millions of Routers”.
This attack can be easily deployed to attack routers, printers, switches, internal servers and more. With flash sockets, this can be used to scan internal ports on protocols other than HTTP/HTTPS. One common technique is for SSH username and password guessing behind a firewall.

So, are you looking at the authentication logs for internal systems as well? 

In the third and final part of this post, I will cover one solution, DNS Wall. There are other solutions ranging from not running script (though in the Web 2.0 world this is no longer much of an option), to using NoScript (as long as you support and use Firefox as your browser) to other DNS options and even creating tailored IPS block lists and filters.

NoScript is a definite option where you can use it. Even with ALL SCRIPTS ALLOWED, NoScript provides protection against many rebinding attacks. But the issue is when there are many users and in organisations where a standardised browser deployment does not include Firefox, this is not an option.
So, next, a solution to the problem I have just raised…

Infomation

As a side note I will get around to updating the information on the side of this Blog, but I will make that a secondary effort following the topics and posts on security.

Some recent articles I have published follow:

In the coming days I will have two more articles published:
  • The nature of business and hacktivism
  • Cyber terrorism 
Stay tunes and I will link these as they are released.

SIP Enumeration

More VoIP security again this morning.

Most VoIP attacks require the attacker to know the VoIP username or phone extension. They use these to confirm the existence of the register, location, proxy Private Branch eXchange (PBX) and more and to craft their attacks.

It is of course possible to brute force a VoIP system running through all extensions possible in the system. This is time consuming and noisy leading to discovery and a skilled attacker will not do this.
Hence Enumeration.

Rather than making the noise of a brute force attack, the attacker can use the Session Identification Protocol (SIP) itself to obtain this information.

The REGISTER, OPTIONS and INVITE SIP methods are the ones most commonly used by an attacker in enumerating users.

Attackers will query these options and use them to speculate on and then validate user accounts. In this way they can both find if an extension is valid as well as mapping it to a particular user.

Monitoring failed traffic is a sign of an attack. Looking at and know what type of traffic is usual on your system and investigating the anomalous information helps you to take your valuable time and use it effectively.
In the coming days, I will describe the SIP enumerating process and how you can understand this and use this understanding to detect (and hence stop) attacks on your VoIP system.

Friday, 5 August 2011

SiVuS–A SIP vulnerability scanner

SiVuS (a tool which is difficult to find now) has the following capabilities:

  • SIP Device Discovery
  • Sip Vulnerability Scanning
  • SIP Message Generation
The tool is Java based (hence requiring the JRE to be installed) and has a good well features GUI.

The purpose of the tool is to enable auditing (and therefor to allow for the securing) of VoIP networks. It supports Real-Time Transport Protocol (RTP) but though the tool has tabs for H.323, it does not yet support this.

The main use of the tool is in scanning and enumerating VoIP systems and looking for vulnerabilities in the implementation (that then can we hope be corrected).

The VoIP packet generator can be used for flood testing and stress tests and with some effort can also be used as a decent Fuzzing tool for VoIP.

Finally, SiVuS can be used (Cain and Able is much better at this and is still supported) to manipulate the VoIP registration and signalling.

For more details, there is a good PDF covering many aspects of SiVuS at the following site.

I will not do a complete run-through and technical write-up as there is a very good step by step process here.

Sivus does not support MGCP and H.323 scanning. We will cover tools that can do this another time.

SIP Registration Hijacking...

The reason we want to scan VoIP systems is the same as any other. I will also be posting on a number of free VoIP vulnerability scanning tools this weekend. The things an attacker can do using SIP Registration Hijacking include:

  • Call redirection (to a phone they want to monitor, to another person’s phone as a prank or just to a black hole, a fax or something else that causes problems)
  • Call swapping (having different people get different calls that should have been destined for the other)
  • Sending messages to a voicemail store or a recorder controlled by the attacker
  • MITM attacks.
MITM attacks on VoIP can lead to call interception, call recording and event injection and modification.

Defences…
I will detail more on the blog, but using TCP instead of UDP for SIP registrations is more secure. It makes life harder for the attacker and hence our lives as security professionals easier.

Better, use signalling encryption. Secure SIP (SIP-TLS and SIPS) may be an existing option with your current VoIP system. If it is, enable it. If not, you can use IPSec and other VPN tunnel technologies to encapsulate the SIP traffic and hence make it more difficult for an attacker to intercept and modify.

Always use strong SIP authentication policies with difficult to crack passwords (with SIP and all other passwords for this matter).

Finally, by reducing SIP registration intervals, the length of time an attacker has control is minimised and the attack becomes more difficult.

I will write on VoIP vulnerability scans this weekend.

DNSWall, Rebinding and client attacks (Part 1).

A few technologies have done wonders in helping protect us from rebinding attacks. OpenDNS / NoScript / DNSWall are key in this effort, but it seems that not many people know what they do.

I will note how OpenDNS and NoScript help defend our networks rebinding another post, but for now I will talk of DNSWalls and why they are necessary.

A DNSWALL is an application, service, daemon etc. that filters the RFC 1918 private addresses out of DNS responses. A reverse DNS wall stops your RFC 1918 addresses from being returned.

For this post, I am focusing on the DNSWALL as a fix for certain types of rebinding attacks. I cover DNS and many of the issues it still faces in more depth in my SANS paper from 2008.

Other attacks against browsers and clients that will be written about in the coming weeks include Cross Site Request Forgery (CSRF) and iFrame attacks.

Rebinding to attack RFC 1918 addresses
In attacking an RFC1918 host, in this example a user’s browser on the internal address of 10.1.1.1 (we have not listed the external address, but there will be a firewall or other NAT device used so that the user may connect to the Internet), the attacker cannot directly send packets to the user.


Here, the user has called a webserver controlled by the attacker at www.badguy.com and it has been initially resolved to an external IP address that the user can connect to across the Internet.

The user starts by making a query to DNS and the initial reply is a valid internet address. For this example I will use 203.34.22.10.

Next, the user’s browser (with Flash and the trimmings) makes a call to the attackers web server:
GET / HTTP/1.1
Host: www.badguy.com
Initially, the attacker’s external web server will respond with HTML code such that the web page is sent to the user and can be displayed in their browser.

A DNS rebinding attack is used by an attacker to exploit the web browser’s same-origin policy. The same-origin policy is used by the web browser when it runs script code ( such as JavaScript, Flash, and other active code) that connects to different web sites when and if the original website and the one that the original one is connecting to share the same origin.

The same-origin policy defines three conditions:
  1. (1) the same protocol (e.g.. TCP) has to be used,
  2. (2) the same port (e.g. 80, 81, 8080 etc.) has to be connected to, and
  3. (3) the same system has the same hostname.
Consequently, http://www.badguy.com and https://www.badguy.com are not both in the same origin as far as a web browser is concerned. The web browser will not allow these two sites to run scripts against each other as these sites have different port numbers (a violation of point 2 above as well as point 1 – protocol http vs. https).
This means that your web browser will (should) not allow scripts from http://www.badguy.com to interact and share data with https://www.badguy.com.
However, the addresses below are all of the same origin:
  1. http://www.badguy.com/attack_scripts
  2. http://www.badguy.com/user_data
  3. http://www.badguy.com
This is as these share the same:
  1. protocol (http over port 80),
  2. port (TCP port 80) and,
  3. hostname (www.badguy.com).
Attackers use the ability to rebind the hostname of a website to an IP address that is different than the original one for the attacks I am documenting here. In particular, by using TTL (time to live) and IP address caching times that differ from the browser to flash and other sources, the attacker can have the user’s host, the user’s browser and the flash application all see different IP addresses.

This starts when the attacker sets a small TTL making the user’s system ask the DNS server for the attackers IP address again. The first call to the DNS server of course will have returned a valid publically routable IP address so the user can get to the attacker’s web server, but a subsequent call to the DNS server could return an internal RFC1918 address.

Exploiting timing differences, the attacker can use the differences in the pinning (I will explain this in the next post and then link it) times of the browser and the script applications (such as Flash) to their advantage.
The browser may remember the IP of the external system, but flash may cache a new IP address obtaining an internal 10.1.1.0/24 address. In this way, the attacker can point your browser and flash application towards an internal system.

This can be used for something as simple as scanning an internal server or event the range of addresses inside the network or for connecting to trusted systems.

As many internal Intranet sites are trust-based (either caching credentials or even using the account of the logged on user or worse, just their IP address), an attacker could attempt to user this trust as a means to log into the internal system and extract data.

More to come…
In the next couple days, I will continue on this post as well as explaining how a DNS Wall can help stop an attacker from mapping your internal network.

At the end of the day, it is never a good idea to allow external Internet hosted DNS servers to return un-routable RFC1918 addresses to your server.

There are a number of things that you need to do to stop this, first, stop your users from connecting to external DNS servers (and it is amazing how many organisations do not filter outgoing UDP and TCP 53 at their firewalls). Next, and I will detail this in more depth in the coming post, install a DNS wall using an application such as Google’s DNS WALL or OPENDNS.

As your systems cannot connect to RFC 1918 addresses on the internet (they cannot be publically routed) you lose nothing by blocking these and gain much.

Thursday, 4 August 2011

We are coming into a new era and we are just not ready for it.

I predict botnets of 100 million plus compromised hosts this decade. When this starts to be the norm, there will not be much more for crime, terror and espionage groups to get. They will have to lock each other out of the hosts they have compromised and they will start to find that systems are either secured with extrusion controls and more or that these hosts have already been compromised.

As there will be a point where they cannot get to compromise more hosts, crime groups and espionage (state based groups) are going to start competing and attacking one another.

When the available systems that can be compromised start to run low, that is, the groups control and maintain their botnets to the exclusion of other botnets, this is when things are going to start to become interesting.

We are looking at botnets of state and criminal groups competing. When this happens, it will be the average person and company who is caught in the middle.

It is not great new toys that will save us, but as always, the basics, the fundimentals, the things we are teaching less and less.

Wednesday, 3 August 2011

Low drama security

I have setup a Facebook group and Google+, "Low Drama Security".

As with many others who have been in security for a long time, I have time and again seen good practice placed on the back-burner for theatre.

A few years back, SANS had a secure coding competition where text books with flaws were noted and the errors that are being taught were brought to light. All of these text books are still being used to train future developers.

One aspect of my ongoing research has been in looking at risk. In this I have been measuring patching stats and more in real organisation for the last few years. Some of the publications are starting to come out and the results are being made public. In this, compliance has been a bugbear. People are adding the appearance of security and missing key aspects of systems that actually come under constant attack. Routers and switches were found to hardly ever be patched and many did not even come under rudimentary controls.

I want to start a movement that will promote the fundamentals.

We need to start including good coding practice in courses (there are very few that do).

We need to start promoting solutions that make a real and measurable impact.

We need to start holding firms accountable for simple errors that should not have occurred.

We need to start making auditors accountable for actually validating security and not just following a checklist.

We need to promote real solutions.

I welcome all to join and start promoting real solutions and not simply theatre.

Sunday, 31 July 2011

Why the Gini is NOT a measaure of inequality as it is touted

I have have the Gini index touted as a constant error in the statements that I make that the US is not an unfair society and it is better to aim for a society where people eat than one where all individuals are equally poor and destitute.

Basically, the Gini index is one of the most flawed statistical lies used in the pursuit of socialism as a goal. It makes so many false assumptions it is not funny. It does not class people by age and gender and does not account for differences in the distributions of age over time.

It does not measure actual wealth and confuses income and wealth.

It compares what it calls a measure of wealth (falsely) in different classes of populations.

To expound further, the Gini index is not as you tout a measure of inequality, but one of income distribution without regard to age and other factors. It fails as a measure of inequality for many reasons, mainly as it does not measure wealth. Inequality is a measure more of wealth at a point in one’s life than over a generalized population.

A person at 20 cannot be compared directly with one at 50. The same person at 20 does not have the wealth and resources of one at the age of 50 as one tends to accumulate wealth as one ages (being that one starts with little and it accumulates over time).

The wealth distributions of males (being that the decision to exit the workforce or not is in itself a determining factor for wealth and also many third world countries do not have large working populations of females with independent incomes) at the age of 45 would be a far superior measure of inequality than the Gini as it is used, but this or course also has its problems (though there are far fewer issues here than in the Gini).

The age distributions in third world and socialist countries (commonly the same though not always) are far flatter than in the western “capitalist” (nominally) countries. That is, a worker in say Kenya will see little increment in their earned income from the age of 20 to that of 50. The distribution of their income over their lifetime remains relatively static.

In contrast, the income and earning capacity of a worker in the US, even an unskilled one, will change significantly during their career.

A worker in the US earns little when they are a student. This rate increases as they gain in experience and increase in productivity. This earning capacity generally peaks around the age of 45-55 and then starts to decline until it finally returns to a low amount for most people in retirement when savings are used to supplement ones income. A worker in the US commonly earns 4-5 times their starting wages at some point in their career.

Many socialist societies have no age based income differentials and the earning capacity is based more on class, rank and party affiliations/position, a truly unequal system.

As the Gini does not account for age and sex based differences in its calculation, it fails even as a true measure of income variance. That is, it fails without even looking at the fact that income equality is not a measure of inequality in itself in any event.

We start in western countries earning less, movie into higher wage brackets before falling to near nothing again. If you take a measure of the "inequality" rank to age and sex classifications, you find an R^2 of over 0.90 or a correlation to age and NOT inequality using the Gini.

Now, taking into account that “first world” countries generally have people living longer than “third world” countries, we start to see that there is an inherent bias in the Gini index as well as the afore noted errors. In countries where people have a longer retirement, the Gini creates a situation where a country is classed as “unequal” for simply having people who live on their accumulated wealth.

Then, the socialist ideal here in not to actually analyze data, but to blindly accept the dogma as blinded sheep.