Stoopid *
Mirrors are a wonderful invention.
Without mirrors, where would those of us who are self-absorbed sit, gazing fondly? Without mirrors, no one would be able to tie a necktie, neatly part their hair, or pop a zit.
Mirrors help us safely answer the age-old question that has been the bane of husbands since the dawn of time: “Do these jeans make my butt look big?” (Answer: “Well dear, I certainly don’t think so, but perhaps you should look in the mirror and see for yourself…”)
Apparently, during the early 90’s all of the mirrors in the world were temporarily broken.
I’ve been having a lot of fun playing around with a mirror of my own. This mirror doesn’t reflect light, however… it reflects TCP connections. I’ve already described the fun of watching it reflecting telnet sessions (see Mirror, mirror on the net… just how stoopid can they get?) so I decided to broaden the “mirroring scope” a bit to encompass some other protocols.
Earlier today, I started reflecting login attempts against Asterisk. (From the Asterisk.org website: Asterisk is an open source framework for building communications applications. Asterisk turns an ordinary computer into a communications server. Asterisk powers IP PBX systems, VoIP gateways, conference servers and other custom solutions. It is used by small businesses, large businesses, call centers, carriers and government agencies, worldwide. Asterisk is free and open source.)
Here’s how a typical mirrored attack goes. (Note: the IP addressses and source ports have been changed both to protect the semi-innocent and to make it easier to follow along. In this instance, 192.168.1.1 is my honeypot - running the TCP mirror - and 10.0.0.1 is the attacker).
1 IP 10.0.0.1.11111 > 192.168.1.1.5038: Flags [S], seq 1883842728, win 29200, length 0
2 IP 192.168.1.1.5038 > 10.0.0.1.11111: Flags [S.], seq 1877060720, ack 1883842729, win 28960, length 0
3 IP 10.0.0.1.11111 > 192.168.1.1.5038: Flags [.], ack 1, win 229, length 0
4 IP 192.168.1.1.22222 > 10.0.0.1.5038: Flags [S], seq 3930485646, win 29200, length 0
5 IP 10.0.0.1.5038 > 192.168.1.1.22222: Flags [S.], seq 150190901, ack 3930485647, win 28960, length 0
6 IP 192.168.1.1.22222 > 10.0.0.1.5038: Flags [.], ack 1, win 229, length 0
7 IP 10.0.0.1.5038 > 192.168.1.1.22222: Flags [P.], seq 1:28, ack 1, win 227, length 27
Asterisk Call Manager/1.1\r\n
8 IP 192.168.1.1.22222 > 10.0.0.1.5038: Flags [.], ack 28, win 229, length 0
9 IP 192.168.1.1.5038 > 10.0.0.1.11111: Flags [P.], seq 1:28, ack 1, win 227, length 27
Asterisk Call Manager/1.1\r\n
10 IP 10.0.0.1.11111 > 192.168.1.1.5038: Flags [.], ack 28, win 229, length 0
11 IP 10.0.0.1.11111 > 192.168.1.1.5038: Flags [P.], seq 1:66, ack 28, win 229, length 65
Action: Login\r\n
Username: pratik\r\n
Secret: secret5\r\n
Events: off\r\n\r\n
12 IP 192.168.1.1.5038 > 10.0.0.1.11111: Flags [.], ack 66, win 227, length 0
13 IP 192.168.1.1.22222 > 10.0.0.1.5038: Flags [P.], seq 1:66, ack 28, win 229, length 65
Action: Login\r\n
Username: pratik\r\n
Secret: secret5\r\n
Events: off\r\n\r\n
14 IP 10.0.0.1.5038 > 192.168.1.1.22222: Flags [.], ack 66, win 227, length 0
15 IP 10.0.0.1.5038 > 192.168.1.1.22222: Flags [P.], seq 28:45, ack 66, win 227, length 17
Response: Error\r\n
16 IP 192.168.1.1.22222 > 10.0.0.1.5038: Flags [.], ack 45, win 229, length 0
17 IP 10.0.0.1.5038 > 192.168.1.1.22222: Flags [FP.], seq 45:79, ack 66, win 227, length 34
Message: Authentication failed\r\n\r\n
18 IP 192.168.1.1.5038 > 10.0.0.1.11111: Flags [P.], seq 28:79, ack 66, win 227, length 51
Response: Error\r\n
Message: Authentication failed\r\n\r\n
19 IP 192.168.1.1.22222 > 10.0.0.1.5038: Flags [F.], seq 66, ack 80, win 229, length 0
20 IP 192.168.1.1.5038 > 10.0.0.1.11111: Flags [F.], seq 79, ack 66, win 227, length 0
21 IP 10.0.0.1.11111 > 192.168.1.1.5038: Flags [F.], seq 66, ack 80, win 229, length 0
22 IP 192.168.1.1.5038 > 10.0.0.1.11111: Flags [.], ack 67, win 227, length 0
23 IP 10.0.0.1.5038 > 192.168.1.1.22222: Flags [.], ack 67, win 227, length 0
- In packets 1, 2, and 3, we see a typical inbound TCP three-way handshake (syn, syn-ack, ack) sourcing from the attacking computer (I’ve changed the port number of the attacker to 11111 to make it easier to follow).
- Once the three-way handshake completes, we know for certain that this inbound connection isn’t spoofed, so now, in packet 4, 5, and 6 the honeypot fires off it’s own connection (from port 22222 to make it easier to follow) right back to the same port on the attacking system.
- Once the three-way handshake for that connection completes, the service running on the attacker’s system sends us back (packet 7) a greeting, (“Asterisk Call Manager/1.1”), which we ACK (packet 8) and then turn around and send back to the attacker (packet 9).
- He ACKs our greeting (packed 10) and, satisified that he’s talking to an Asterisk server, fires off a brute-force login attempt (packet 11).
- We ACK that data (packet 12) and then fire that same login attempt back to the Asterisk server running on the attacker’s system (packet 13).
- The Asterisk server running on the attacker’s system ACKs our data (packet 14) and then responds with an authentication error (packets 15 and 17)
- We then turn that around and send it back to the attacking process (packet 18).
- Both connections are gracefully closed (packets 19-23)
Done and done…
I’m keeping my eye on this attack, just waiting for the point in time where he hits the right username/secret combo to compromise himself…
Meanwhile, as I sit here waiting, I think I’ll put my time to good use by gazing fondly upon this devestatingly handsome fellow I see before me in the… mirror.
-TL
Tom Liston
Owner, Principal Consultant
Bad Wolf Security, LLC
Mastodon: @tliston@infosec.exchange
Twitter: @tliston
May 24, 2016