Detecting QUANTUMINSERT

Fox-IT has a blog post (and has published Snort rules) on how to detect man-on-the-side Internet attacks like the NSA’s QUANTUMINSERT.

From a Wired article:

But hidden within another document leaked by Snowden was a slide that provided a few hints about detecting Quantum Insert attacks, which prompted the Fox-IT researchers to test a method that ultimately proved to be successful. They set up a controlled environment and launched a number of Quantum Insert attacks against their own machines to analyze the packets and devise a detection method.

According to the Snowden document, the secret lies in analyzing the first content-carrying packets that come back to a browser in response to its GET request. One of the packets will contain content for the rogue page; the other will be content for the legitimate site sent from a legitimate server. Both packets, however, will have the same sequence number. That, it turns out, is a dead giveaway.

Here’s why: When your browser sends a GET request to pull up a web page, it sends out a packet containing a variety of information, including the source and destination IP address of the browser as well as so-called sequence and acknowledge numbers, or ACK numbers. The responding server sends back a response in the form of a series of packets, each with the same ACK number as well as a sequential number so that the series of packets can be reconstructed by the browser as each packet arrives to render the web page.

But when the NSA or another attacker launches a Quantum Insert attack, the victim’s machine receives duplicate TCP packets with the same sequence number but with a different payload. “The first TCP packet will be the ‘inserted’ one while the other is from the real server, but will be ignored by the [browser],” the researchers note in their blog post. “Of course it could also be the other way around; if the QI failed because it lost the race with the real server response.”

Although it’s possible that in some cases a browser will receive two packets with the same sequence number from a legitimate server, they will still contain the same general content; a Quantum Insert packet, however, will have content with significant differences.

It’s important we develop defenses against these attacks, because everyone is using them.

EDITED TO ADD (5/14): Detection for QI was recently released for Bro, Snort and Suricata.

Tags: browsers, Edward Snowden, hacking, NSA, QUANTUM, TCP

Posted on May 4, 2015 at 6:17 AM • 55 Comments

Comments

keiner • May 4, 2015 7:15 AM

Suricata, which is a derivative of Snort (f*cked up by being bought by the NSA subsidiary CISCO) is developed on behalf of

US HOMELAND SECURITY

http://suricata-ids.org/about/consortium/

…the same US HOMELAND SECURITY requests stopping encryption:

http://gizmodo.com/dhs-secretary-begs-silicon-valley-to-stop-the-encryptio-1699273657

This US HOMELAND SECURITY sh*t can only be part of the problem or part of the solution. Choose yourself…

Momo • May 4, 2015 7:23 AM

Best hope there’s no stateful firewall not under your control between your network and the attack.

mike~acker • May 4, 2015 7:25 AM

this should fail on any SSL or TLS connection: the attacker should not be able to steal the session key.

without the session key the attacker could not properly encrypt the packet to be inserted

the session key should be generated during the SSL/TLS “handshake” and once generated — encrypted with Public Key Encryption — and then sent to the Client machine.

as a result — only the client which initiated the communication session will be able to decrypt the packet that holds the session key. and that would be game over for our QI attacker

if SSL/TLS is not doing this properly then all of SSL/TLS is entirely compromised and we need to talk.

65535 • May 4, 2015 8:32 AM

I am interested to know if Fox-IT’s code patch for Snort really works against packet injectors like Quantum Insert/Fox acid. I have seen Snort used as a firewall with good success. It would be welcome news to find Snort can be patched to protect against state sponsored packet injection. I would recommend it for my customers.

I see some qualification [which seems minor]:

“…it’s possible that in some cases a browser will receive two packets with the same sequence number from a legitimate server, they will still contain the same general content; a Quantum Insert packet, however, will have content with significant differences. The researchers have detailed in their blog post other anomalies that can help detect a Quantum Insert attack…” -Wired

http://www.wired.com/2015/04/researchers-uncover-method-detect-nsa-quantum-insert-hacks/

I read this to mean Fox-IT/snort combination will almost always detect the Quantum Insert packet injection – but may not always block it.

Some other remediation must take place in certain instances. This Fox-IT/Snort combination would certainly benefit the non-encrypted website to browser communications [The majority of websites are not encrypted and would benefit].

This also assumes that Snort has not been compromised by the NSA.

Am I close on the Fox-IT/Snort assumption?

keiner • May 4, 2015 8:43 AM

@65535
I’m a snort user but far from an expert and would read it that way that by the differences in package load (legit server and QI) the two packages can be differentiated and the detection will work, while when a legit server sends two packages with same seq. number this will be detected as a false positive due to the same package load.

