Am I being attacked?
-
@johnpoz In this scenario if the attacker did manage to get his HTTP response through to the target's browser, it would contain any html/javascript that the attacker wanted, so theoretically he could create a webpage that looks identical to say a login page for a website, except the form's action would point to a webserver somewhere else that he controlled (e.g., action="http://1.2.3.4/script.php" method="get"..) which would take the credentials the user input into the form thereby giving the credentials to the attacker -- so no response back is required. This attack wouldn't work with SSL encryption though but I was thinking for HTTP request this seems like it could be plausible.
Good point with the local port -- it does seem like a longshot but I did read some reports of people testing their maximum packets sent per second and people are reporting between 20,000pps - 40,000pps so if these are getting through to the target then the chances seem decent. However not sure if there are additional checks at the Application layer in the browser..
So let's say that the attacker hits the correct local port in the TCP portion of the packet with correct source/destination IP at the right moment, how would the firewall know the difference from these pieces of information between the true response and the malicious response? Are there any other identifiers that you know of that the firewall is looking at? Is this problem too complex to figure out without a team of specialized nerds? =)
-
Well I think your a bit out into fantasy land if you seriously think you would fall victim to such an attack. But pf should be checking sequence number and timestamps as well with antispoof.
https://man.openbsd.org/pf.conf
comparing a packet to a state involves checking its sequence numbers, as well as TCP timestamps if a rule using the reassemble tcp parameter applies to the connection. If these values are outside the narrow windows of expected values, the packet is dropped. This prevents spoofing attacks, such as when an attacker sends packets with a fake source address/port but does not know the connection's sequence numbers.I have not looked into such things in a really long time ;) I do not believe these settings are exposed in the gui to manipulate..
-
A direct attack against a browser on a host behind the firewall like that is extremely unlikely IMO.
There are many far easier vectors a determined attacker might employ. Almost all of which involve the host connecting out to some malicious resource which the firewall will allow by default. You just need to trick the host into doing it.
You can filter outbound connections to lists of known malware sites and that can help against a wide spread generic attack. Targeted, spear-phishing type attacks are far less likely to be on a list like that though.
Steve
-
@stephenw10 said in Am I being attacked?:
extremely unlikely
Most likely an understatement IMO... More likely to get hit by lightening as you were cashing your winning mega millions lottery ticket ;) On a clear sunny day..
-
Yup, an attack is extremely unlikely because the chances of it even getting to the target host are basically zero. So why bother.
Steve
-
@johnpoz I mean, this is how phishing emails work! =) Sorta like when an attacker has a foothold or access to an internal network and performs relay attacks against smb and other protocols to serve fake logins (e.g. Responder). I was just curious though if it was a known thing for attackers to craft packets for this purpose. I'll take your word for it though that this type of spoofing shouldn't be something to be concerned about from a security perspective!
-
@spookymonkey a state bypass attack by spoofing the IP and source port along with sequence numbers and timestamps is not how "phishing" emails work ;) heheh
You clicking a link in some email that you think is your bank asking you to "verify" info has nothing to do with spoofing an IP..
-
@stephenw10 That makes sense, much easier to get a user to execute a payload than playing the packet lottery as @johnpoz likes to call it =)
-
@johnpoz Lol, true.
-
@spookymonkey if your interested in ways to bypass a firewall.. Here is a method..
Keep in mind the server on the victim network was already exploited, and the firewall allowed legit traffic to it... The bad software on the server behind the firewall was just leveraging the open path to pass traffic back and forth to the bad guy via the already open gate.. Looking like legit traffic.
Something like this a ips might be able to catch such bad traffic - but quite often this traffic is inside a https tunnel, that IPS would not be able to see..
-
@johnpoz said in Am I being attacked?:
@spookymonkey if your interested in ways to bypass a firewall.. Here is a method..
Keep in mind the server on the victim network was already exploited, and the firewall allowed legit traffic to it... The bad software on the server behind the firewall was just leveraging the open path to pass traffic back and forth to the bad guy via the already open gate.. Looking like legit traffic.
Something like this a ips might be able to catch such bad traffic - but quite often this traffic is inside a https tunnel, that IPS would not be able to see..
The moral of this story (from the article) is don't open stuff like SSH on the WAN side of your firewall. The entire scenario outlined in the article @johnpoz linked started with a dictionary attack on the password of an SSH account that was allowed through the firewall over to the web server. Once the attacker was on the web server, it's pretty much game over at that point.
While it may be technically correct to say the traffic "bypassed the firewall", that is not really a fair way to describe the scenario in my view. The firewall was configured to allow HTTP(S) traffic, the "malware C2 traffic" was disguised as HTTP(S); ergo, the firewall allowed it. So "bypass the firewall" is not necessarily how I would characterize it.
This could have been prevented, or at least made much more difficult, by using certificate-based public key authorization with the SSH account on the web server; or even better, putting that remote access behind a VPN.
So while it makes for a nice sensational headline to say "bypass the firewall", the actual truth is a bit more mundane and common. Somebody allowed password-authenticated remote access through the firewall to trusted servers behind it. That was the original compromise path. After the attacker is inside your local network, you've lost the war.
-
@bmeeks said in Am I being attacked?:
The moral of this story (from the article) is don't open stuff like SSH on the WAN side of your firewall.
It should be don't use ssh with a password. Use passwordless ssh instead. Ssh supports that. You create a public/private key pair, to allow access.
