[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-disclosure] Mail Drives Security Considerations

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Matthew Flaschen wrote:
<blockquote cite="mid454F2D7E.6080000@xxxxxxxxxx" type="cite">
  <pre wrap="">Just set it to only accept signed messages starting from a 
certain date.

Matthew Flaschen

Darkz wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Matthew Flaschen wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">Why can't message signing offer backwards compatibility 
(assuming you
use multipart/signed)?

Matthew Flaschen

Darkz wrote:
  
      </pre>
      <blockquote type="cite">
        <pre wrap="">Mail Drives Security Considerations
===================================

Author: Attila Gerendi (Darkz)
Date: November 03, 2006


 There are more "mail drive" solutions available like "GMail Drive", 
"GSpace", "Gmail FS", etc.. These systems are built to store ordinary 
files in email accounts (usually gmail because it's free 2Gb++ space).

 In some of these solutions the files and folders usually are stored as 
attachments in a special email. The file system does not have FAT (File 
Allocation Table) and the informations regarding the name and path of 
the files/folders are stored in the email SUBJECT field. Additionally 
there is no mechanism to filter these emails.
 
 So the problem is the remote attacker can shout blindly emails which 
describe a file or folder in this file systems and manipulate or inject 
files into that file system. This may be used for a new spam type or to 
inject undesirable/malicious files into someone's file collection. At 
the first sight this can not be worse then plain email spamming, however 
because this concept is extending the email use if no sanitation will be 
included then it will extend the spam use as well, some malicious people 
will find out new malicious solutions for particular or generic situations.

A few examples are described below, other may exist.

1. viksoe's GMail Drive shell extension
---------------------------------------
   
    - file injection. You can inject files into the "GMail Drive file 
system" by sending email with Subject: "GMAILFS: /new_filename.txt 
[13;a;1]" and "new_filename.txt" as attachment. However if the sender is 
not "self" then the filename will be displayed with red color. The 
sender email address can be spoofed.
   
    - folder creation. You can create new folder by sending email with 
Subject: "GMAILFS: /new_folder/. [14;a;1]"
   
    - rewrite file contains. You can overwrite file displayed content 
sending email with Subject: "GMAILFS: 
/existing_path/existing_filename.txt [13;a;1]" and "filename.txt" as 
attachment. However if the sender is not "self" then the extension will 
display 2 files with the same name but both will have the same new content.
   
   
   
2. Gmail File Space(GSpace) by Rahul Jonna
------------------------------------------

    - file injection. You can inject files into the "GSpace file system" 
by sending email with Subject: "GSPACE|new_filename.txt|2174|1|1|1|gs:/ 
d$" and putting "new_filename.txt" and "metadata.txt" as attachment. 
However the interface will fill the "from" information with the sender 
email address. The sender email address can be spoofed.
   
    - folder creation. You can create new folder by sending email with 
Subject: "GSPACE|test/|-135|1|1|0|gs:/ d$" and "blank.txt" and 
"metadata.txt" as attachment. However the interface will fill the "from" 
information with the sender email address. The sender email address can 
be spoofed.
   

Solution:
---------
  there are more possible solutions to filter unwanted content, such as 
inserting unpredictable id-s in the emails, message signing, but none 
(in my opinion) which can offer backward compatibility.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: <a class="moz-txt-link-freetext" 
href="http://lists.grok.org.uk/full-disclosure-charter.html";>http://lists.grok.org.uk/full-disclosure-charter.html</a>
Hosted and sponsored by Secunia - <a class="moz-txt-link-freetext" 
href="http://secunia.com/";>http://secunia.com/</a>

    
        </pre>
      </blockquote>
      <pre wrap="">
  
      </pre>
    </blockquote>
    <pre wrap="">I am not really familiar with message signing but i guess you 
can not sign 
already received emails in your inbox. So how you manage the older 
files(emails)? If you chose to support signed and unsigned emails then you are 
vulnerable, if you not then you have to delete all files(emails) and rewrite 
them, which method is no more compatible with the old file-system. Please 
correct me if I am wrong.

Attila Gerendi
    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
Then the remote attacker will have to override the email date. After a
fast test I found out it can be done by&nbsp; changing the settings on the
SMTP server, and that is possible if you have access to server setting
or you own one. I send this email with altered SMTP server date, you
should check in the email headers to see how will arrive to you.<br>
<br>
Attila Gerendi<br>
</body>
</html>


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/