Hey everyone,
Yesterday, while perusing through an Intercept article, I ran across a reference to quantum insert attacks for the first time. My intellectual curiosity beckoned me to dig a little deeper and consider utilizing a QI detection system using "common software" like Snort or Suricata. My [one-day-long] research unveiled some peculiar findings, starting with Snort not being an option for Jessie users, but ultimately boiled down to a couple of questions before I go about installing and compiling a bunch of software.
1. I read two studies, one that suggests Suricata can detect these intrusion methods (with a stream_event), and one which explicitly states it can't. Both were published within a month of each other. I find that odd, and I might have misread one or the other.
2. Are these types of attacks something that network admins worry about anymore? I know these were published two years ago, but I couldn't find much literature aside from those same few articles about the same few IDS and solutions. The most recent just stated that Honeybadger was modified to detect QI.
3. Assuming this type of attack is still relevant for security experts, what are some prevention methods? If there are none, what do you typically do with the results aside from saying, "cool, I found one!" And, which software would be best for detecting these (Suricata, Honeybadger, Qisniff)?
Help is appreciated!
Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
IDS and Quantum Insert
-
- Posts: 459
- Joined: 2013-06-16 00:10
IDS and Quantum Insert
the crunkbong project: scripts, operating system, the list goes on...bester69 wrote:There is nothing to install in linux, from time to time i go to google searching for something fresh to install in linux, but, there is nothing
Re: IDS and Quantum Insert
I don't understand why you believe this to be the case.n_hologram wrote:...starting with Snort not being an option for Jessie users...
Nobody would ever ask questions If everyone possessed encyclopedic knowledge of the man pages.
-
- Posts: 459
- Joined: 2013-06-16 00:10
Re: IDS and Quantum Insert
https://packages.debian.org/search?keyw ... ection=allacewiza wrote:I don't understand why you believe this to be the case.n_hologram wrote:...starting with Snort not being an option for Jessie users...
the crunkbong project: scripts, operating system, the list goes on...bester69 wrote:There is nothing to install in linux, from time to time i go to google searching for something fresh to install in linux, but, there is nothing
Re: IDS and Quantum Insert
Just because it is not packaged for Jessie does not mean it is not an option, unless you are saying that is the only installation method you are willing to use. Snort seems to perform better for me when compiled from source with the appropriate flags/options for the intended system. Most snort BLOBS I've seen come bloated with alot of superfluous stuff covering more bases than any one user/system wants or needs anyway.
Nobody would ever ask questions If everyone possessed encyclopedic knowledge of the man pages.
-
- Posts: 459
- Joined: 2013-06-16 00:10
Re: IDS and Quantum Insert
Yeah, that's fair. I compiled it from source yesterday, but it output an error -- I haven't looked into it yet, but I'll check it once I get home.
The Snort thing was incidental, though. I'm more interested in the overall ways to defend a network against QI attacks.
The Snort thing was incidental, though. I'm more interested in the overall ways to defend a network against QI attacks.
the crunkbong project: scripts, operating system, the list goes on...bester69 wrote:There is nothing to install in linux, from time to time i go to google searching for something fresh to install in linux, but, there is nothing
-
- Posts: 459
- Joined: 2013-06-16 00:10
Re: IDS and Quantum Insert
Well, snort is running, which is neat. Still looking into ways to block QI attacks. Suggestions are still appreciated.
the crunkbong project: scripts, operating system, the list goes on...bester69 wrote:There is nothing to install in linux, from time to time i go to google searching for something fresh to install in linux, but, there is nothing
Re: IDS and Quantum Insert
please enlighten us about this particular type of attack.
you seem to be assuming we're all security experts.
i had a look at the article linked, but from what i see it's a 2-pronged approach:
1. get users browsing history (easily prevented through sane usage habits? i.e., no google or firefox services etc.?)
2. replace most visited website with nsa enabled version (does not happen on the user's computer, but "somewhere on DNS level"?)
...
you seem to be assuming we're all security experts.
i had a look at the article linked, but from what i see it's a 2-pronged approach:
1. get users browsing history (easily prevented through sane usage habits? i.e., no google or firefox services etc.?)
2. replace most visited website with nsa enabled version (does not happen on the user's computer, but "somewhere on DNS level"?)
...
-
- Posts: 459
- Joined: 2013-06-16 00:10
Re: IDS and Quantum Insert
As a security enthusiast, whenever I post here, I guess it's a bad habit to assume that there's someone with far more knowledge about these subjects XD Sorry. With that said, forgive me for unintentionally butchering terminology below.debiman wrote:please enlighten us about this particular type of attack.
you seem to be assuming we're all security experts.
That's the set-up, but the process sends a duplicate packet to the client. When working properly, the first one "should" be from the NSA, and is a 302 redirect. Below, here's what HoneyBadger IDS detects when one is successful. Notice the 302:i had a look at the article linked, but from what i see it's a 2-pronged approach:
1. get users browsing history (easily prevented through sane usage habits? i.e., no google or firefox services etc.?)
2. replace most visited website with nsa enabled version (does not happen on the user's computer, but "somewhere on DNS level"?)
https://pbs.twimg.com/media/CaJMCjxWAAAQCra.jpg
Now, a variety of programs detect the attacks. HoneyBadger looks for these types of attacks, but from what I understand, it isn't a comprehensive IDS. Other, reputable IDS software "should" be able to detect them as well, albeit with minor modifications. I began investigating Suricata because it "can already detect Quantuminsert attacks out of the box" (although, as I mentioned before, another website [linked in first post] questioned the validity of its ability to detect this type of attack), and Snort can be patched to detect it. And it's these same few programs with the same few methods that recur article after article. Based on my research, I don't believe detecting the attacks is really the issue.
However, I find it interesting that no one has established a work-around. I believe it's because the NSA packet appears so similar to a normal 302 redirect. From an article:
So, if successful, your client "should" ignore anything from the real website, because the process of accepting the spoofed packet closes the connection. This behavior is evident in the tshark analysis they reference:The reason why Suricata and other methods fail to detect this attack is because the injected packet contained both application layer data (an HTTP redirect) and a TCP FIN flag. Upon receiving this spoofed packet the client (victim) followed the redirect as well as closed down its current TCP socket to the web server, by responding with a FIN+ACK packet. Subsequent packets sent by the real web server were then ignored by the client since the TCP socket was already closed when they arrived.
So, the client doesn't wait long enough for the legitimate packet. By the time it arrives, the connection is closed, thanks to the FIN+ACKing.Here's what the PCAP file looks like when analyzed with Tshark:
tshark -r mots-with-fin.pcap -T fields -e ip.src -e ip.dst -e ip.ttl -e tcp.seq -e tcp.flags -e http.response.code -e http.response.phrase
10.0.1.4 91.225.248.129 64 189665416 0x0002
91.225.248.129 10.0.1.4 54 4114717473 0x0012
10.0.1.4 91.225.248.129 64 189665417 0x0010
10.0.1.4 91.225.248.129 64 189665417 0x0018
91.225.248.129 10.0.1.4 64 4114717474 0x0019 302 Found <--INJECTED
10.0.1.4 91.225.248.129 64 189665756 0x0010
91.225.248.129 10.0.1.4 54 4114717474 0x0010
10.0.1.4 91.225.248.129 64 189665756 0x0011
91.225.248.129 10.0.1.4 54 4114717474 0x0018 301 Moved Permanently
Frame number 5 is the injected “302 Found” packet spoofed by the attacker. The TCP flag value 0x19 translates to FIN+PUSH+ACK, which is the attackers attempt to tear-down the TCP connection. The client responds with a FIN+ACK (0x11) in frame 8. The final frame is the real HTTP response coming from the legitimate web server.
Based on readings like these, it's sensible that there wouldn't be a legitimate solution to blocking these types of attacks. Many resources detect them, but I can't find any that block them. I superficially understand the reasons why "block QI attacks" et al yields no meaningful search results. I imagine one best way to stop these is to block 302 packets from entering the client/network. However, since sites rely on this temporary redirection, normal browsing activity could break -- albeit not so broken as being the victim of a QI attack. One issue I'm facing is I also can't find any way to block 302s to even test the sensibility of that approach. Another reason, from what I imagine, is that you would have to wait for the legit packet, which I assume means tearing out the 0x19 part of the NSA's packet (I'm butchering the language now, right?) just to prevent the connection from closing, but as I'm treading in territoriy I don't understand at this point, I'm going to yield discussions about this second theory to an actual expert or professional. Again, these are my personal two conclusions based on what [little] I know and found.
So, I'm at a wall where I feel that I understand the theory, detection methods, but not prevention solutions. I assumed that if no one has already done so, there might be someone who knows how to, since I have the ambition to learn but currently lack the expertise to implement. Search engines gave few results, and most just yielded the same few pages. I can only assume that there are no ways to block QI attacks, but again, I'm not the professional. And, I hope I clarified my points well enough for non-professionals, of which I am a part. Any help on this topic would be appreciated.
the crunkbong project: scripts, operating system, the list goes on...bester69 wrote:There is nothing to install in linux, from time to time i go to google searching for something fresh to install in linux, but, there is nothing
Re: IDS and Quantum Insert
This is the typical pitfall when IDS transitions to I"P"S. The cost vs. benefit of blocking is simply not there unless A) you are a TCP-IP security-focused protocol expert OR B) you have a specific vulnerability associated with a known target vector "and" support from A).n_hologram wrote:Based on readings like these, it's sensible that there wouldn't be a legitimate solution to blocking these types of attacks. Many resources detect them, ...normal browsing activity could break...
I doubt you will find that here.
Nobody would ever ask questions If everyone possessed encyclopedic knowledge of the man pages.