Telkom & the Man-in-the-middle attack - ROUND 2
This is a follow-up to my post on the man-in-the-middle attack that Telkom continues to use, as well as to the Telkom response in the awesome TechCentral article and new thoughts brought about by the Reddit post.
A real threat
Shortly after I posted my article, I was contacted by someone (let’s call them Person X), who went snooping based on my post and found that Telkom did indeed have a major security flaw in the system. We agreed to hold off sharing the information publicly until Telkom fixed it—or enough time had elapsed to show they didn’t care. Telkom appears to have fixed it, as far as I can tell, so let’s dig into this major attack vector.
Recapping the content served to you is made up of three pieces:
- JavaScript – this is appended to other JavaScript to ensure it runs, and the entire modified JavaScript is returned from a specific server. This server is only visible on the Telkom ISP network.
- HTML – a bit of HTML is loaded, once again from the same server as above.
- Image – the graph showing you usage is a static image served from a server, which is (oddly) available everywhere: http://images.telkomsa.net/
Person X realized that the images came from a folder /ibn and that folder had directory listing enabled—which isn’t a good practice, but normally not a major security concern. What the directory listing showed, besides the files, was the version number of the server, which was (at the time) 2.0.52.
Apache 2.0.52 was released in November 2004—11 years ago—and has numerous security flaws. There’s no reason to run this version at all—it’s insecure and highlights a major security procedure flaw at Telkom. Using one of the flaws, it was possible to replace the specific image on the server with anything you wanted. For example, you could swap the image file with a Flash file that would enable you to use one of the recent zero-day attacks against Flash—and leverage Telkom’s system to deliver said Flash file to the user. This would allow you to own the target machine.
Remember, this popup only shows to people who meet the following three requirements:
- Telkom ISP client
- At or near their limit
- Have not opted out
I would assume that the tech-savvy of Telkom’s users have opted out, and those near their limit are soft-capped, meaning that security patches are slower to reach them. In short, it’s the most vulnerable group who would be targeted. Scary, right?! Let’s hope Telkom fixed all the issues with that server—and all the others.
Comments on Telkom’s choice of wording
I’m really happy Telkom has responded and is fixing things—that’s all I wanted. That said, their choice of wording and delay in commenting until they fixed the issue is interesting. Let’s break down their response, and I’m avoiding nit-picking since I could do a lot of that too.
In technical terms, we refer to it as an HTTP redirect
That’s true. It is an HTTP redirect, but the manner in which it’s used is not in the traditional sense, where the destination server tells the client to go somewhere else. Here, a man in the middle (see what I did there 😜) is doing the telling—and thus I chose the term MITM attack as the description. It’s not an exact description, but it describes the entire scenario, not just one aspect of it.
HTTP redirect is a common mechanism used in service provider networks for content caching and to optimize video streaming.
True again. That said, in those scenarios, service providers don’t change the content—they only alter the destination for better performance for the user. Telkom is changing the JavaScript content, and there’s a fundamental difference there.
does not alter the Web service content
In my previous post, I showed that they are changing the JavaScript content, so that’s pretty incorrect.
is not a security risk
See above—and then realize it was only true when it was said, not the day before.
will not “break” a website
The web is a big place; it’s impossible to know that. I also wonder why “break” is in quotes—is there more than one definition of it?