SoylentNews is people
SoylentNews
From Ars: "Spyware service provider Hacking Team orchestrated the hijacking of IP addresses it didn't own to help Italian police regain control over several computers that were being monitored in an investigation"
Over a six day period in August 2013, Italian Web host Aruba S.p.A. fraudulently announced its ownership of 256 IP addresses into the global routing system known as border gateway protocol, the messages document. Aruba's move came under the direction of Hacking Team and the Special Operations Group of the Italian National Military Police, which was using Hacking Team's Remote Control System malware to monitor the computers of unidentified targets. The hijacking came after the IP addresses became unreachable under its rightful owner Santrex, the "bullet-proof" Web hosting provider that catered to criminals and went out of business in October 2013, according to KrebsOnSecurity.
It's not clear from the e-mails, but they appear to suggest Hacking Team and the Italian police were also relying on Santrex. The emails were included in some 400 gigabytes of proprietary data taken during last weekend's breach of Hacking Team and then made public on the Internet.
With the sudden loss of the block of IP addresses, Italy's Special Operations Group was unable to communicate with several computers that were infected with the Hacking Team malware. The e-mails show Hacking Team support workers discussing how the law enforcement agency could regain control. Eventually, Italian police worked with Aruba to get the block—which was known as 46.166.163.0/24 in Internet routing parlance—announced in the BGP system as belonging to Aruba. It's the first known case of an ISP fraudulently announcing another provider's address space, said Doug Madory, director of Internet analysis at Dyn Research, which performs research on Internet performance.
Also covered by Brian Krebs:
http://krebsonsecurity.com/2015/07/hacking-team-used-spammer-tricks-to-resurrect-spy-network/
Original Submission
(Score: 3, Interesting) by jasassin on Monday July 13 2015, @10:12PM
I don't understand BGP. Could someone explain to me why they needed to own IP addresses to monitor already infected machines? What happens when two providers claim to own the same IP addresses? Does routing break? Does that depend on the route? This is the perfect place to ask these questions, I'm sure there are quite a few people who can explain this in more detail than the article. Maybe I'm not even asking the right questions. Any info is greatly appreciated.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 1) by hedleyroos on Monday July 13 2015, @11:43PM
I'll pipe in with a me too please.
(Score: 3, Informative) by GoonDu on Tuesday July 14 2015, @01:16AM
Elementary knowledge in networking, please take my answer with a lot of salt.
BGP is used for routing between ISP/regions, so when you wish to route traffic from one ISP or region to another, we need to determine the shortest route to take (very much like routing between WANS). From what I can get from the article summary, the IP address block isn't exactly under Aruba jurisdiction, the ISP can't really log what goes on between those infected machine. Instead, the spyware could be reporting activities back to home. However, when it went dark, no one knows what happened so by owning the IP block, the ISP could track what goes in and out of the machine's traffic and hand in the logs to the law enforcement.
I must apologise if I make any serious mistakes. It's been a while since I touched on networking.
(Score: 5, Informative) by isostatic on Tuesday July 14 2015, @01:34AM
Also a basic knowledge. I use BgP, but only in a private network.
Each network provider connects to some other providers and advertises its own subsets to them. "Reach 1.2.3.0/24 via me", they say.
Those other providers then advertise those networks- reach 1.2.3.0/24 via me, then him
Then the next one in the chain advertises them again - reach 1.2.3.0/24 via me, her, then him
If your ISP wants to send a packet to 1.2.3.0/24, it looks at the potential routes and chooses the best one. Typically the shortest, but there are a variety of factors, including the most specific route (an ISO will route to 1.2.3.0/24 ahead of routing to 1.2.0.0/16.
What seems to have happened here is that a rogue ISP has said "I can reach 1.2.3.0/24", and pushed the routes out. Neighbouring ISPs believe it, and send the traffic their way.
I have no idea why they've done this. The trouble is that while most ISPs will filter incoming routes, it's hard to filter out /24 adverts without breaking the internet. If you own a /24 and want your ISP to advertise you, you need those routes to be accepted by your ISPs peers and transit providers. In this case the subnet stopped being advertised at all, then started being advertised via a new ISP. The same thing happens legitimately every day, of an ISP is found to advertise fraudulent routes they will be dropped by their peers though, so the problem is usually self policing. If you can't drop an ISP (say it's Pakistan telecom, dropping them would break Pakistan), you heavily filter them and risk problems down the road should someone want to move a /24 to them.
(Score: 0) by Anonymous Coward on Tuesday July 14 2015, @01:57AM
What irks me is that IPv6 won't solve the BGP problem, it will only make it worse. I don't get it why IETF couldn't come up with a better protocol, since IPv6 isn't compatible with IPv4, it wouldn't hurt to create a new and better BGP protocol while they were at it.
(Score: 3, Interesting) by gnuman on Tuesday July 14 2015, @03:40AM
1. IPv6 makes routing tables easier to filter. A North American block should not generally appear from South Africa. IPv6 aims at geographical fragmentation.
2. IPv6 is easier on routers because it handles TTL differently.
3. IPv6 requires much less routes since localized entities will never run out of local IPs. If you get an IPv6 /32 route, you will not exhaust it, unlike a tiny in comparison IPv4 /24
Anyway, BGP has little to do with actual IP protocol version.
(Score: 2) by sjames on Tuesday July 14 2015, @12:37PM
BGP is truly a separate issue. It is simply one of many protocols for exchanging routing information. Eventually there will be a new version of BGP that can handle v6 and v4.
But it's a hard problem. Consider, what is your suggestion for assuring that someone announcing a route has the right to do so? Clearly there would have to be some sort of cryptographic proof of delegation involved. But it can't be a central registry since a router just booting won't have a route to the registry until it has already accepted many routes into it's table from BGP. Next up, how do you aggregate routes without losing the proof?
The originator of a BGP announcement has no idea what routers may pass that announcement on. Consider, you announce (legitimately) a route to 1.2.3.0/24 (a block allocated to you) to two upstream ISPs. Eventually, both ISPs announce that route (possibly as part of an aggregation) to their peers. If a transit agreement is in place, some of those peers may announce it to their peers. Otherwise, they will still announce it to their own customers who have elected to recieve BGP (perhaps because they are multi-homed).
Other than your upstreams verifying (as they generally would) that you have a right to announce 1.2.3.0/24, nobody else in that mass of routers who may announce a route to you can logically validate the announcements. Does ISP C which you don't even know exists have a right to announce a route to 1.2.3.0/24 to a router in Mongolia? Turns out, it does because they are a peer to ISPD which is a peer to ISPB who is one of your upstreams and they have a transit agreement in place. If they don't announce that, people in Mongolia can't reach you.
Finally, remember that none of this is static. The failure of a port halfway around the world may totally change who is announcing a route to your class C and where they are announcing it. That's how the internet routes around damage.
.
(Score: 2) by VLM on Tuesday July 14 2015, @11:53AM
What happens when two providers claim to own the same IP addresses?
If you do this intelligently then this is great, its just multi-homing. Very reliable, good idea. If everyone is on the same page.
Note that anybody speaking BGP and talking to other BGP speakers IS a provider. Even if they're a stereotypical end user (major business, whatever) with their own IP space and connections to five upstream ISPs. Lets say provider A is AS #1 and provider B is AS #2, the end user is AS #3 and advertises their space, and they have a connection with providers A and B and neither advertise ("claim to own") the space, is the end user AS#3 which does the advertising.
If you want a real troubleshooting headache you could have the upstream providers advertise the space themselves, but that's a great way to make a routing black hole if the connection between a provider and the end user drops and the provider doesn't stop advertising the route, all that traffic will get tossed.
There is no global routing table every router has a different view on reality. For a good time google "BGP looking glass" those are (usually web based) BGP speakers all over the net as a public service let you look at the route to an address, (and usually a bunch of other things). So ask a looking glass in Euroland for the AS path to "somewhere" and that path will look nothing like the AS path for a looking glass in Chicago, at least for the first couple hops anyway.
When I was still in the business about a decade ago, if a BGP speaking customer wanted to start advertising new space we'd demand a simple one page signed letter of agency scanned, FAXed, or mailed to "us" then I'd adjust their prefix lists to allow the new space thru (with BGP you can filter what you'll listen to from people in BGP announcements, which is completely distinct from filtering traffic, which often confuses the hell out of people because the router syntax is roughly similar). There were some customers of very long relationship I'd trust to fix the paperwork later, and others with shall we say the opposite relationship where I'd put extra effort into verification to figure out if they had any idea what they were doing because they were always Fing stuff up.
Wrangling BGP sessions for customers was an interesting job, but theres only "X" positions to do it, and every year "X" declines because of consolidation and cost cutting and outsourcing, while Cisco graduates enough CCNP and above with qualifications to fill every single position... every year. So to say there's an oversupply of qualified workers to do the job would be a huge understatement. There are supposedly BGP jobs if you're willing to move to some hellhole where it takes $250K to not live under a bridge but they only offer $120K, and/or take $40K/yr to live in a civilized area, which I'm not interested in. So when that company sank, I went into dev work, at least there are some job openings for that everywhere, and usually at higher pay.
I did all the Cisco cert stuff, long since expired, and they were pretty good at what they were. As a guy who did routing stuff all day, I took the routing test for CCNP (back when it was four tests, routing, switching, troubleshooting, and WAN) and didn't study anything but the legacy ISIS stuff, and it was pretty fair, its not a paper cert. What was a little weird is what I spent most of my brain cells spinning on the job, wasn't even remotely on the test. So you'll have a cert that accurately says you can program a router to speak BGP and "do things" but you'll be left with no idea what to do or why or how, outside strictly typing on a router. So I'd say the cert stuff only gets you maybe half way to understanding BGP.
(Score: 2) by sjames on Tuesday July 14 2015, @12:39PM
The machines they were monitoring had trojans on them phoning home. The ISP housing 'home' went away. Since the trojans were contacting a fixed IP{ address, the only way to restore monitoring was to grab those IPs and route them to an active server somewhere.
(Score: 2) by jasassin on Wednesday July 15 2015, @02:51AM
Ah ha! Thanks man.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 2) by jasassin on Wednesday July 15 2015, @03:43AM
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 2) by sjames on Wednesday July 15 2015, @10:11AM
Typically when you colo a server, you use IPs assigned by the colo provider (ISP). That provider went belly up.
(Score: 2) by jasassin on Wednesday July 15 2015, @11:19PM
Gotcha. Thanks to everyone who helped explain!
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A