Messing with binary formats
5 likes16,409 views
The document is a presentation by Ange Albertini exploring various binary file formats and their vulnerabilities, particularly in relation to malware. It discusses how malware exploits file structure and format signatures, including practical examples of PDF and executable formats. Albertini emphasizes the importance of proper file format identification and the risks of 'type confusion' in security tools.
![%PDF*****
1 0 obj
<<
/Size 2
/W[[]1/]
/Root 1 0 R
/Pages<<
/Kids[<<
/Contents<<>>
stream
BT{99
Tf{Td(Inlined PDF)'
endstream
>>]
>>
>>
stream
*
endstream
startxref%*******](https://image.slidesharecdn.com/44con2013-messingwithbinaryformat-130916110834-phpapp01/85/Messing-with-binary-formats-46-320.jpg)
![like washing powders
security tools are selected:
● speed
● {files} → {[clean/detected]}
file types not taken into consideration](https://image.slidesharecdn.com/44con2013-messingwithbinaryformat-130916110834-phpapp01/85/Messing-with-binary-formats-56-320.jpg)
Messing with binary formats
- 1. Messing with binary formats London, EnglandAnge Albertini 2013/09/13 ΠΟΛΎΓΛΩΣΣΟΣ
- 2. Welcome! ● this is the non-live version of my slides ○ more text ○ standard PDF file ;) About me: ● Reverse engineer ● my website: http://corkami.com ○ reverse engineering & visual documentations to extract the live deck. 61 slides: pdftk 44con-albertini.pdf cat 1 3 5 7 9 10 12 14 16 18 23 25 29 31 33 35 37 39 41 43 45 47 49 51 53 55-57 59 63 65 67 69 71 73 75 77 79 81 83 85 87 89 90 94 96 98 101-102 104 106-107 109-112 114-117 119 output 44con-albertini(live).pdf 119 2 4 6 8 11 13 15 17 19+4 24 26+3 32 34 36 38 40 42 44 46 48 50 52 54 58 60+3 64 66 68 70 72 74 76 78 80 82 84 86 88 91+3 95 97 99+2 103 105 108 113 118
- 3. low-level ones, that is I just like to play with lego blocks
- 4. generate files byte per byte Goals ● explore the format ● make sure that's how things work ● full control over the structure
- 5. result: ● a complete executable ● all bytes defined by hand
- 6. our problem ● is related to virus (malwares) ● they use many file formats ● it's critical to identify them reliably ○ and to tell whether corrupted or well-formed
- 7. standard infection chain the most common chain: 1. a web page, in HTML format a. launching an applet 2. an evil applet, in CLASS format a. exploiting a Java vulnerability b. dropping an executable 3. a malicious executable, in Portable Executable format (a vast majority of malwares rely on an executable)
- 8. another classic chain ● open a PDF document ○ with an exploit inside ■ dropping or downloading a PE executable ● get a malicious executable on your machine
- 9. the challenge it might look obvious: ● tell whether it's a PDF, a PE, a JAVA, an HTML... ● typical formats are clearly defined ○ Magic signature enforced at offset 0
- 10. reality some formats have no header at all ● Command File (DOS 16 bits) ● Master Boot record some formats don't need to start at offset 0 ● Archives (Zips, Rars...) ● HTML ○ but text-only? some formats accept a large controllable block early in their header ● Portable Executable ● PICT image
- 11. How did this start? a real-life problem: 1. a (malicious) HTML page 2. started with 'MZ' (the signature of PE) 3. just scanned as a PE! a. wow, this PE is highly corrupted :) b. it must be clean :p ? MZ
- 12. polyglots in the wild GIFAR = GIF + JAR ● an uploaded image ○ an avatar in a forum ● with a malicious JAVA appended as JAR hosted on the server! ● bypass same domain policy ● now useable via its JAVA=EVIL payload + =
- 13. let's get started PE, the executable format of windows ● it's central to windows malware ● it enforces a magic signature at offset 0 ○ game over for other formats?
- 14. ● starts with a compulsory header ● made of sub-headers overview
- 15. a historical sandwich 1. a deprecated but required header 2. a modern header
- 16. old header content ● almost completely ignored ● only required: ○ 2 byte signature ○ pointer to new header
- 17. the new header can be anywhere ex: at the end of the file! such as Corkami Standard Test
- 18. let's look at HTML format
- 19. it enforces NOTHING! anything before the <html> tag! even 28 Mb of binary!
- 20. and it's been the same since Mozilla 1.0 in 2002thanks to Nicolas Grégoire!
- 21. now, the PDF format
- 22. signature position? ● officially at offset 0 ● officially tolerated until offset 1024 ● wtf? ○ it get actually worse later
- 23. PDF trick 1 put a small executable within 1024 bytes (just concatenate)
- 24. trick 2 1. start a fake PDF + object in a PE header 2. finish fake object at the end the PE 3. end fake object 4. put PDF real structure works with real-life example! (PE data might contain PDF keywords)
- 25. JAR = ZIP + Class just enforced at the very end of the file
- 26. but CRCs are just ignored it was too easy :p
- 27. Summary
- 28. Structure 1. start ○ PE Signature ■ %PDF + fake obj start ■ HTML comment start 2. next ○ PE (next) ○ HTML ○ PDF (next) 3. bottom ○ ZIP
- 29. it’s time for a real example! an inception demo! wait, what?
- 30. we’re already in the demo! the live version file is simultaneously: ● the PDF slides themselves ● a PDF viewer executable ○ ie, the file is loading itself ● the PoCs in a ZIP ● an HTML readme ○ with JavaScript mario
- 31. so, it works but it lacks something ● not artistic enough ● not advanced enough let's build a 'well representative' (=nasty) PoC
- 32. the PE specs ● Official MS specs = big joke ○ 'the gentle guide for beginners' ○ barely describes standard PEs
- 33. stripped down PE many elements removed ● including no sections
- 34. imports (imports = communication between executables and libraries) imports are made of 3 lists
- 35. evil imports ● let's make these lists into each other ● with more extra tricks to fail parser!
- 36. ultimate import fail ● failing all tools ○ including IDA & Hiew ● now fixed :)
- 37. let's put some code ● some undocumented opcodes! ● big blank spaces in Intel official docs
- 38. let's check AMD's ● miracle!
- 39. result in WinDbg ● '???' == clueless (tool/user) don't rely (only) on official docs
- 40. messing with PDF
- 41. there is a so-called standard and the reality of existing parsers looking at: Adobe, MuPDF, Chrome ● 3 different files ○ working each on a specific viewer ○ failing on the other 2
- 43. let's look inside ● MuPDF ○ no %PDF sig required ■ a PDF without a PDF sig ? WTF ?!?! ○ no trailer keyword required either ● Chrome ○ integer overflows: -4294967275 = 21 ○ trailer in a comment ■ it can actually be almost ANYWHERE ■ even inside another object ● Adobe ○ looks almost sane compare to the other 2
- 45. Chrome insanity++ (thx to Jonas Magazinius) ● a single object ● no 'trailer' ● inline stream ● brackets are not even closed ● * are required - it just checks for minimum space
- 46. %PDF***** 1 0 obj << /Size 2 /W[[]1/] /Root 1 0 R /Pages<< /Kids[<< /Contents<<>> stream BT{99 Tf{Td(Inlined PDF)' endstream >>] >> >> stream * endstream startxref%*******
- 47. PDF.JS ● very strict ○ 'too' strict / naive ? ○ I don't want to be their QA ;) ● requires a lot of information usually ignored ○ xref ○ /Length %PDF-1.1 1 0 obj << % /Type /Catalog ... >> endobj 2 0 obj << /Type /Pages ... >> endobj 3 0 obj << /Type /Page /Resources << /Font << /F1 << /Type /Font /Subtype /Type1 ... >> >> >> >> endobj 4 0 obj << /Length 47>> stream ... xref 0 1 0000000000 65535 f 0000000010 00000 n ...
- 48. let's play further combine 3 documents in a single file ● it's actually 3 set of 'independant' objects ● objects are parsed ○ but not used
- 49. alternate reality demo the live slide-deck contains 2 PDF ● bogus one under Chrome ● real one under MuPDF (Sumatra, Linux...) ● rejected under Acrobat ○ because of the PE signature (see later) DEMO
- 50. final PoC ● combine most previously mentioned tricks ● many fails on many tools ● total control of the structure ○ the PDF 'ends' in the Java class
- 51. Adobe rejects 'weird magics' after 10.1.5 not in their own specs :p 10.1.4 10.1.5
- 52. also in ELF/Linux flavor ● starring a signature-less PDF ○ which won't run on other viewers
- 54. and Apple too PS: I don't have a Mac, this was built blindly Thanks to Nicolas Seriot for testing
- 55. why should we care?
- 56. like washing powders security tools are selected: ● speed ● {files} → {[clean/detected]} file types not taken into consideration
- 57. type confusion make the tool believe it's another type, which will fool the engine engine with checksum caching will be fooled: 1. scanned as HTML, clean 2. reused as PE but malicious
- 59. engine exhaustion rankings in magazines are based on scanning time → scanning per file must stop arbitrarily → waste scanning cycle by adding extra formats
- 60. Weaknesses ● evasion ○ filters → exfiltration ○ same origin policy ○ detection ■ ex: clean PE but malicious PDF/HTML/... ■ exhaust checks ■ pretend to be corrupt ● DoS
- 61. Conclusion
- 62. Conclusion ● type confusion is bad ○ succinct docs too ○ lazy softwares as well ● go beyond the specs ○ Adobe: good ● suggestions ○ more extensions checks ○ isolate downloaded files ○ enforce magic signature at offset 0
- 63. Questions ? thank YOU !
- 65. Bonus
- 66. Valid image as JavaScript Highlighted by Saumil Shah ● abusing header and parsers laxisms ● turn a field into /* ● close comment after the picture data