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

Off-Topic discussions about science, technology, and non Debian specific topics.
Post Reply
Message
Author
n_hologram
Posts: 459
Joined: 2013-06-16 00:10

IDS and Quantum Insert

#1 Post by n_hologram »

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!
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
the crunkbong project: scripts, operating system, the list goes on...

User avatar
acewiza
Posts: 357
Joined: 2013-05-28 12:38
Location: Out West

Re: IDS and Quantum Insert

#2 Post by acewiza »

n_hologram wrote:...starting with Snort not being an option for Jessie users...
I don't understand why you believe this to be the case. :?
Nobody would ever ask questions If everyone possessed encyclopedic knowledge of the man pages.

n_hologram
Posts: 459
Joined: 2013-06-16 00:10

Re: IDS and Quantum Insert

#3 Post by n_hologram »

acewiza wrote:
n_hologram wrote:...starting with Snort not being an option for Jessie users...
I don't understand why you believe this to be the case. :?
https://packages.debian.org/search?keyw ... ection=all
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
the crunkbong project: scripts, operating system, the list goes on...

User avatar
acewiza
Posts: 357
Joined: 2013-05-28 12:38
Location: Out West

Re: IDS and Quantum Insert

#4 Post by acewiza »

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.

n_hologram
Posts: 459
Joined: 2013-06-16 00:10

Re: IDS and Quantum Insert

#5 Post by n_hologram »

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.
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
the crunkbong project: scripts, operating system, the list goes on...

n_hologram
Posts: 459
Joined: 2013-06-16 00:10

Re: IDS and Quantum Insert

#6 Post by n_hologram »

Well, snort is running, which is neat. Still looking into ways to block QI attacks. Suggestions are still appreciated.
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
the crunkbong project: scripts, operating system, the list goes on...

User avatar
debiman
Posts: 3063
Joined: 2013-03-12 07:18

Re: IDS and Quantum Insert

#7 Post by debiman »

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"?)

...

n_hologram
Posts: 459
Joined: 2013-06-16 00:10

Re: IDS and Quantum Insert

#8 Post by n_hologram »

debiman wrote:please enlighten us about this particular type of attack.
you seem to be assuming we're all security experts.
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.
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"?)
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:
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:
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, 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:
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.
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.

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.
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
the crunkbong project: scripts, operating system, the list goes on...

User avatar
acewiza
Posts: 357
Joined: 2013-05-28 12:38
Location: Out West

Re: IDS and Quantum Insert

#9 Post by acewiza »

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...
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).

I doubt you will find that here.
Nobody would ever ask questions If everyone possessed encyclopedic knowledge of the man pages.

Post Reply