Client Side Penetration Testing – T&T This article includes tips and techniques on how to deliver spoofed emails and how to defend against email spoofing. The next article will include techniques on how to embed an executable file in attachable files without being detected by mail filters and anti-virus. >> Emailing Most client side attacks are based on delivering emails to the target, nevertheless by underestimating the need to build an adequate trust level towards the target, theres a fair chance that the exercise will fail even at this early state. Below we will begin by listing some techniques, considerations and tips on how to successfully deliver emails and establish this trust level. >> SMTP in general SMTP servers which are flagged as the MX for each domain, by design, accept connections by any system on the internet and relay the messages to their users. The term “system” does not imply mail servers, so the “system” does not have to be a mail server necessarily. Anyone may connect to this type of SMTP server at port 25 using a client (Outlook, Thunderbird or even telnet) and send a message directly to its domain(s) users. Unless this SMTP server is an open relay (very rare nowadays) messages can be relayed only to users of the domain(s) it serves, any other attempt to send messages to other domains will be rejected. >> MX enumeration As a first step the target’s MX server that is responsible for email relaying, has to be identified. This can be done easily by querying any DNS server for the target’s MX records: $ host -t mx target target mail is handled by 20 mx2.target. target mail is handled by 10 mx1.target. >> Email Spoofing Techniques Obviously, the chances that an email will seem legitimate are increased dramatically if the sender email address is spoofed to an email address which belongs to the target’s domain. The sender address is declared in two fields. The “MAIL FROM” SMTP command that is in fact used as “Bounce To” address in order to reach the sender in case of delivery failure The message header “From: “ (e.g. From: “Spoofed” ) that defines the address that will shown as sender at target’s mail client During usual email communication using clients like Outlook, Thunderbird, etc. the user cannot control these fields directly. Both are filled by the mail client with the email address that was defined upon user account creation. >> MAIL FROM command Below we describe how to detect errors and blocking mechanisms when using the MAIL FROM command in order to spoof the target’s email. Telnet or a similar program should be used in order to quickly and correctly identify such mechanisms. After target enumeration, the actual spoofed emails can be sent by any email client properly configured to send email directly to target’s MX server. Since there are several mechanisms that will block the spoofed “MAIL FROM”, the most important part is to check if the email has reached the target. The message can be relayed from any SMTP server to reach the target’s MX. The reason we choose directly the target’s MX to communicate with, is that we will have strong indications if our message is rejected (due to blocking technologies that are mentioned below) through error messages that would not otherwise be visible (if an intermediate SMTP was used to relay the message). An example SMTP communication with target’s MX server with telnet is demonstrated below. $ telnet mx1.target 25 Connected to mx1.target. Escape character is ^]. 220 mx1.target ESMTP - Welcome HELO test 250 mx1.target says HELO to [xxx.xxx.xxx.xxx:xxxx] MAIL FROM: 250 2.1.0 Ok RCPT TO: 250 2.1.5 Ok DATA 354 continue. finished with \r\n.\r\n Date: Fri, 1 Aug 2014 11:12:29 +0300 From: Spoofed User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Target >> Target
Posted on: Sun, 10 Aug 2014 20:47:39 +0000
Trending Topics
Recently Viewed Topics
© 2015