[This was originally published in Phrack Magazine #53 and mirrored on attrition.org.]
This article will be short and sweet as the concept and methodology are quite simple.
UUCP Style routing has been around longer than most newbie hackers, yet it is a foreign concept to them. In past years, Phrack has seen at least one article on using this method to route a piece of mail around the world and back to the base host. That article in Phrack 41 (Network Miscellany) by the Racketeer gave us a good outline as how to implement routed mail. I will recap that method and show a practical use for it. If you have any questions on the method for building the mail headers, read a book on UUCP or something.
In short, you want to create a custom route for a piece of email to follow. This single piece of mail will follow your desired path and go through machines of your choice. Even with mail relaying turned off, MTAs will still
past this mail as it looks at the mail and delivers only one hope at a time. The customized headers basically tell sendmail that it should only be concerned about the next target in the path, and to deliver. In our example
below, we will have nine systems to be concerned about. Your base host, seven systems to bounce through, and the user on the final destination machine.
host1 = origin of mail. base host to send from.
host2 = second...
host3 = third... (etc)
host8 = final hop in our chain (i.e.: second to last)
user @ dest = final resting place for mail
Most people will wonder “why route mail, sendmail will deliver directly”. Consider the first step in doing a penetration of a foreign network: Recon. A would-be attacker needs as much information about a remote host as possible. Have you ever sent mail to a remote system with the intention of bouncing it? If not, try it. You will find it a quick and easy way of finding out what version of what MTA the host is running.
Knowing that the message will bounce with that information, think larger. Send mail to multiple hosts on a subnet and it will return the version information for each machine it bounces through. Think larger. Firewalls are often set up to allow mail to go in and out without a problem. So route your mail past the firewall, bounce it among several internal systems, then route the mail right back out the front door. You are left with a single piece of mail containing information on each system it bounced through. Right off, you can
start to assess if the machines are running Unix or not among other things.
So, with the example above, your mail ‘to’ will look like this:
I know. Very weird as far as the order and placement of each. If you don’t think it looks right, go reference it.
The desired outcome of this mail is to return with as much information about the remote network as possible. There are a few things to be wary of however. If the mail hits a system that doesn’t know how to handle it, you may never see it again. Routing the mail through a hundred hosts behind a firewall is risky in that it may take a while to go through, and if it encounters problems you may not get word back to know where it messed up. What I recommend is sending one piece of mail per host on the subnet. This can be scripted out fairly easy, so let this be a lesson in scripting as well.
Theoretical Route 1:
internal host1 --.
internal host2 --'
Theoretical Route 2:
If the internal network is on a different IP scheme than the external machines, (ie: address translation) then your mail will fail at the first hop by the above means. So, we can try an alternative of passing mail to both sides of the firewall in order. Of course, this would rely on knowledge of internal network numbering. If you are wondering how to get this, two ways come to mind. If you are one of those wacky ‘white hat’ ethical hackers, this information is often given during a controlled penetration. If you are a malicious ‘black hat’ evil hacker, then trashing or Social Engineering might be an option.
firewall (external interface) --.
firewall (internal interface) --.
.-- internal host1 --'
`-- internal host2 --.
firewall (internal interface) --'
firewall (external interface) --'
Taking it to the next level:
So if you find this works, what else can you do? Have a remote sendmail attack lying around? Can you run a command on a remote machine? Know what an xterm is? Firewalls often allow a wide variety of traffic to go outbound. So route a remote sendmail based attack to the internal host of your choice, spawn an xterm to your terminal and voila. You just bypassed a firewall!
Yup. That is it. Short and sweet. No need to put excess words in this article as you are probably late on your hourly check of rootshell.com looking for the latest scripts. Expand your minds.
- “taking it to the next level” is a bastardized trademark of MC.
- ‘wacky white hat ethical hacker’ is probably a trademark of IBM.
- ‘malicious black hat evil hacker’ is a trademark of the ICSA.