bob • May 4, 2015 9:44 AM

@65535
Blocking Injected packets will be difficult as you cannot be certain which of the duplicate packets is the inserted one. Ofcourse you could check TTL differences, and other anomalies. But they can be faked to be the same as well.

keiner • May 4, 2015 9:47 AM

@bob

But snort blocks based on IP, so both, the legit. as well as the fake traffic should be blocked. The browser should show nothing…

tsl ssl retort • May 4, 2015 11:18 AM

@mike acker

tsl/ssl IS very broken. google beast attack. This nsa quantum insert attack works for two reasons: 1. They can connect to your machine faster then you destination page can. And 2. They have ALL the Certificates from the signing companies so they can impersonate anyone.

So yes, the system is very broken. Don’t tell anyone, wouldn’t want to up set the people. Just like how the MLK documents are out, etc. It goes on and on. The truth is out there, but unlike Fox Mulder, out there isn’t very far. In fact, either your local library or nowadays, your very own in-home networked computer allows you to view the shocking truth about the world – just laying around!

The great scam here is not that powerful governments hide and sneak and spy and manipulate their own people! The scam is that the people have all knowledge and means to understand and end these crimes but do nothing!

Bob S. • May 4, 2015 11:21 AM

Yes, “EVERYONE is using them” (packet injection): USA GB GER China, crooks, hackers crackers your next door neighbor.

It would be a different story if the National SECURITY Agency and it’s ilk used their resources to make the internet SECURE. Instead, we know now they see their job as DESTROYING SECURITY so they can collect electronic data from EVERYONE in the world, including the people that pay them (taxpayers) and those supposed to be their bosses (Congress).

Based mostly based on the Snowden Revelations we know their game anymore. We may not know every one of their plays, but we know what the rules are:

There aren’t any.

That’s NOT the way a democratic republic is supposed to work, no matter how many times repeat the BIG LIE: “It’s all legal”.

on snort info • May 4, 2015 11:22 AM

This is not unique to FoxIt/Snort. All you need is a simple packet sniffer. The attack works by matter of being faster, that is all. So if your session is hijacked, two packets with identical headers/ACK codes will arrive.

Just watching for DUP packets at the start is all you need to do. Of course, when you start doing that suddenly you are very easy to Denial Of Service, as you will drop connections with doubled start packets. Well, you can’t have everything, can you?

James Sutherland • May 4, 2015 11:31 AM

Presumably the inserted packets will also be defeated if the target HTML stream is gzip-compressed, let alone anything more elaborate like SSL – which might suggest they’d have to do something beforehand to disable gzip on target requests as well, unless they just rely on the target sites all lacking that feature?

Gerard van Vooren • May 4, 2015 11:58 AM

AFAIK Minimalt solves that with mandatory PKI. It is still not released however…

Jeff • May 4, 2015 12:34 PM

Why can’t the MITM just delete the real packets?

Andrew Wallace • May 4, 2015 1:01 PM

This is traditonal man in the middle with a sexed up name used by the NSA from old documents that Snowden had access to and decided to publish to main stream media outside of cybersecurity circles.

The defences required are no different from traditional man in the middle attacks.

All we have learned is that the NSA years ago were using the same tactics as teenagers in the same era just with a more organised and funded approach and for national security agenda purposes.

Rather than the teenagers who were doing it for their own entertainment or to gain credibility among online peer groups.

Even with Stuxnet that the NSA were alleged to have carried out. The tactics resemble that of what teenagers use just with a more organised and funded approach.

To sum up, the NSA are paying close attention to online peer groups from teenagers who are unsuspectingly giving the NSA tips for their next attack designs.

The NSA are on the same page as the teenage hackers but are able to launch the same attack style class with more sophistication.

Bruce said in You Tube videos that it has been the teenage hackers learning from the NSA passing tactics down to UNIVERSITY grads doing a thesis.

I believe the opposite. It is teenage hackers being eavesdropped on are leading the next attack designs for the NSA to take tips from.

Andrew

Jesse • May 4, 2015 1:10 PM

@on snort info:
You can’t be that easy to DoS, as people would at least need to be able to spoof source IP packets to you in direct response to your TCP connection requests. Anybody in a position to do that is already in a uniquely simple position to mess up your shit compared to, say, any random script kiddie on Xbox live. :J

@James Sutherland:

Presumably the inserted packets will also be defeated if the target HTML stream is gzip-compressed

