Shulou(Shulou.com)05/31 Report--

This article mainly shows you "how to intercept SSM proxy traffic". The content is simple, easy to understand and clearly organized. I hope it can help you solve your doubts. Let Xiaobian lead you to study and learn this article "how to intercept SSM proxy traffic".

For reference only.

Intercepting EC2 messages

If you've ever intercepted SSM proxy traffic, you'll notice that it keeps calling ec2messages:GetMessages. By default, the agent does this continuously, keeping the connection open for approximately 20 seconds. During this 20-second interval, the agent will continue to listen for messages. If a message is received, say a component calls ssm:SendCommand, it will receive the message over the open connection.

We can also call ec2messages:GetMessages ourselves, which will allow us to intercept incoming EC2 messages to the instance. However, there is a small problem. SSM agents will establish this connection approximately every 20 seconds. What if there are two competing connections? AWS only responds to newly established connections. Therefore, if SSM agent runs first, we can create a new connection on it and intercept the message.

We can ensure that we have the most current connections by repeatedly opening new connections, and in this way we can ensure that our connections are always up-to-date and achieve interception of EC2 messages. To test my idea, I created a simple PoC that listens to send-command messages and steals the command content.

Another benefit of this approach is that we can reply to any response we want. For example, we can provide a "Success" and return an interesting message. An example PoC is given below:

Intercept SSM sessions

EC2 messages are relatively simple to implement, and you can check if you have received a message and take action or respond to it as appropriate. Unfortunately, SSM sessions are relatively complex, involving multiple Web socket connections, a unique binary protocol, and so on.

Shortly after SSM proxy starts, it creates a WebSocket connection back to AWS. This connection will be used as a control channel, mainly responsible for listening for connection requests. When a user attempts to initiate an SSM session (ssm:StartSession), the control channel receives the request and generates a data channel. This data channel is primarily responsible for transmitting the actual communication messages between users and EC2 instances.

A dedicated binary protocol handles the transmission of messages at both ends. Fortunately, we can get the SSM agent's source code, so all we have to do is check its source code and define the specification.

From an attacker's perspective, intercepting SSM sessions is more reliable than intercepting EC2 messages. This is because control channels have a longer lifetime, and just like EC2 messages, AWS only communicates with the latest channels. This way, we can create our own control channel and listen for incoming conversations. By using the SSM proxy source code, we were able to craft messages in binary format (if you look at the PoC code I gave you, you will see that I just translated Go To Python) and interact with the conversation.

So now, what we can do is as follows:

Or we could do something else, like steal commands and provide our own output, or try to intercept and read user credentials sent to the device, etc.

The above is "How to intercept SSM proxy traffic" all the content of this article, thank you for reading! I believe that everyone has a certain understanding, hope to share the content to help everyone, if you still want to learn more knowledge, welcome to pay attention to the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.