Some security researchers have found a vulnerability in the BGP ( Border Gateway Protocol ) routing protocol that could allow one to intercept internet traffic on a scale not possible before, except by a group such as the NSA with their Echelon project. The attack exploits a man-in-the-middle type vulnerability in BGP to monitor and possibly even modify traffic. The exploit works by using the BGP issue to redirect traffic to the eavesdropper’s network where sniffing and other tools can be used to look at the traffic. The attack can only intercept data going to a target ( not from a target ).
The BGP issue has long been known as a theoretical one, however no one has publicly done this until recently at the Defcon Conference where Anton Kapela and Alex Pilosov successfully intercepted traffic bound for the conference and redirected it to New York.
The issue is a result of the BGP notion of trust – BGP routers talk to each to indicate paths ( quickest an efficient ) for the transport of traffic. However, the information passed between BGP routers is not checked and is taken as the truth. An eavesdropper simply advertises a route for a particular target and this is propagated immediately around the world. Traffic bound for the correct target could now be rerouted if that fake path is chosen.
Unlike your average IP hijack, the traffic is silently redirected and no one is the wiser. Normally this is not possible but the attack here uses and BGP feature called AS path prepending that can cause a number of BGP routers to reject the deceptive advertisement. Those ASs can then be used to forward data.
One of the solutions that have been put forward is to create a certificate registry where ISPs would register their ASs and right to do BGP updates. Another option is Secure BGP, which requires BGP routers to digitally sign their prefix advertisements with a private key. Peer routers would then be given certificates authorising them to route its traffic.
All in all, a difficult position for all operating in the Internet space. Costs are high and margins thin so security is not always first on the list. Let’s hope some of the possible solutions are brought to the fire before serious damage is done to the Internet.
Besides SPR ( source port randomisation ), Nominum have a number of other security options built into their Vantio DNS product:
defense: strange queries result in a direct connection to the server
resistance: tries not to give out ip’s for name servers ( glue records )
warns ISP of attack
So, interesting options from Nominum but as I understand it, you can’t actually buy the product – it’s more of a lease type thing. And not cheap, cheap …
Eeek, but let’s look closer. Nominum only fixes the cache poisoning problem for their own users. Defense: shouldn’t they always have a direct secure connection to the server? Resistance: isn’t this what hiding a dns server is all about? Blowing smoke is what this is all about. Perhaps they should give their ‘we fix the DNS for everyone’ solutions to everyone so that we can get rid of the issue once and for all.
VMWare developers recently left beta debug code in an update provided for ESX 3.5, with an expiry date built in. The result would be that users would lose access to their VM’s after applying the update and a ‘general system error’ would be indicated. While the updated update is now working and available, those who need a quick fix can disable the NTP daemon and set the clock back a few days. Interestingly, ITweb had the headline today: SA unaffected by web glitch. Lucky us …
You may have noticed a lot of email purporting to come from MSNBC.com in the last few weeks and this is a result of a new spam campaign doing the rounds. Problem is that some of these headlines could actually be valid; even if people are intelligently looking at their email for spam, they might miss one or two of these. Have a look here to see how many you think could be valid.
So the trick is to look at the email as whole, including headers and attachments, if there is any doubt at all. For example, why would MSNBC.com be sending you email in the first place?
Ben Laurie of Google’s Applied Security team, while working with an external researcher, Dr. Richard Clayton of the Computer Laboratory, Cambridge University, found that various OpenID Providers (OPs) had TLS Server Certificates that used weak keys, as a result of the Debian Predictable Random Number Generator (CVE-2008-0166).
In combination with the DNS Cache Poisoning issue (CVE-2008-1447) and the fact that almost all SSL/TLS implementations do not consult CRLs (currently an untracked issue), this means that it is impossible to rely on these OPs.
In order to mount an attack against a vulnerable OP, the attacker first finds the private key corresponding to the weak TLS certificate. He then sets up a website masquerading as the original OP, both for the OpenID protocol and also for HTTP/HTTPS.
Then he poisons the DNS cache of the victim to make it appear that his server is the true OpenID Provider.
There are two cases, one is where the victim is a user trying to identify themselves, in which case, even if they use HTTPS to “ensure” that the site they are visiting is indeed their provider, they will be unable to detect the substitution and will give their login credentials to the attacker.
The second case is where the victim is the Relying Party (RP). In this case, even if the RP uses TLS to connect to the OP, as is recommended for higher assurance, he will not be defended, as the vast majority of OpenID implementations do not check CRLs, and will, therefore, accept the malicious site as the true OP.
Dan Kaminsky gave a very interesting talk on the recent DNS issues as part of the Black Hat USA 2008 conference currently on the go in Las Vegas. Originally DJ Bernstein had advocated ( and put into DJBDNS ) source port randomisation as part of the DNS request but no one else had as they thought transaction id randomisation was good enough. Well it wasn’t, so the current ‘fix’ is to do just that. Unfortunately, the attempts at protection of internal networks ( Firewall NAT’ing ) ends up removing this protection due to it removing the random source port!!!
Dan also has a very cool video of the spread of DNS updates ( or the lack thereof ):
Red — Unpatched
Yellow — Patched, but the NAT is screwing things up
Green — OK
The following article comes courtesy of SDV: Some researchers at the recent BlackHat conference have been doing work in the area of Window Vista security and have ( apparently ) found a major hole whereby they can use .Net or similar scripting languages to effectively bypass the memory security functions built into Vista ( DEP – Data Execution Prevention and ASLR – Address Space Layout Randomization ). Once that is done, you have open access to Vista and its internals. The following link from Neowin provides some more information about this potentially devastating ( for Microsoft and those using Vista ) issue.
Dan Kaminsky previewed information relating to possibly the worst DNS-related exploit ever, earlier this month. The issue is a cache poisoning vulnerability and can result in DNS answers containing fiddled information. This is actually a general design issue more than any vendor-specific issue. Imagine entering a url in your browser and been taken to another site instead, one that was not expected, where malicious code is auto executed or worse, a fake copy of the target site has been developed where you unintentionally enter personal defining information such as user names and passwords.
All vendors’ DNS implementations were affected and most have updated their respective versions by now – a notable exception is Apple’s MacOS X Server … Apparently Apple are to busy with more important things like MobileMe issues. Considering that there is active exploit code circulating, it’s vitally important that if you run an authoritative name server, that you update your DNS applications soonest. A test is available on Dan’s site if need more info or to check your system.
A little birdie has also whispered in my ear that BIND 9.5.x-p has been particularly unstable; just a note for those using the latest version of the most popular DNS server on the market.
It’s quite interesting that out of the 30 or so contacts I sent information to about the vmsplice issue, only one person came back to me requesting their kernel be updated. This is unfortunately the reality of security these daysÂ – with more to lose, people have less concern about security.
The recent vulnerability in the linux kernel pertaining to the vmsplice function has resulted in quite a hole in many Linux PCs all over the world. It is recommended to updated to 184.108.40.206 immediately to close this loop hole. Please note that to successfully exploit this bug, you need to have at minimum unprivileged local access. More info available here: