So in another thread, @Mayahana wrote While I would not put it that way, there's truth to the statement. If you don't have a gateway logging outbound traffic, independent of your client machines, how are you supposed to know a compromise has occurred? But then I thought: suppose the gateway is aggressively filtering traffic. And suppose your client machine gets compromised via a remote vulnerability. You may access the gateway's admin interface from the client machine, and your keystrokes may be logged, etc.. But as long as the gateway remains trustworthy and properly configured, it won't allow traffic from your desktop to the attacker's C&C server. And as long as the attacker cannot change the gateway's settings, it will remain trustworthy. So the theoretical attacker will be locked out. Sounds great! But the most effective way to prove an idea worthwhile is to try and punch holes in it. So let's see if we can think of methods by which our hypothetical attacker could exploit an insecure client machine, in order to bypass a hardened gateway. [Disclaimer: I am not an expert of any stripe. I don't know all the tricks. Don't assume I thought of everything.] 1. Automated attacks against the gateway from the LAN. a) Attacker drops a payload on the client which attempts to brute-force the gateway's credentials from inside. Issues: network admin may notice. Decently configured gateways will make this very difficult. May require prior knowledge of the gateway's configuration. b) Attacker drops a payload that uses a known exploit to attack a service run by the gateway. Issues: network admin may notice. Might require prior knowledge of the gateway's configuration. Vulnerable services may be run by other internal machines, instead of the gateway itself, which would make the attack useless. Reliable automation might require a large and obvious payload. Requires forethought, prior knowledge of the gateway, etc. In general, fails to qualify as "low hanging fruit" by a large margin. 2. Direct attacks against the gateway. a) Brute force against the admin interface. Issues: if the admin is savvy, this will either be unfeasible (public key authentication) or impossible (no WAN access at all). b) Exploits against the admin interface. Issues: may not be possible, as with (a)., c) Exploits against other gateway software. Issues: they need a working exploit, and possibly knowledge of the gateway configuration. Gateways tend to be hardened pretty well. Serious remote kernel exploits are not common. Things get a little thorny here. If the gateway is subject to a serious vulnerability such as Shellshock, things like log parsers might become exploitable... If the attacker has the time, money, and motivation to actually bother. 3. Working around the gateway's restrictions. 1. Establish C&C servers somewhere unlikely to be on anyone's bad-list. Issues: requires a lot of preparation and a lot of chutzpah. 2. Hijack the ISP's DNS service. Issues: can be mitigated by IP based filtering. Assumes people are actually using the ISP's DNS. May not be doable, and if it is it's guaranteed to attract a whole lot of unwanted attention. 3. Work with what you have. e.g. - Use an IM or IRC client on the insecure machine to send yourself the user's keystrokes. Likewise email clients. If the mail or IM goes to a central server, and that server is good-listed on the gateway, it might work. - Use an automated payload that hijacks Android or iOS devices, and sends you stuff over their wireless broadband connections. Issues: rather involved, requires some prior knowledge of the target network... and let's get real, nobody is actually going to do this just to circumvent one stranger's abnormally tough network security. Still, this might be tricky to defend against, short of common sense measures like "block IM if you don't use it," or at least "don't run IM clients on that dusty old WinXP machine in the basement." ... That's all I can think of, barring ye olde social engineering fallback. I can't say I've covered all the bases; but it seems to me that effective use of network gateway could put a stopper on a compromise, even if the client machine being attacked is quite insecure. That's something. My Raspberry Pi may soon find a definitive purpose...
If the Gateway has UPnP capabilities and they're enabled, a compromised device on the LAN could use it to open a port. If I recall correctly, just such an exploit was used with Flash Player a few years back. Unless you absolutely need it, UPnP should be one of the first things disabled on a gateway and if possible, on the clients as well.
Use major SNS or services like Dropbox for C&C. I know most company forbid access to them for employee except some sector like advertising/publishing, but I guess you're thinking about home environment. This will work until those specific page are found by service provider or blacklisted by security vendor. Or DNS MITMing unless victim use DNSCrypt... As MRG's BABO test malware, embed data in browser's http(s) request, BABO bypassed all corporate MPS (Malware Protection System) products tested there. I think attack situation also matters. If you have only one time chance, you have to hardcode everything as there's no guarantee it can establish C&C connection, but if you know victim's favorite site and can repeatedly attack him, story is different.
Also remember, I have APT enabled. APT is designed to handle many such internal compromise situations. ASUS routers 68u and beyond have a rudimentary form of APT. My Sophos UTM 9.3 has a pretty advanced APT system, and I have it fully enabled. It's designed to detect threats from within. https://en.wikipedia.org/wiki/Advanced_persistent_threat I will post my thoughts on the other things as I get time.
Well, APT usually means threat or attack itself so using this word for protection measure is bit confusing. Although there're many individual names for those APT shield technology, I believe MPS is relatively common one.
Or Google Drive for that matter. Such things might be more easily automated too. That sounds right nasty. Is it common enough that I should be worried about it? How would that bypass iptables though? The request is only going to go to good-listed servers. Edit: though if HTTPS is unrestricted, then yeah, that'll work. I was thinking in terms of broader attacks, not really targeted. But you raise a good point there. These days, if you have a serious custom firewall setup, anyone who actually bothers trying to break through it is being pretty targeted by definition.
I don't know actual example of DNS MITMing, but at least those who made DNSCrypt had to care about it... Ah, in that case it can't bypass it but MRG used good reputaion server for BABO. Well, most NGFW have SSL scanning capability and even w/out it still can block https site if it is blacklisted. Yup, I agree.
