TROOPERS12 Conference
Thank you for attending another edition of your premium ITSec event!
Slides to be found in the archive.
Twitter
PostsArchive for March 2011
Some of you may have heard of the break-in at RSA and may now be wondering “what does this mean to us?” and “what can be done?”. Not being an expert on RSA SecurID at all – I’ve been involved in some projects, however not on the technical implementation side but on the architecture or overall [risk] management side – I’ll still try to contribute to the debate 
Fundamentals
My understanding of the way RSA SecurID tokens work is roughly this:
a) The authentication capabilities provided by the system (as part of an overall infrastructure where authentication plays a role) are based on two factors: a one-time-password (OTP) generated in regular intervals by both a token and some (backend) authentication server and a PIN known by a user.
c) the OTP generation process takes some initialization value called the “seed” and the current time as input and calculates – by means of some algorithm at whose core probably sits a hash function – the OTP itself.
d) the algorithm seems publicly known (there are some cryptanalytic papers listed in the Wikipedia article on RSA SecurID and a generator – needing the seed as input – has been available for some time now). Even if it wasn’t public we should assume that Kerckhoff’s principle exists for some reason
e) So, in the end of the day, an OTP of a given token at a given point of time can be calculated once the seed of this specific token is known.
This means: to some (large) degree, the whole security of the OTP relies on the secrecy of the seed which, obviously, must be kept. [For the overall authentication process there's still the PIN, but this one can be assumed to be the "weaker part" of the whole thing.]
Flavors
RSA SecurID tokens, and those of other vendors as well, are sold in two main variants:
- as hardware devices (in different sizes, colors etc.) Here the seed is encoded as part of the manufacturing process and there must be some import process of token serial numbers and their associated seeds into the authentication server (located at the organization using the product for authentication), and some subsequent mapping of a user + PIN to a certain token (identified by serial number, I assume). The seeds are then generated on the product vendor’s (e.g. RSA’s) side in an early stage of the manufacturing process and distributed as part of the product delivery process. Not sure why a vendor (like RSA) should keep those associations of (token) serial numbers and their seeds (as I said, I’m not an expert in this area so I might overlook sth here, even sth fairly obvious ) once the product delivery process is completed, but I assume this nevertheless happens to some extent. And I assume this is part of the potential impact of the current incident, see below.
- as so-called “soft tokens”, that are software instances running on a PC or mobile device and generating the OTP. For this purpose, again the seed is needed and to the best of my knowledge there’s, in the RSA space at least, two ways how the seed gets onto the device:
- generate it as part of “user creation” process on the authentication server and subsequent distribution to users (by email or download link), for import. For obvious reasons not all people like this, security-wise.
- generate it, by means of an RSA proprietary scheme called Cryptographic Token Key Initialization Protocol (CT-KIP) in parallel on the token and the server and thereby avoid the (seed’s) transmission over the network.
Btw: In both cases importing the seed into a TPM would be nice, but – as of mid 2010 when I did some research – this was still in a quite immature state. So not sure if this currently is a viable option.
Attacks
- compromise of an organization’s authentication server. From audits in the past I know these systems often reside in network segments not-too-easily accessible and they are – sometimes – reasonably well protected (hardening etc.). Furthermore I have no idea how easy it would be to extract the seeds from such a system once compromised. Getting them might allow for subsequent attacks on remote users (logging into VPN gateways, OWA servers etc.), but only against this specific organization. And if the attacker already managed to compromise the organization’s authentication server this effort might not even be necessary anymore.
- compromise of the (mobile) devices of some users of a given organization using soft tokens and copy/steal their seeds. This could potentially be done by a piece of malware (provided it manages to access the seed at all, which might be difficult – protected storage and stuff comes to mind – or not. I just don’t know
This is the one usually infosec people opposing the replacement of hard tokens by soft tokens (e.g. for usability reasons) warn about. There are people who do not regard this as a very relevant risk, as it requires initial compromise of the device in question. Which, of course, can happen. But why “spend energy” on getting the seed then as the box is compromised anyway (and any data processed on it). I’m well aware of the “attacker can use seed for future attacks from other endpoints” argument. One might just wonder about the incentive for an attacker to got after the seeds…
It should be noted that binding the (soft) token to a specific device, identified by serial number, unique device identifier (like in the case of iPhones) or harddisk ID or sth – which can be done in the RSA SecurID space since some time, I believe since Authentication Manager 7.1 – might to some degree serve as a mitigating control against this type of attack. - attack vendor (RSA) and hope to get access to the seeds of many organizations which can then be used in subsequent targeted attacks. I have the vague impression that this is exactly what happened here. Art Coviello writes in his letter:
“[the information gained by the attackers] could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.”
I interpret this as follows: “dear customers, face the fact that some attackers might dispose of your seeds and the OTPs calculated on those so you’re left with the PIN as the last resort for the security of the overall authentication process”.
– and equally conventional wisdom including pieces like “We recommend customers update their security products and the operating systems hosting them with the latest patches”. And, of course, it’s pure coincidence that they mention the use of SIEM systems twice… being a SIEM vendor themselves ) 14
VMSA-2011-0005: VMware vCenter Orchestrator remote code execution vulnerability
0 Comments | Posted by erey
Reading this advisory I’m quite tempted to emit another rant on the relationship of heavy use of 3rd party components, lack of (security) quality assurance and services running at times where they’re not needed (see second workaround here). I’ll refrain from that for today. Just wanted to let you know that the underlying vulnerability in Struts2 was initially discovered by Meder Kydyraliev who gives this talk at Troopers in two weeks. He’ll certainly describe the inner workings of this one, and others…
Have a good one,
Enno
) and networking technologies in general so it was a workshop in the purest sense: lots of practical hands-on, lots of tinkering, lots of enligthening discussions. ) but workshops like this one are sth I particularly enjoy. Huge personal progression and getting paid for it netsh int ipv6 set int [index] routerdiscovery=disabled
, thanksHi everybody,
this post is the sequel of this one on the IPv6 security feature called “RA guard”. As announced in that post I recently got a 4948 on ebay. After installing the appropriate image and noticing that RA guard was still unavailable I found out it should have been a 4948E which is capable of “doing IPv6 in hardware” (as opposed to the “simple 4948″ only supporting IPv6 in a “software switched” way. and pls note there’s also the informal term 4948-E denoting a 4948 running an “enhanced image”).
Well… we’ll certainly find some useful function for that device – and I just initiated the acquisition of a 4948E – but I was just eager to get my hands on the practical use and implications of RA guard. Looking at the Cisco Feature Navigator for “IPv6 Basic RA Guard” it seems that it’s still the same platforms supporting it as eight weeks ago, so there was only one option left: get one of our Cat 65Ks from the basement and perform the testing with it.
Given ERNW’s strong emphasis on sports pretty much immediately some kind-of “strong man contest” evolved going like “who can lift and carry the device without further assistance”
so we had quite some fun just putting the box into operation.
[for those interested we can provide the number and nature of modules installed at the time of that contest ]
Ok, back to the technical side of things. Here’s what we did:
Step 1) Perform RA based attacks with “RA Guard” being absent.
For that purpose we used Van Hauser’s THC-IPV6 attack suite (which can be found here) and performed two specific attacks.
1a) Use
fake_router6 eth0 2001:db8:dead:beef::/64
to send spoofed RAs which resulted in an additional prefix and associated default gateway being learned on the victim system (default install of current MS Windows).
It should be noted that the additional (“spoofed”) default gateway had a better (= lower) metric in the routing table.
1b) Use
flood_router6 eth0
to send arbitrary spoofed router advertisements (with the eventual purpose of a DoS condition). This worked equally well. Right after starting the attack the CPU load of the attacked system ‒ and for that matter, the load of other systems on the local link as well ‒ went to 100% (and stayed there for hours after stopping the emanation of packets on the attacker’s host).
[you might notice that this is not the "oldest and weakest laptop we took from our lab shelf"...]
In short: both RA based attacks we tried worked like a charm.
So this is absolutely something every security responsible of a IPv6 enabled network should be concerned about…
Step2: put lab device into action, enable RA guard and check if it helps.
At the time of our testing the box was running
Cisco IOS Software, s3223_rp Software (s3223_rp-IPBASEK9-M), Version 12.2(33)SXI5, RELEASE SOFTWARE (fc2)
[which, btw, "silently ignores" any WS-X6248-RJ-45 modules present in the box. Of course, I'm aware that all of you valued readers always carefully read the release notes of this (or other) images before deploying them...]
We then enabled RA guard on the access-ports to-be by
Router(config)#int range f1/24 – 36
Router(config-if-range)#switchport
Router(config-if-range)#switchport mode access
Router(config-if-range)#ipv6 nd raguard
and performed the attacks again.
Without success! Seemingly the box efficiently (and silently) discarded all RA packets arriving on those ports.
So we can certainly state that RA guard fully performs as expected. One minor annoyance we noticed: there seems no log message of any kind while the attack is in progress.
However, earlier – when performing step 1a – we had noticed sth like this on the router legitimately serving the local network with RAs:
Thus there might still be a way to detect RA based attacks. It’s just not on the box providing protection from them but on another one.
If you want to see these attacks (and the - quite simple – configuration of RA guard) in practice you can do so either at our workshop on “IPv6 security in LANs” at Troopers or at the Heise IPv6 Kongress in May. At both occasions we’ll demonstrate this stuff.
We think that RA guard is pretty much the only way to protect against RA based attacks in an operationally feasible way (as opposed to, say, filtering ICMP type 134 by means of port based or VLAN ACLs).
To mitigate the risk of “RA interference” caused by potentially misconfigured systems (e.g. Windows systems running 6-to-4 with a public IPv4 address and Internet Connection Sharing enabled; more on this in a future post on IPv6 tunnel technologies) or by systems “accidentally inserted into the local network” (employee connecting SOHO DSL router. which, again, certainly never happens in your network…), there might be another configuration tweak that could help. The standards track RFC 4191 on Default Router Preferences and More-Specific Routes introduced the concept of a preference assigned to router advertisements distributed by routers on the local link.
For that purpose the format of RA messages is extended and two of the previously unused bits within the byte containing the flags are used for a “Prf” (Default Router Preference) value.
The configuration is quite simple (on Cisco routers where the feature was introduced in IOS Version 12.4(2)T) and goes like this:
Router(config)# interface f0/1
Router(config-if)# ipv6 nd router-preference {high | medium | low}
Hosts receiving RAs tagged with a high preference flag will prefer them over RA messages emitted with the default value (“medium”). We’ll play around with this in a more detailed fashion at some occasion and keep you posted. In the interim you might look here to get some background on the way router preference works.
The next post of our series is planned to cover the (in the current Windows world) ever-present tunnel technologies and their security implications.
Have a great weekend everybody,
Enno
gtp_scan is a small python script that scans for GTP (GPRS tunneling protocol) speaking hosts. To discover those hosts it uses the GTP build in PING mechanism, it sends a GTP packet of the type ECHO_REQUEST and listens for an incoming GTP ECHO_REPLY. Its capable of generating ECHO_REQUESTS for GTP version 1 and GTP version 2. Also the script can scan for both, GTP-C and GTP-U (the control channel and the user data channel), only the port differs here.
In the output the received packet is displayed and the basic GTP header is dissected so one can see a GTP version 1 host answering a GTP version 2 ECHO_REQUEST with the ‘version not supported’ message.
Tests have shown that there are some strange services around, which answer to an GTP ECHO_REQUEST with a lot of weird data, which leads to ‘kind of’ false positive results but they can easily be discovered by checking the output data with your brain (eg. there is no GTP version 12)
download it here gtp_scan-0.5.tar.gz
enjoy
/daniel