---[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 03 of 15
-------------------------[ P H R A C K 5 3 L I N E N O I S E
[snip..]
0x7>-------------------------------------------------------------------------
Practical Sendmail Routing
Intro:
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.
How to:
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)
host4
host5
host6
host7
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:
host3!host4!host5!host6!host7!host8!dest!user@host2
I know. Very weird as far as the order and placement of each. If you don't
think it looks right, go reference it.
Goal:
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:
you --.
firewall --.
internal host1 --.
|
internal host2 --'
firewall --'
you --'
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.
you --.
firewall (external interface) --.
firewall (internal interface) --.
|
.-- internal host1 --'
|
`-- internal host2 --.
|
firewall (internal interface) --'
firewall (external interface) --'
you --'
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!
Conclusion:
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.
Hi:
mea_culpa mea_culpa@sekurity.org
* "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.