In this presentation, I discuss four different approaches to merging multiple files of different formats into one, such that it can be read as each type. I then discuss the security implications of this property inherent in many file formats, theorize about attacks which can be launched when developers assume that files can only be one format.

1. Jack of all Formats Daniel “unicornFurnace” Crowley Application Security Services, Trustwave - SpiderLabs

2. Introductions How can files be multiple formats? Why is this interesting from a security perspective? What can we do about it? (yodawg we heard you like files so we put files in your files)

3. Terms File piggybacking Placing one file into another File consumption Parsing a file and interpreting its contents

4. Scope of this talk Files which can be interpreted as multiple formats …with at most a change of file extension Covert channels Through use of piggybacking Examples are mostly Web-centric Only because it’s my specialty This concept applies to more than Web applications Srsly this applies to more than Web applications GUYS IT’S NOT JUST WEB APPS

5. Files with multiple formats How to piggyback files (Clap and cheer now to confuse the people who can’t read this)

6. File format flexibility Not always rigidly defined From the PDF specification:“This standard does not specify the following:……methods for validating the conformance of PDF files or readers…” Thank you Julia Wolf for “OMG WTF PDF” CSV comments exist but are not part of the standard Not all data in a file is parsed Metadata Unreferenced blocks of data Data outside start/end markers Reserved, unused fields

7. File format flexibility Some data can be interpreted multiple ways Method of file consumption often determined by: File extension Multiple file extensions may result in multiple parses Bytes at beginning of file First identified file header

8. 7zip file with junk data at the beginning

9. 7zip file with junk data at the beginning

10. Multiple file extensions Apache has: Languages Handlers MIME types File.en.php.png Basename– largely ignored File.en.php.png Language – US English File.en.php.png Triggers PHP handler File.en.php.png Triggers image/png MIME type

11. Metadata Information about the file itself Not always parsed by the file consumer “Comment”fields, few restrictions on data Files can be inserted into comment fields for one format ID3 tags for mp3 files will be shown in players But not usually interpreted

12. Metadata – GIF comment

13. Metadata – GIF comment

15. Unreferenced PDF object …with a 7zip file.

16. PDF / 7Z opened as a PDF

17. PDF / 7Z opened as a 7Z

19. Series of chunks

20. IHDR chunk

21. Other chunks including at least one IDAT chunk

23. 4 byte identification field

24. Data

25. 4 byte CRC of id field and data fieldChunks with unknown IDs will be ignored The CRC will likely not even be checked

26. jaCK chunk

27. Start/End markers Many formats use a magic byte sequence to denote the beginning of data Similarly, many have one to denote the end of data Data outside start/end markers is ignored Files can be placed before or after such markers Files must not contain conflicting markers

28. Start/End markers JPEG Start marker: 0xFFD8 End marker: 0xFFD9 RAR Start marker: 0x526172211A0700 PDF Start marker: %PDF End marker: %%EOF ( and can replace ) PHP Start marker: <?php End marker: ?>

29. A WinRAR is you!

30. A WinRAR is also JPEG!

31. Limitations Some formats use absolute offsets They must be placed at start of file or offsets must be adjusted Examples: JPEG, BMP, PDF Some have headers which indicate the size of each resource to follow Such files are usually easy to work with Other files can be appended without breaking things Examples: RAR

32. Limitations Some files are simply parsed from start to end Such files require some metadata, unreferenced space, or data which can be manipulated to have multiple meanings Different parsers for the same format operate differently Might implement different non-standard features May interpret format of files in different ways

33. TrueCrypt volumes No start/end markers No publicly known signature Parsed from start of file to end of file No metadata fields No unused space Data is difficult to manipulate

34. TrueCrypt volumes

35. Security Implications Reasons why file piggybacking must be considered (Read the first word in every sub-bullet on the next slide)

36. Security Implications Data infiltration/exfiltration Never check what .mp3 files pass in and out of your network? Gonna change that when you get back to the office? Anti-Virus evasion Give an AV a piggybacked file, it might apply the wrong rules You might not know that most AV applies heuristics/signatures based on identified file format! File upload pwnage Up loading well-formed images that are also backdoors is possible

37. Security Implications Multiple file consumers Different programs may interpret the file in different ways GIFAR issue Parasitic storage How many file uploads allow only valid images? Disk space exhaustion DoS Some image uploads limit uploads by picture dimensions Size of the file may not actually be checked

38. File upload pwnage Imagine a Web-based image upload utility It confirms that the uploaded file is a valid JPEG It doesn’t check the file extension It uploads the file into the Web root It doesn’t set the permissions to disallow execution Code upload is possible if the file is also a valid JPEG This isn’t hard…

39. Anti-Virus evasion exercise Check detection rates on Win32 netcat Place it in an archive and check Put junk data at the beginning of the file and check Piggyback the archive onto the end of a JPEG and check Change the file extension to .JPG and check

40. Check detection rates on netcat

41. Archive netcat and check again

42. Add junk at the beginning of the file

43. Piggyback the archive onto a JPEG

44. Change the extension to .jpg

45. LULZ netkitties

46. Data Infiltration Take the previous example of a 7z attached to a JPEG This will bypass lots of AV Maybe also IDS/IPS Haven’t tested it

48. Type of files being communicated

49. Content of traffic

50. Communication properties

51. These techniques allow for covert channels

52. With wide bandwidth

53. With some plausible deniability

54. In files which are

55. Ordinarily harmless

56. Frequently passed

58. Browsers automagically download images

59. What if those images are also malware?

61. JAR appended to the end of a GIF

62. Browser loads the GIF

63. Old versions of JVM would recognize AND RUN the JAR

64. Apache handling “file.en.php.png”

65. Passes file to PHP for preprocessing

66. Serves resulting output with

67. a US english charset

69. It allows the upload of only 1x1 images

70. For disk space reasons

71. Append 2GB of junk onto the end of a 1x1 image

72. ???

73. NO DISK SPACE!!!

76. Don’t allow the user to control any part of the filename

77. Don’t set the perms to executable

78. Don’t trust file properties

79. Allow only one extension

81. Check for all valid file headers

82. Performance hit

83. Apply all signatures/heuristics globally

84. Big freakin’ performance hit

85. Identify by behavior

87. Nuffsaid

88. Put some additional protection in place

89. Disk quota

91. Remove metadata

92. At end of file

93. Parse out relevant format data and save as new file

94. In unreferenced block or as part of real data

95. Don’t upload files?