DEV Community 👩‍💻👨‍💻

jmau111⭐
jmau111⭐

Posted on • Originally published at blog.julien-maury.dev

Pivoting with SSH in CTFs

In the previous post, I wrote a few paragraphs about Chisel, a pretty convenient binary you can use to build reverse tunnels during a CTF.

The tool is mostly used for network pivoting, and it works great, but there are other ways.

Pivoting in short

As we saw in the previous post, network pivoting can consist of forwarding ports between the targeted machine and the attacker's machine.

Using a rogue channel (tunnel) created with Chisel (or another tool), the attackers can access to a specific instance in the network from their machine, for example, a Mysql or a Mongodb database.

The idea is to use a first compromised machine that has access to the network to reach internal instances that are not exposed outside of the network.

SSH in short

If you're playing CTFs, you probably already know how to ssh-connect to a server. In its most basic form, the connection consists of using a login and a password to access to a server:

# "user" is the username and "server" can be either an IP or a host like website.ctf
ssh user@server
Enter fullscreen mode Exit fullscreen mode

N.B.: it's recommended to use keys instead of passwords for better security

SSH means "secure shell" and is designed as a secure alternative to old protocols such as telnet. It's safer because it encrypts communications regardless of the network infrastructure, whereas telnet transmits information in plain text.

It's not exactly bulletproof, though, as misconfiguration and human errors happen, but it's robust enough.

Local port forwarding

SSH is actually a common protocol for pivoting. It's just that some CTFs do not allow players to get secure shells easily because the scenario does not include it or the exploit focuses on another layer.

To pivot with SSH, you can use the -L option, which allows to bind remote and local, for example:

# on the attacker's machine
ssh -L {LOCAL_PORT}:127.0.0.1:{REMOTE_PORT} user@server
Enter fullscreen mode Exit fullscreen mode

Pretty straightforward! After that, you can connect locally to http://127.0.0.1:{LOCAL_PORT}.

But why do we even need such forward?

Because the {REMOTE_PORT} is not broadcast on the targeted server, so we need to create a tunnel to access to this instance from our local machine.

That's it?!

Pretty much! However, like with Chisel, there are more complicated usages and commands to use depending on the situation.

CTFs don't go too far, so you won't have to forward port dynamically using proxies and socks, but it's indeed possible with other options.

Many CTFs "invite" you to use this approach to explore internal instances and get more info such as passwords or even other users' SSH keys, allowing you to escalate privileges.

Top comments (0)

🤔 Did you know?

 
📚 You can adjust your experience level in Settings to see more relevant content.