Snort – Openssl-Heartbleed bug (CVE-2014-0160)
-
If the attacker is blocked only AFTER that the first attack has been succesfully, the IPS is useless.
As others have said already, this is NOT inline… What you want will never get achieved on pfSense. Plus - once again - if you security is so weak that it takes one packet to break it, you seriously have whole slew of things to fix first which are order of magnitutes more critital than messing with stuff like Snort.
-
Suricata is on the way….should be inline blocking coming up when Bill is done messing with it!
-
If the attacker is blocked only AFTER that the first attack has been succesfully, the IPS is useless.
As others have said already, this is NOT inline… What you want will never get achieved on pfSense. Plus - once again - if you security is so weak that it takes one packet to break it, you seriously have whole slew of things to fix first which are order of magnitutes more critital than messing with stuff like Snort.
Here the issue is the extreme danger of the heartbleed…if you are logged in pfsense, and you're exposed to the bug, i can stole your session cookie, create a one new in my browser and...woilà, logged in your box without prompting any user or password. So i say yes, only one packet is necessary to break it ;).
Snort on pfSense doesn't work inline with the traffic passing the interface. Snort gets a copy of the traffic through a capture library and then analyzes that traffic. If you want a true inline IPS, you would have to look at something else than Snort running on pfSense.
Thanks fragged, that's what i wanted to know.
Know if Snort on a linux box will be able to achieve the goal?I have never seen a LAN ip seen as source on a WAN interface before….if the probe is set to WAN. LAN ip are only seen here as destination...
Supermule,
consider that the WAN interface ip is 192.168.1.2. In some months of use, i saw various alerts, in both directions. I've never given too much weight, i was thinking that is normal operation. If isn't, i will be happy to share my conf and troubleshoot this. -
So i say yes, only one packet is necessary to break it ;).
And I would never ever rely on something soo damn complex (and logically buggy as that comes hand in hand) as snort to be a magic thing to prevent this. If you think someone got root on your system, flatten and rebuild, the only solution.
-
So i say yes, only one packet is necessary to break it ;).
And I would never ever rely on something soo damn complex (and logically buggy as that comes hand in hand) as snort to be a magic thing to prevent this. If you think someone got root on your system, flatten and rebuild, the only solution.
Completely agree, i will do a clean install :).
Unfortunately (or maybe fortunately) i saw with my eyes my colleague doing me the joke; he's an expert security engeneer but not a genius, so i think many people would be able to do the dirty hack. -
That means he need access to your pc…. and how would you do that with 1 packet since it takes quite a lot to hack the password associated with the machine running the browser that connects to the pfsense....
The funny shit is, that it is located somewhere maintained over 3 step encrypted remote controlled desktop....thats NOT connected to the internet from inside the LAN..... ;)
-
Only after that the first attack has been detected, snort puts the source ip in the block list.But is too late, the attack is successful!
Did you initiate the attack? and were you successful with gaining any credentials/access?
Did you use any packet capture system after pfSense to see what was in the packets that made it thru snort?
-
@BBcan17:
Only after that the first attack has been detected, snort puts the source ip in the block list.But is too late, the attack is successful!
Did you initiate the attack? and were you successful with gaining any credentials/access?
Did you use any packet capture system after pfSense to see what was in the packets that made it thru snort?
BBcan17 is on the right track here with his questions. I don't know of any recent exploit that actually does something useful for the hacker with just a single packet getting through. Most need a number of packets to pass back and forth to do real harm. Granted there were a few problems with ICMP and some illegally constructed packets that could crash some network stacks in the past with a single packet, but those have mostly been patched these days.
Very few packets should make it through Snort. It needs just enough of the "stream" to make the pattern match, then it will insert the blocking rule in the firewall (and kill all open state table entries, if you have that option enabled). After the block, nothing else can come though. "Just enough of the stream" might be one packet or several, depending the particular exploit Snort is detecting.
Bill
-
I will update the post soon with the step by step procedure to reproduce the test we've done.
Meanwhile just to give you an idea in this link –> https://www.mattslifebytes.com/?p=533
is described a technique very similar to the one used by us.Edoardo
-
Hi,
following the steps to reproduce and bypass Snort:
- downloaded this script to test the vulnerability (and dump the memory) of the buggy pfsense –> https://gist.githubusercontent.com/sh1n0b1/10100394/raw/4f24ff250124a03ad2d3d6010b6402c3a483d2f3/ssltest.py
- the attacker runs the script (meanwhile the administrator of the pfsense is logged in from his browser); in the dump file is stored the session ID of the admin's session.
3)at this point, after the dump has occurred, Snort has recognised the attack and blocks the source ip. - used a cookie editor (for example cookies manager+ from firefox addons) and create a custom cookie with the session ID extracted before.
5)now if we change the source ip (cell. tethering or using tor if can't change external ip) using the new cookies you will be able to Hijacking the session.
However, for open source projects like this i think we should always see the cup half full( italian proverb :D), it's already so much what Snort does for the cost of 0.
Edoardo