Why would that have any effect on anything?
1> Your browser has to announce it’s willingness to work with gzip codec in it’s request headers, and then the server has to announce in it’s uncompressed headers that the payload will be compressed. QI is already on the case from the beginning of the server headers. Even if the real server is passing back gzip data, QI packets can elect to pass back uncompressed data with headers basically reading “Sorry, I don’t feel like sending you anything gzipped today!”

2> The first packet for any non-trivial webpage will always be 1500 bytes (or whatever the chosen MTU is, 1500 is the most popular) so even if the original packet is gzipped, it is not smaller than the QI packet.. it just has a greater portion of the uncompressed payload packed into it.

3> QI could offer you as small of a packet as they feel like, nobody is holding a gun to their head to fill the 1500 bytes.

4> Even if the real packet were smaller than the QI packet due to compression, QI wins thanks to latency not thanks to bandwidth. We are talking about a race between two individual datagrams and not two very long file downloads.

5> If QI felt like compressing it’s payload, there is nobody stopping that either. Gzip is an embarrassingly simple stream-filter codec to apply to anything that moves.

Hello, QI could compress the attack pages impersonating servers that don’t support compression, if they’d like. xD

Nick P • May 4, 2015 2:59 PM

@ Andrew Wallace

Great assessment. I agree entirely. Ill add that they’ll leverage academia, industry, and black hats for developing new techniques as well.

Clive Robinson • May 4, 2015 3:12 PM

@ on snort info,

Of course, when you start doing that suddenly you are very easy to Denial Of Service, as you will drop connections with doubled start packets. Well, you can’t have everything, can you?

Maybe not but you can have a little more…

Think a little further on the issue of your statefull firewall

Think not so much on just matching packets by their content but also by their time component as well (thing not also not just a time component but also another dimenson as well).

But also think not so much of dropping packets but capturing them and seperatly analysing them further.

With a little further thought you can see a way to differentiate the wanted from the unwanted packet.

Once you know the bad packet form you can use it in a number of ways, not least is to help recognise further bad packets.

By no means a perfect solution but it raises the bar quite a bit for the attacker, which in effect moves them on to another game.

MrC • May 4, 2015 4:26 PM

Where exactly is the redundant (legit, too slow) packet getting discarded by the victim? Presuming that it’s the browser that’s doing the discarding, then I’d think that the appropriate place to be doing this kind of detection would be baking it into the browser. The public at large is not going to go download snort, plus the patch, plus the definitions. Simply not going to happen. They might pay attention to a browser warning saying “hey, looks like you’re getting QIed here.”

Q • May 4, 2015 4:32 PM

Pardon the naivete, but could this technique be implemented in browsers? Seems like a relatively simple change.

John • May 4, 2015 4:36 PM

@65535 Main reason for a legitimate server to send two packets with identical sequence numbers is a resend due to a NAK (packet got corrupted), or a resend due to a timeout (missing ACK). In either of those two cases, the payload of the packets would be identical or close to identical. So it seems to be a darn near perfect detection of a QI attack is to maintain a fairly short term log of incoming uncorrupted packets where the log contains the associated IP addresses, sequence number, and a hash of the packet content. Reason for storing only uncorrupted packets is to eliminate the case of a packet getting corrupted en-route. Then if a packet is found that has the same IP addresses and sequence number, but differing content hash, then a QI attack has been detected.

Grauhut • May 4, 2015 5:35 PM

I doubt this works.

If i were a member of the “Equation Group” i would reroute your GET request by sending a routing message after your SYN, destination would be a route to a content manipulating “spoof every ip” proxy and the original machine wouldnt even see a GET, just a lost connection (happens billions of times a second )so it would not answer directly after a dead SYN-ACK and there would be no dup packages.

In my world you would have to scan for dup SYN-ACKs, but this also only works if they forgot to also reroute the traffic from the original server to the victims box ipaddr to a black hole of their choice.

Andrew Wallace • May 4, 2015 5:55 PM

The NSA have two options:

Eavesdrop on teenagers
Hire teenagers

We’ve seen an emphasis on a recruitment drive in the last few years so option 2 is picking up more momentum than it was in the past.

Teenagers sitting in their bedroom for hours on end are the main leverage of innovation coming out of NSA.

Nobody likes to admit that and to be honest it would be embarrassing for anyone in the NSA to talk about but it is what is going on.

We see the NSA as a vast superpower so to admit they get their tips from teen hackers is something rather not talked about.

Why do we know this. We just need to look at the Snowden documents to work it out.

The embarassment for the NSA is not that Snowden has stolen the documents it is what the documents say about the NSA and who NSA keep an eye on and taking tips from.

For it to be known that NSA has been taking tips from teenagers in bedrooms is of deep embarrassment for the American administration who finely trim their public profile of something far more superior.

