IPFire vs. shellcode attacks: an experiment

Discussion in 'other firewalls' started by Gullible Jones, Sep 29, 2015.

  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    So we've all heard how awesome firewall distros like IPFire, pfSense, etc. are. But a lot of things are claimed to be awesome, and don't life up to it in reality. I wanted to verify those claims. Thus, yesterday I set this up:

    screen 0.png

    Two VMs running Puppy Linux ( :p ), one running IPFire, all on top of Backbox on my AMD A2 workstation. That's Armitage (a Metasploit frontend) in the background.
    - IPFire was configured with one virtual NIC on an internal net, the other on a bridge
    - Puppy Control was on a bridge
    - Puppy Test was on the internal net, seeing the world through an IPFire periscope

    So, first: establish that the control can be successfully attacked. This sounds obvious - Puppy being, by all appearances, the most insecure distro ever - but it actually isn't. From what I've seen, even supposedly applicable exploits usually fail on TahrPup. I suspect the PAE/NX enabled kernel is largely responsible, especially in combination with ASLR and Ubuntu-issue PIE binaries...

    Anyway, we know that the "fake XPI extension" social engineering attack will work, if the XPI is in fact clicked on. And indeed:

    screen 1 - pwned.png

    Now with that out of the way, let's try the test VM. We'll start with a typical iptables firewall config.

    screen 2 - ipfire config.png screen 3 - pwned again.png

    ... Yay. :(

    Alright, now let's try with the squid proxy enabled. Proxy is in transparent mode, all traffic forced through it. On to the next post...
     
  2. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    So, here's the proxy config. Note I'm not letting through TLS, because it's just not needed for this experiment.
    screen 4 - proxy config.png screen 5 - proxy block ads exes etc.png

    Unfortunately, this does not help at all.

    screen 6 - pwned again.png

    Not that I expected it to. With all ports still allowed, traffic can just bypass the proxy. But what if we block everything except proxy traffic?

    screen 7 - proxy blocked default.png

    And this time, it looks like we might have something. Huh:

    screen 8 - no workie.png

    Victory? We'll see in the next post.
     
  3. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    ... No, not victory, because we're still using weird ports and now the firewall is blocking them. What happens when we switch to ports allowed by the proxy?
    screen 8 - only proxy allowed ports.png

    The answer is, "not much different!"

    screen 8 - takes forever and fails.png screen 9 - blocked by proxy.png

    The reverse shell doesn't start. Wait, you say, is this the proxy blocking it? Or is it actually the firewall?
    screen 10 - by proxy, not firewall.png

    Nope, nothing in the firewall logs. It's the proxy.

    screen 11 - victory.png

    And our test VM is still uncompromsied. Victory!
     
  4. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    Bonus: for extra measure, let's see if ClamAV scanning on squid can block the XPI, not just the reverse shell.

    screen 12 - extra clamav.png screen 13 - clamav blocked.png

    Yup...

    screen 14 - clamav really blocked.png

    A bit iffy though, insofar as it blocks the download every time, but only displays the banner after the first time. Whoops. Also, I'm gonna guess that this is not a generic detection. Might still be worthwhile, I've seen differing opinions on that.
     
  5. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    So, conclusions.

    What happened here?

    My guess: the proxy understands protocols - HTTP and FTP. A reverse TCP shell is not part of those protocols, even when it's on the correct port, so the proxy will not pass it through... My guess, anyway.

    Can it be relied upon?

    Probably not. A reverse shell based on HTTP, or (gods forbid) HTTPS, would in the above case go right past it. But at least it limits an attacker's options a bit.

    What about ClamAV scanning?

    Maybe. Malware detection is probably more important for end users... and ClamAV malware detection is frankly rubbish in my experience. OTOH, Clam detection of PUAs, and of generally weird program characteristics, is pretty good IMO. It might be helpful, but again I don't think I'd rely on it.

    Should I set up a firewall/proxy box?

    Not my place to say, really...

    It does seem to me like a better bet than just an outbound firewall. However, I'd strongly caution against using HTTPS MITM capabilities with a proxy. That creates a single point of failure, that an attacker could use to really mess you up.