The other day I worked on a little project of mine and accidentally discovered, that Windows is able to produce different hash values for the same input.
wat?!
The problem here is, that the 64bit and 32bit Powershell both create different hash values for the same input, while using build in functionalities like Get-Filehash or binaries like certutil. The behavior is not restricted to Powershell, but expands to CMD aswell.
Windows creating different hash values for cmd.exe
I thought that if somebody actually makes the effort to produce a hash value of something it is usually for something important and not just for fun. Which would mean that it could be important that the hashing algorithm actually works like intended. But when I reported the problem to the the Microsoft Security Center I got the following answer:
What you’re reporting appears to be a bug/product suggestion, but would not meet the bar for security servicing.
So i guess its “not that important”.
Anyway I thought it was nice to know and wanted to share this little story.
UPDATE – 11th May 2020:
To be honest, I was a little dissatisfied with Microsoft’s response. For this reason, I decided to ask people who are absolute experts in the field of IT security in the hope that they could explain to me how the behavior comes about. And I could hardly believe my eyes when Tavis Ormandy took the time to answer my question (which I am very happy and grateful for).
Mail from Tavis Ormandy giving a possible explanation to the problem. (LINK inside mail)
After receiving the email I tried to verify the explanation on one of my machines. I guess my assumption that this was a bug was wrong and that it was more of a feature. A required feature, which, like Tavis himself wrote, delivers a surprising result in this case. Thanks Tavis for the explanation.
Screenshot showing that Windows never hashed the same files, but the 32-bit variant of cmd.exe within an 32 bit process.
When it comes to phishing documents its 99% of the time Microsoft office documents, since it is so versatile with what you can do. Because of that people often neglect security measures for PDF documents. To be fair, since PDF documents wont allow an attacker to implement handy VBS script which opens a shell in an instant, it is a bit harder to use PDF for phishing purposes. However, one way to do so is by injecting java script into the PDF document.
1) Create a Microsoft word document and tailor its content just as you like. Afterwards export the document as PDF. Alternatively you can just pick any other already existing PDF document.
1. Create a word document and export it as PDF.
Open up the PDF document with a text editor of your choice. The PDF document usually consists of the following four parts.
Header: This is the first line of a PDF document and specifies the version number. To inject java script we do not need to edit anything here.
Body: This is where all the objects of the document are stored. The first line of the body is usually right next to the header and starts with “1 0 obj” to create the first object inside the PDF. Objects contain all the information within the PDF document aswell as the java script that we are going to add. The last line of the body contains “endobj” while the line after that usually starts the cross reference table (xref).
2. End of Body (red) with object numbers 24 and 25. Start of xref (green).
Cross reference table (xref): The table starts with the line that contains “xref” and it contains the references to all the objects in the document. Since we are going to add objects inside the body of the document to inject java script we need to edit the object number of the reference table later on. In figure 2 we can see that the document contains 25 objects inside the body at the moment, therefore the cross-reference table gets numbered as 26.
Trailer: This specifies how the application reading the PDF document is able to find the cross-reference table and other objects. The trailer also contains the total amount of all objects, which is why we need to edit the trailer aswell after adding java script. Usually the trailer starts right behind the cross-reference table with the line “trailer” as shown in figure 3.
3. Shift between xref (green) and trailer (blue).
2) Now its time to inject java script into the document. Therefor we add three objects at the end of the PDF body, right before the cross-reference table. Keep in mind that the new objects have to be consecutively numbered. We also have to edit the object number inside the reference table accordingly as shown in figure 3.
4. Body (red). New objects inside body (orange). Reference table (green). Edited amount of objects (purple).
The first and the second object are for initialization of the java script and each of them references the next object. The third object contains the actual java script.
3) Since two out of the three new objects are already referencing each other we need to create only one new reference for the first object that we have added so that the object that contains the java script gets executed. To do this we need to edit the root (first) object which is usually at the beginning of the document. The root object begins with “1 0 obj” and contains various information about the document. Within the object we need to add the string “/Names X 0 R”, where X is the number of our first of three added objects, which in our case is 26.
5. Adding “/Names 26 0 R ” to the root object to reference our first added block.
4) The last step is to edit the trailer of the document. The trailer is at the end of the document as figure 3 already showed and contains the total amount of objects within the document. Sometimes there are two trailers. To reduce the risk of failures it is recommended to edit both of them, even though editing just the last one usually works aswell. Since the reference table is our last object inside the document and it is numbered as 29, we have to edit the trailer accordingly as shown in figure 6. For comparison, see the original trailer in figure 3.
6. Reference table (green). Trailer (blue). Editing size of the document with the new total amount of objects (orange).
After saving everything we are ready to test if everything is working as intended. When we open the document with an Adobe Acrobat Reader we see that the java script gets executed right away, asking for username and password.
7. The injected java script asks for a username.8. Afterwards the java script asks for the corresponding password.
After entering a username and password, the java script tries to sent the data to the web server stored inside the source code. With default configuration the Acrobat Reader will display a security warning as shown in figure 9.
9. Acrobat security warning when any connection to an external resource happens.
If the user accepts the risk, the username and password will be sent to the web server of the attacker.
10. Using a web server for username and password exfiltration.
Alternatively an attacker can inject any other action that java script is capable of executing. For example to trick a user into downloading and executing a binary.
Countermeasures:
1) Make sure that allapplications that you provide for viewing PDF documents within your environment do not allow the execution of java script.
11. Deactivate java script for Acrobat Reader.
2) Make sure that all applications that you provide for viewing PDF documents within your environment have restricted access or no access at all to the internet and other non-PDF documents.
12. Restrict access to the internet and all non-PDF attachments.