The bubble for the NSA is not burst but its bouncing all over the place.

Sure, NSA have been keeping an eye on politicians such as Merkel for geopolitical intelligence but for technical intelligence its been teen hackers.

What does that tell us as a community.

It tells us NSA keep an eye on exactly the same people we do and don’t have anything superior to anyone else as far as geopolitical and technical intelligence is concerned.

We’re looking at the same stuff as each other.

We’ve been worried that the NSA have been doing different stuff but it looks like NSA are on the same page with only a slight give and take margin.

There has been a worry in the community that NSA have been streets ahead but that’s not what the Stuxnet and Snowden documents are telling everyone.

The NSA is essentially the byproduct of teen hackers with an on steroids budget to beef up teen tactics.

Andrew

LarryH • May 4, 2015 7:26 PM

@AndrewWallace

I doubt teenagers dig cryptography. However, your point certainly isn’t without merit (logic?). Therein, lies the power of mass surveillance. We focus on watching for terroristic tendencies, predicting crimes, and other vices over the Net, but it is also a vast knowledgebase to learn from, provided that it takes one to know one.

BTW, I’ve been enjoying your posts because they are simple and soothing.

Nick P • May 4, 2015 10:25 PM

@ Andrew Wallace

You went from a decent point about NSA knocking off others’ work to sheer nonsense. NSA has a lot more than those options. They hire all kinds of people for SIGINT, most of which aren’t teenagers. Most of their R&D is academics with basic COTS kits coming from offensive computing companies and zero days from black market. I agreed that they’d knock off anyone’s work once they published it but there’s zero evidence that they’re just hiring teens massively. Most published evidence is to the contrary.

Wouldn’t surprise me if a large number of their script kiddies joined after high school. That’s still speculation, though, as we know little about them. You seem to be derailing the discussion with strawman points again.

Gweihir • May 4, 2015 10:35 PM

Detecting that type of insertion with a passive tap is dead easy. (And a passive tap cannot be detected by the attacker.) All it needs is a hash-table (key: seq_no ++ h(payload)) coupled with a queue for aging or, alternatively, explicit garbage collection. A small device like an Raspberry Pi (or the far, far better Banana Pi) should be quite able to do it for a home network. Of course, this gets a bit more difficult if they split the insert (sending several packages for one original one), but even then just keeping the first, say, 1000 bytes of each new connection and looking for deviations in data would be enough. Or just detect the deviation in splitting. On detection, log everything and maybe sound a bell or the like. Personally, I would kill the connection, just to be safe.

Basically, this is a project for one rainy weekend to get it to work and some additional ones to make it general enough to give away. May be something I will put on my Linux firewall in the future.

Philip Van Hoof • May 5, 2015 4:46 AM

