NewSat network breach 'most corrupted' Oz spooks had seen: report Defunct Australian satellite company Newsat distinguished itself in a way never known to the public before the company went under: it was so badly hacked it had 'the most corrupted' network the nation's spy agency had encountered. The company's assets were sold off last year after it went into administration. Unnamed sources …
I had a little exposure to Newsats IT infrastructure as an external consultant. What I saw scared the hell out of me, and I was amazed at how poor their security was. I couldn't believe an ISP's core infrastructure could be so badly put together, so out of date, so insecure.
I am in no way surprised by this article.
More or less the norm today in SAT comms. The exceptions are Boeing and Inmarsat - there is money serving in aircraft and ships.
As far as the rest - it is difficult to attract the level of tech staff needed to maintain a network when you are collecting a pittance from customers which are constantly late on payments while at the same time you have to pay an arm and a leg for SAT transponder resource. All of that results in marching from one insolvency to another.
So no surprises really.
They see everything going through their pipes, they can do what they will with it and you have no idea what they are up to, nor much of a recourse if you don't like it.
The least they can do is provide proper network security and functionality, and doing so for the customer means keeping the house in order.
The fact that an Australian ISP has government-issued surveillance equipment is not surprising these days, even if it is a bit disappointing. I'm sure it is just one of the many - although I'd be interested in a per-country comparison of how many ISPs do have such government surveillance on-premise. Maybe that could be one point of a Freedom Index chart ?
If I own the pipes, I see your security negotiations and I can man in the middle you with absolutely zero effort. You'll never know I'm pwning you.
So unless you have an alternate channel for disseminating your keys - which 99.99999999% of orgs and individuals do not - a compromised ISP == "everyone is fuxxored".
"If I own the pipes, I see your security negotiations and I can man in the middle you with absolutely zero effort. You'll never know I'm pwning you.
So unless you have an alternate channel for disseminating your keys - which 99.99999999% of orgs and individuals do not - a compromised ISP == "everyone is fuxxored"."
Trevor, if that is your understanding of how TLS, even without PFS, works then you should immediately hand back your gold badge, hang up your credentials on the coat hook and cease writing any more articles for tech sites.
Funny how it's doable in practice. It's detectable*, if you know what you're looking for - and thankfully browsers have stepped this up a little - but proxying TLS connections in this fashion is absolutely possible. The key is to control the entire negotiation process instead of trying to intervene in one that's already started.
You can not simply insert yourself mid stream to an extant session. You can, however, cause the client to negotiate the TLS connection with your MITM proxy while your proxy negotiates a TLS session with the target site.
All the client traffic goes from the client to you whereupon you decrypt, sniff the traffic and forward on down the next TLS session to the target site.
Yes, it requires that you have a certificate that the client trusts. And ideally you would be able to spoof the site in question with this cert so that if your client thinks they are contacting bob.com they don't end up with a trusted cert from proxysrus.com.
But this is really just a discussion about root certification trusts at this point, and we all know that the entire cert authority system is pretty broken.
So I'm back to: if you can insert yourself between the two endpoints you can MITM TLS connections. It takes some effort, some creativity and some illegality, but it's absolutely doable. Innumerable corporate security products rely on exactly this, as do various state-level spying initiatives.
The difference between them is merely how they go about obtaining trusted root cert status.
*A great tool for this is the add-on Cert Patrol for Firefox. It will let you see when certs for a site have changed, even if they're "valid" re: root certs. Of course, a lot of companies with large infrastructures change certs regularly, or even deploy multiple valid certs from multiple valid providers! This practice makes MITM attacks all the more viable, especially for large/popular sites, and it also makes it harder to detect in practice because you become immune to Cert Patrol warnings after a few days.
So you are saying your statement "If I own the pipes, I see your security negotiations and I can man in the middle you with absolutely zero effort. You'll never know I'm pwning you." is a load of scaremongering bollocks?
What you actually meant to say was that you have to own a trusted root or scammed or socially engineered a CA to give you domain certificates for every site that your customers may wish to visit and be able to use it long enough before it is revoked. Of course you can MITM if you have that, FFS! That's why you can't do that unless there has been some serious procedural failing and that is why TLS and certification was developed to make sure your ISP (or any other MITM) could not snoop on your traffic. If a CA hasn't somehow been compromised and you are using best practice protocols and PFS, there is no known way to MITM at the present time.
The fact that it can't readily be broken (as long as a trusted root is trusted) is what keeps the internet secure and it is why some parties want everyone to switch their sites to HTTPS.
However it still returns to your comment that if you are an ISP (a MITM) you can't decrypt everyone's traffic just by monitoring the handshakes - it's a complete misunderstanding of the basics of TLS encryption and authentication or asymmetric cryptography in general. (If you've find a viable way of cracking it or a sure fire way of using generating trusted certs then go speak to a nation's intelligence services as you're in for a mega-bounty.)
Oh yeah and "Innumerable corporate security products rely on exactly this, as do various state-level spying initiatives"? Corporate security products get the security administrator to install the security product as a trusted root on all domain PCs! You can only surmise what the intelligence services may or may not be able to decrypt and how, however as fake trusted roots or certs can be spotted they can easily be revoked. Either way, you were talking about being an ISP and how there is "absolutely zero effort" for them to decrypt your traffic, laughable!
Sorry, but I don't see getting trusted root certs as being all that hard. Pretty much zero effort, when you look at just how easily that particular scam has been pulled off before.
It takes a lot - a lot - to get browsers to pull trust for a cert, and comparatively little to set up a CA and get into the list. Especially for ISPs.
Designing a network and physically putting it in place is a lot of effort. It's stupid money, requires a huge number of people and takes crazy amounts of time. Becoming a CA and then abusing it, or using already abusable certs from generally trusted CAs, or any of many other techniques (you need to install our software in order to use our internet) is basically zero effort.
You make a choice about how you want to ruin your reputation and then you do the paperwork. You will eventually be caught, but you can absolutely spoof the TLS traffic quickly and easily.
As you state: Internet security basically relies on the system. Something you seem to think actually works.
I, however, view the CA system as completely broken and pathetically easy to manipulate, especially when compared to other very tangible considerations of running something as big as an ISP.
Cheers.
"Sorry, but I don't see getting trusted root certs as being all that hard. Pretty much zero effort, when you look at just how easily that particular scam has been pulled off before."
"You will eventually be caught, but you can absolutely spoof the TLS traffic quickly and easily."
Oh Trevor, some of your articles I thought were well informed. If what you write is just based on no fact, or research just some wild eyed crazy theories then I'll have to think again when reading your stuff and remember that what you write could just as easily be a load of garbage.
You dug a hole by thinking you could just intercept the security handshakes (as you clearly stated in your original post) and have tried to dig out of it by saying it is trivial to set yourself up as a trusted root cert provider accepted by the major browsers.
If you believe this to be true then go ahead and let me know when firefox has the Trevor_Pott Certs Inc trusted root certificate installed. Alternatively put a post on mozilla.dev.security.policy stating how trivial it is for a fake trusted root to get into Firefox (or the other respected groups from other manufacturers). Anyone who thinks breaking (best practice) PKE is trivial is either a genius or a lunatic - Trevor, you are no genius.
It takes a lot - a lot - to get browsers to pull trust for a cert, and comparatively little to set up a CA and get into the list. Especially for ISPs.
That's understandable. A browser provider that pulls trust for a major (if untrustworthy) CA is liable to thanked by the CA for that action in the form of a lawsuit for defamation/libel/whatever. It may happen that keys are revoked at the CA's request, but it would be contentious for a browser provider to unilaterally bar a given CA, especially when that CA is a commercial concern whose profitability will be affected by the bar.
PKIs are quite good at arbitrating trust when given a base set of trustworthy CAs to work from, but as soon as that trust is eroded by bad certs in the store the whole system starts to crumble. It's not entirely a tech problem, though -- what's needed is some out-of-band system for ensuring that the case set of CA certs can be relied upon to be trustworthy. An easy way to check the root certs' validity (such as a published list of cert fingerprints in print media) would help.
Let's not forget that another way in which an ISP can subvert the security of a connection is by MITMing a connection and switching from HTTPS to HTTP. An ISP that does this while the end user is downloading a new browser can (for example) substitute a browser image with an already-poisoned root CA store and the user -- if he hasn't already noticed the switch to HTTP -- is unlikely ever to discover the deception.
"...is by MITMing a connection and switching from HTTPS to HTTP."
Eh? How can they inject HTTP data when the client has requested HTTPS? That doesn't make sense.
They can capture the initial HTTP request and not allow or intercept the https redirect but not the other way around. They can only do the http intercept if your site doesn't support HSTS or isn't an HSTS qualified connection.
I'm not sure I could hack my way out of a "hello world" statement. Written correctly, it shouldn't have an attack surface.
Also, how am I in a line of code? If I echo myself out of a line of code, is that me that escapes to the display device, or merely a copy of me? Oh the existential horror of it all...
"So unless you have an alternate channel for disseminating your keys - which 99.99999999% of orgs and individuals do not"
Here's some ways in which I have exchanged keys and passwords with other organisations:
Phone
Post (ie snail mail)
Physically going round to their office
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