I keep wondering about this MIN in the patch: if (memcmp(p->data, seg->payload, MIN(p->dsize, seg->size)). Doesn’t that mean that you can still place the insert after the size of the smallest and not get detected by this?

The FoxIT article mentions that a retransmission with a different payload size will sometimes look like a QUANTUMINSERT, this can happen when a retransmission is cut short, for example during TCP window size changes. But doesn’t the session need a new SYN/ACK for that anyway (which requires changes to the sequence numbers).

I noticed that they recently changed the patch from comparing p->data to p->payload. Does this solve it (I’m not an expert in snort’s apis, so I don’t know what the difference is between p->data and p->payload).

65535 • May 5, 2015 10:03 AM

After reading the comments, the detection of inserted packets in an http stream or segment [not the MTU] seems more difficult that expected.

Re-reading the Fox-IT solution it seems they base the decision to flag QI packets on a 10% weight difference in payload. Intuitively, that 10% payload difference seems OK… to a point.

@ keener

“…[I] would read it that way that by the differences in package load (legit server and QI) the two packages can be differentiated and the detection will work, while when a legit server sends two packages with same seq. number this will be detected as a false positive due to the same package load.”

That is the way I read it.

If the two packets with the same payload of 10% +/- amount arrive one could either say it was false positive or a real QI [which should be dropped] which is a problem. This assumes the packet was properly forged with the correct IP data and so on.

@ bob

“Blocking Injected packets will be difficult as you cannot be certain which of the duplicate packets is the inserted one. Of course you could check TTL differences, and other anomalies. But they can be faked to be the same as well.”

That is the problem with a “properly forged” packet. Which brings us back to the decision to drop the packet on a 10% payload differentiation – will this 10% payload differential work?

@ on snort info

“Just watching for DUP packets at the start is all you need to do. Of course, when you start doing that suddenly you are very easy to Denial Of Service, as you will drop connections with doubled start packets. Well, you can’t have everything, can you?”

Good observation.

@ Clive Robinson

“Maybe not but you can have a little more…Think a little further on the issue of your statefull firewall… Think not so much on just matching packets by their content but also by their time component as well (thing not also not just a time component but also another dimenson as well).

“But also think not so much of dropping packets but capturing them and seperatly analysing them further. With a little further thought you can see a way to differentiate the wanted from the unwanted packet… no means a perfect solution but it raises the bar quite a bit for the attacker, which in effect moves them on to another game.”

That is a very good idea. I think there has to be other parameters to determine if it is a real QI packet insertion.

The problem now is what to do if you let the “close call” packets in [to avoid dos’g yourself]. How do you re-mediate the bogus packets after they start the infection process?

Andrew Wallace • May 5, 2015 12:24 PM

Nick P,

Script kiddie is a derogatory term that we should stop using in the security industry.

Andrew

Beepeepeep • May 5, 2015 1:03 PM

@Andrew Wallace

Why should we stop using it? There’s behavior we want to discourage and behavior we want to encourage. We want to discourage reliance on using tools other people write without understanding what the tool exactly does.

Most of the security industry unfortunately are script kiddies nowadays.

Andrew Wallace • May 5, 2015 1:44 PM

Why don’t we call them penetration testers? That is the professional term used.

Andrew

Wael • May 5, 2015 2:47 PM

@Andrew Wallace,

Why don’t we call them penetration testers? That is the professional term used.

Good question! Perhaps because “them” may or may not be “pen testers”, dontcha know?

Describe the characteristics and capabilities of “them”, then look at the thread below. Pen testers are orthogonal to “script-kiddies”.

Classes of attackers

Vatos • May 5, 2015 2:57 PM

If security is wide open (“everyone is using them”), why are we not hearing about the widespread compromise of VISA cards?

I would think that money would be a powerful motive for people to use the QUANTUMINSERT attack

Andrew Wallace • May 5, 2015 5:04 PM

Wael

To me “them” ment young people looking to get hired with no criminal element who are still being ringfenced under the script kiddie tag.

Andrew

Clive Robinson • May 5, 2015 5:19 PM

@ 65535,

The problem now is what to do if you let the “close call” packets n [to avoid dos’g yourself]. How do you re-mediate the bogus packets after they start the infection process?

I have thought about this issue off and on for some time, I first thought about it when MS IE was susceptible to malware using graphics files.

The solution I was thinking about is simple in principle but practice might be harder depending on what level you want to take it to.

That is build a firewall that’s actually part way to being a browser and server –as with thin clint tech– it also acts as a format converter and delay line.

So your client browser sends of it’s request, and it heads off to rryour gateway where it hits this firewall which then forwards the request onto the actual remote site. Under normal circumstances the reply comes back from the remote site to this firewall that builds the page internaly. Once the page is built it converts it into a different form that it then sends on to the client browser as though it had come from the remote server.

When it gets two packets with the expected headers etc but different pay loads instead of sending it onto the client browser it sends a popup warning to the user and if the user decides to carry on it strips out all suspect javascript etc and converts all images to a different format etc.

That’s the rough idea, a lot of the code to do this already exists with various “thin client” and other systems it’s just a matter of somebody cobbling up a prototype, and finding out where the dificult to solve practical problems are.

Of course there will be some issues with web sites that can not function without javascript etc, the question is are people prepared to live without them?

In my case the answer is yes as I have Javascript turned off and various other things as well. OK I can not see slashdot pages and Utube videos, but tobe honest I’m not that fussed, they’ve always struck me as a way to waste your time/life which you are never going to get back… as they say “lifes to short” to waste it 😉

Marcos El Malo • May 5, 2015 6:35 PM

Your idea brings to mind the scheme used by the Opera Mini browser, which received relayed web pages from intermediary Opera servers. Of course the intention was different: the idea was to compress graphics and reduce the amount of data transfered.

Wael • May 5, 2015 8:08 PM

@Andrew Wallace,

To me “them” ment young people looking to get hired with no criminal element who are still being ringfenced under the script kiddie tag.

So you want to call all “young people looking to get hired with no criminal element” penetration testers? What if they aren’t even working with computers or information security? Someone flipping burgers at a joint next to you would then qualify as a penetration tester? Then again a “penetration tester”, by your definition, isn’t one if s/he had a criminal record! I think you need to be more specific in your definition 😉

Andrew Wallace • May 5, 2015 8:51 PM

Young people looking to get hired into the NSA with no criminal background was the context already specified.

These folks should not be described in the same way as a script kiddie and I believe the term is outdated.

Andrew

Marcos El Malo • May 5, 2015 9:08 PM

@clive

My comment three comments up was directed at you. Whoops, should have previewed!

Marcos El Malo • May 5, 2015 9:10 PM

@Wael

Have you forgotten your youth, when your hormones were running wild? I’m pretty sure the great majority of teenage boys are penetration testers (not all successful, of course).

Nick P • May 5, 2015 9:31 PM

@ Andrew Wallace

The term script kiddie originally described people who hacked computers using tools they didn’t understand made by real hackers. They followed step by step instructions for the common case, while getting the help of real hackers in unusual situations. Snowden leaks show that this is how most of NSA’s foot-soldiers work, too. The TAO and offensive computing companies employ the real hackers who package up shrink-wrap tools with instructions and heuristics for their users. This situation is identical to the hacker and script kiddie relationship.

So, they’re script kiddies. Err, script kiddies hitting U.S. government-sanctioned targets in exchange for taxpayer money. So, script kiddies with a bankroll and get out of jail free cards. Must be nice.

Wael • May 5, 2015 9:56 PM

@Marcos El Malo,

Apparently so… Wait until @Figureitout reads this! He’s gonna have a field day with you 🙂

@Andrew Wallace

Young people looking to get hired into the NSA with no criminal

Still not penetration testers only! Some could be developers, some could be architects, and some… could be proctologists! You dig me?

and I believe the term is outdated.

I’m not aware of that! What replaced this term?

Figureitout • May 5, 2015 11:24 PM

Clive Robinson RE: utube
–Actually you’re missing out on quite a bit funny videos and more importantly some informational ones (just don’t read the comments, you might get cancer lol). These days, once I get the funds (probably after I graduate, but I’ll be ready to implement) to get multiple connections and truly dedicated modern PC’s; it’s good to have PC’s dedicated to surfing “unsafe web” for research/enjoyment, then others for “safer web”, then local network, then air gap.

Not to mention some things on my school network are reliant on javascript (I always had to download an insecure version of Adobe flash to do physics homework online at home, someone could just crack my account and screw my grade) and it’s frickin’ embarrassing, they used to do their own thing and it was good before selling out to google; now they got the “NSA/DHS” seal of approval…lol. So backdoored garbage then, it’s not going to be funny when it fails big time. And the printers are wide the f*ck open, looks like crap, no craftsmanship. I don’t get it, brand new printers then installing them like crap.

Wael
–Don’t get it. I’m always super calm and non-passionate and never let my emotions get the best of me. :p

But seriously I don’t want more beef and don’t have anything to prove to anybody. Don’t care.

Clive Robinson • May 6, 2015 1:55 AM

@ Marcos El Malo,

Your idea brings to mind the scheme used by the Opera Mini browser, which received relayed web pages from intermediary Opera servers. Of course the intention was different…

Yes, it’s a funny old world like that, several unrelated people trying to come up with solutions to various different problems arive at the same basic underlying idea.

The upside when it happens –and it has happened to me quite a few times– is it gives confidence that you are thinking in the right direction. The down side is if some one patents the basic underlying idea, it can then become a Patent Troll Tool against many unrelated products.

There is of course another advantage to having this intermediate firewall/server, you can include it in a very wide area VPN or encrypted mixnet etc, which makes the job of the likes of the NSA et al harder still…

As far as I can see the likes of the NSA et al will not stop their activities legal or otherwise, as long as they can get funding. Thus raising the bar and thus the cost significantly is kind of like a reverse DDoS on them, if you make each attack they want to make expensive then they will stop focusing on “collect it all” and go back to the old ways of “targeted surveillance”, because although the tax payer purse is large it is limited and politicos want to use it for many other vote gaining and feather bedding activities.

Buck • May 6, 2015 2:03 AM

@Jesse, @Nick P, @Andrew Wallace, @Beepeepeep, @Wael, @Marcos El Malo

DDOSers, teenagers, code-cutters, professionals, criminals, penetrators, hackers…

Please, feel free to define any of the above terms as a singular concept that we all agree upon! Then, maybe we can continue to debate the (de)merits of the terms or classes of people!

At least, @Wael tried!!

bob • May 6, 2015 2:07 AM

@65535:
That is the problem with a “properly forged” packet. Which brings us back to the decision to drop the packet on a 10% payload differentiation – will this 10% payload differential work?

Even if the 10% differential will work, to do the comparison you would need two or more packets with overlapping sequence numbers. So to effectively block QI you would need to delay each packet and see if there will be a duplicate or else you are potentially letting through the inserted one.

Buck • May 6, 2015 2:21 AM

@Clive

Yup! That sort of firewall/server could come in handy for a multitude of reasons — not the least of which is experience/knowledge gained in the process.

Otherwise, it seems silly to devote so much effort towards detecting or deferring these QI ‘Man-on-the-Side’ attacks… Seriously, what sort of topologies are still in use that it wouldn’t be super easy to leverage such a privileged network position for a MITM..?

Alex • May 6, 2015 5:14 AM

It would be nice to have some Linux kernel switch to use second packet instead of first.

Mike the Goat (horn equipped, redux) • May 6, 2015 6:45 AM

Nick P: exactly! The vast majority of the NSA are indeed script kiddies, most of them using public domain tools that we already know about slightly modified and given some stupid govt codename. Sure, the TAO team probably has some super secret 0day exploits that we don’t know about but I am beginning to suspect that they are neither as organized or as smart as we’ve previously given them credit for.

Clive Robinson • May 6, 2015 8:22 AM

@ Mike the Goat, Nick P, and others,

We have had this conversation about the NSA’s abilities in this area before. And as I’ve said before in many respects they are playing catch up, it’s one of the reasons I disagree with Bruce’s notion about things moving from PhDs research, it’s to overly generalised, and can be shown in oh so many cases that some of the moree interesting attacks were discussed in other places –such as this blog– long before they made it into PhD research or NSA systems.

Yes there are things that the NSA are far ahead in, but these have been their traditional research areas and the open and academic researchers are catching up rather quickly.

As for the NSA et al having “script robots” be they human (kiddies) or AI (systems) is it makes a lot of financial and resource sense when you are running in “collect it all mode”. Where as it makes way more sense in “directed attacks” to use specialised highly talented staff.

To me this has always appeared to be the sensible way to go about things, I just wonder why there is so much opposition to the idea.

I sometimes think it’s because it’s “more Macho” to fight and slay a Giant than it is to fend off a pack of rats. The reality is that unless you fight rats with the right defences they will be at the heart of things before you know it.

Philip Van Hoof • May 6, 2015 2:20 PM

@Alex: this requires the kind of state that the patch for snort also keeps, to be kept in the kernel. That sounds like a pretty bad idea (a kernel’s state should not significantly grow over time). Therefore I think it’s better for userland to detect this (the firewall software, for example snort). By the way, how do you know for sure to drop the first and not the second packet? Dropping the second would actually make quantum-insert much more easy. Plus userland could never detect malicious intent anymore (wireshark would be blind). No, the kernel must deliver as-is and as good as possible deliver a tcp/ip stack.

I think it would be interesting for other userland applications to query the firewall service, like snort, about its analysis. That way the browser could become knowledgeable about the use of duplicate sequence numbers for a given piece of data.

Many designs are possible. I wonder how or what we will end up using in a few years.

Henry • May 6, 2015 9:54 PM

“Script kiddie is a derogatory term that we should stop using in the security industry.”

Security industry invented the word. There is nothing derogatory about the term. If all bad peoples make their own tools of crime, then there will be less risk exposure for good peoples. Enlarge time to crime, then less crime will committed given resource constraint.

Using basic and complex tools to task is fundamental to enterprising and conscription. They increase free market efficiency. Unfortunately, this can also be detrimental to society.

ronnie sahlberg • May 6, 2015 9:54 PM

@bob

” you would need to delay each packet and see if there will be a duplicate ”

Actually, this happens pretty much automatically nowadays since most computers are on really lossy networks (wifi).
When you download something, the train of TCP segments you receive will often have missing packets due to unreliably networks. When this happens all other segments received behind the lost packet will be queued internally in the RX queue until the host receives the retransmission of the originally lost packet.

I.e. server sends you packets 1 2 3 4 5 6 7 8 9 but packets 1 is lost.
The remaining packets are then kept in the RX queue until the missing pacekt 1 can be retransmitted which takes anything from a few ms, if you are lucky, or >=1 second if you have to take a full retransmission timeout.

This happens a lot in networking so there are enormously many opportunities for a host to do these kind of checks between every segment it receives and those queued segments that have not yet been delivered to the application.

I would give it a really good chance to very successfully detect almost every single QI attempt just due to this, if just the network stack would “check any received segment to whatever we have already received but not yet delivered to the application”.
Would probably be quite trivial to add to at least the linux stack if it doesnt already have these simple checks.

Ethereal/Wireshark actually has a check that detects and flags overlapping segments with conflicting data.
The display filter is “tcp.segment.overlap.conflict” and should still work.

It did work at least about 10 years ago when I coded it, for completely different reasons. (I added this to check and quickly find this kind of situation due to broken TCP implementations. There were TCP implementations that did this exact thing due to bugs back in the day.)

So if you have a network trace, wireshark should be able to detect this by that filter. It works by comparing all segments against the TCP PDU reassembly buffer so you must also make sure you have TCP reassembly enabled in the preferences.

But on the other hand, If they can listen in on your outgoing packets and learn the sequence numbers and then just inject spoofed TCP segments. If they can do that they are already in the path for both forward and reverse direction for your tcp session to the server.
Why cant they just discard the real packets that the server were returning back to you, then you would never receive any duplicates and you would not be able to detect anything.

65535 • May 7, 2015 12:11 AM

@ Clive Robinson

“…build a firewall that’s actually part way to being a browser and server –as with thin clint tech– it also acts as a format converter and delay line… your client browser sends of it’s request, and it heads off to rryour gateway where it hits this firewall which then forwards the request onto the actual remote site. Under normal circumstances the reply comes back from the remote site to this firewall that builds the page internaly. Once the page is built it converts it into a different form that it then sends on to the client browser as though it had come from the remote server.

“When it gets two packets with the expected headers etc but different pay loads instead of sending it onto the client browser it sends a popup warning to the user and if the user decides to carry on it strips out all suspect javascript etc and converts all images to a different format etc. a lot of the code to do this already exists with various “thin client” and other systems it’s just a matter of somebody cobbling up a prototype, and finding out where the dificult to solve practical problems are… there will be some issues with web sites that can not function without javascript etc, the question is are people prepared to live without them”

Yes, when you combine your solution with the javascript issue [which many sites rely upon] it becomes an extremely complex issue. But, without the .js issue your solution has a lot of merit. I think the final workable solution will have to be a combination of Snort with a browser fix or IP stack fix.

@ bob
“Even if the 10% differential will work, to do the comparison you would need two or more packets with overlapping sequence numbers. So to effectively block QI you would need to delay each packet and see if there will be a duplicate or else you are potentially letting through the inserted one.”

That is valid, and that delay might not be acceptable for some users. The solution is more difficult that I thought [it took me quite awhile to read and digest each comment].

@ ronnie sahlberg

“this happens pretty much automatically nowadays since most computers are on really lossy networks (wifi). When you download something, the train of TCP segments you receive will often have missing packets due to unreliably networks. When this happens all other segments received behind the lost packet will be queued internally in the RX queue until the host receives the retransmission of the originally lost packet. server sends you packets 1 2 3 4 5 6 7 8 9 but packets 1 is lost. The remaining packets are then kept in the RX queue until the missing pacekt 1 can be retransmitted which takes anything from a few ms, if you are lucky, or >=1 second if you have to take a full retransmission timeout. This happens a lot in networking so there are enormously many opportunities for a host to do these kind of checks between every segment it receives and those queued segments that have not yet been delivered to the application. I would give it a really good chance to very successfully detect almost every single QI attempt just due to this, if just the network stack would “check any received segment to whatever we have already received but not yet delivered to the application”

That is a good point. That brings us back to a change in the network stack or some browser plug-in/fix. It is a complex problem which will probably get worse as common hackers adopt these sophisticated packet injection attacks.

HTTPS for all web communications is look better each day [as this site uses].

Clive Robinson • May 7, 2015 12:51 AM

@ 65535,

Yes, when you combine your solution with the javascript issue[which many sites rely upon] it becomes an extremely complex issue.

From a security perspective nobody and I realy do mean nobody should be allowed “to load code” onto your system.

As far as .js goes, it is a technology that’s a decade or so past it’s sell by date. Those who insist on .js are being quite indolent on using it.

Javascript and similar all belong on the scrap heap of history, not in the developers or even maintainers tool box, they are the major security vulnerability these days and should as a consequence be given the drop kick into the bad idea dump…

roy • October 3, 2016 5:05 AM

I don’t know why people keep suggesting to implement detection in browsers. Browsers aren’t able to access the raw TCP data. In order to do that, they’d have to run as root (or with CAP_NET_ADMIN) and bind directly to the interface like a packet capture utility. I suppose theoretically a browser could run a setuid/setcap privilege-separated program which binds to the network interface which the browser will be using, sending the browser events over a simple interface like a pipe, which would allow better integration between detection and browser response… But having the browser in any way need to bind to an interface and sniff raw packets seems like an overall nasty concept.

Detecting QUANTUMINSERT

Comments

Leave a comment Cancel reply