Post Avitu3ZoJM4SlM4BA8 by gynvael@infosec.exchange
(DIR) More posts by gynvael@infosec.exchange
(DIR) Post #Avitu3ZoJM4SlM4BA8 by gynvael@infosec.exchange
2025-07-02T11:58:03Z
5 likes, 2 repeats
Imagine the following situation: your company receives a ZIP file with an invoice, and you're the person responsible for checking if all the details are correct, before sending it off to the payment department. You open the archive, and there's a single PDF inside. You view it, and all the details match—your company's details, seller's company's details, items and total amount are what's expected, and even the bank account number is the same as on previous invoices from this company. As everything looks good, you forward the ZIP with the invoice to the payment team, and move onto reviewing other incoming invoices.A few days later you receive the same invoice again, but you already have it in the system. Just in case you reach out to the payment department whether it's been paid, and they confirm it has—great, no action required.Another month passes by, and you get a "payment due" reminder. What's this? You remember it being paid already, so what gives. You ask the payment team, they again confirm the invoice was settled. You phone the seller about this, but they say they received nothing. So you head down the hall to the payment department, you open the invoice on your laptop, and start going through the details with them. But what's this? The destination account number and amount in the wire transfer and the invoice don't match! The payment team manager's face gets a bit red—seems like it was their mistake? But no! They show you the invoice, and the amount and account number match the actual payment... but it doesn't match what you see on your screen! How can this be?Both of you re-download the ZIP archive from the email you've forwarded and open the PDF inside. And there it is—you see two different invoices. What in the world is happening?Immediately you report it up the chain, and your boss's boss gets a pair of IT forensics consultants on the job. They investigate, and later you learn that your company has been scammed with a pair of different invoices hidden inside a schizophrenic ZIP file. This means that you—on your work laptop running a certain software stack—saw and approved the correct invoice. But the payment team—running a different software stack—saw the fake invoice inside the ZIP, which they thought was what you had approved. Even later on you find out that the seller's company has been partially compromised and a lot of their customers got fake invoices. But that's water under the bridge at that point, and the money your company transferred is long gone.Technical details → https://hackarcana.com/article/yet-another-zip-trick
(DIR) Post #Avitu4kpvqU8PqEUzI by wolf480pl@mstdn.io
2025-07-02T12:46:12Z
0 likes, 0 repeats
@gynvael I didn't think I'd see TOCTOU used against humans
(DIR) Post #AvjQ0bR8WvZW35Asng by wolf480pl@mstdn.io
2025-07-02T18:45:58Z
0 likes, 0 repeats
@gynvael wait, so how many different ways of reading zipfiles do we know so far?- from the start, only LFHs- from the end, find last* EOCD use CDH size- from the end, find last* EOCD, use CDH offset- from EOF-65557, find first EOCD , use CDH size- from EOF-65557, find first EOCD- from start, find first CDHbut any of the 5 that deal with CDH also have to deal with redundancy between CDH and LFH, so x2that'd be 11?*could be inside a comment
(DIR) Post #AvjUaaV9srYnOFTD28 by wolf480pl@mstdn.io
2025-07-02T19:37:14Z
0 likes, 0 repeats
@mei @gynvael no i meanIf instead of parsing it once, checking the parsed form, and then immediately using it, or, alternatively, serializing it into a fresh file that contains only verified data and can be used laterIf instead of doing that you parse the input file at two different times, once to check and once to useThat's called TOCTOU, right?
(DIR) Post #AvjV9M1bhQymcwE3Ie by wolf480pl@mstdn.io
2025-07-02T19:43:33Z
0 likes, 0 repeats
@mei @gynvael hmm ok, i guess I broadened the definition in my headcanon too much.But still, you defend from both the same way, right? You only read/parse the input once?
(DIR) Post #AvjVNW8itEMc3GJ8Hw by wolf480pl@mstdn.io
2025-07-02T19:46:07Z
0 likes, 0 repeats
@mei @gynvael and in this case, you'd extract the zip, open the invoice, check it, screenshot it, and send the screenshot to the payments department?
(DIR) Post #AvjoMNHmDn8FQmi8yu by lispi314@udongein.xyz
2025-07-02T23:00:27.844369Z
0 likes, 0 repeats
@wolf480pl @gynvael @mei Given email supports multiple attachments, simply banning the use of zip files for transfers of few files (<=10 attachments is more than reasonable) or any number of invoice files would be the proper step (a policy change, instead of technical).I'd considered technical changes to prevent this (without spec changes) but that assumes everyone uses non-broken software (lol) that does verify all redundant fragments & fields (requiring new program flags to handle files from unreliable storage/transfer) and still leaves the issue of update/deletion/hiding being a valid operation by spec (there is no explicit user-visible versioning).
(DIR) Post #AvjoMOA0y8W8905SWO by wolf480pl@mstdn.io
2025-07-02T23:18:48Z
0 likes, 0 repeats
@lispi314 @mei @gynvael I think you're taking this too practically.My proposed solution wasn't meant to be a serious proposal, but an example of applying the general principle of TOCTOU-resistant systems to the system of two humans who deal with invoices.Banning zip files only protects from ambiguous zip files. One day someone may come up with a way to make an ambiguous PDF thay displays differently in pdf.js than in Adobe Reader, and then what?
(DIR) Post #AvkKihDryRYYAVZSpU by lispi314@udongein.xyz
2025-07-02T23:37:12.230719Z
0 likes, 0 repeats
@wolf480pl @gynvael @mei PDF is indeed a problematic format for a number of reasons. Its specification has some major issues and it should probably be deprecated.djvu could somewhat substitute in the meantime, though something else meant to actually fill in PDF's role but doing it right would be preferable.
(DIR) Post #AvkKiiEGETSnI0lI4u by lispi314@udongein.xyz
2025-07-02T23:59:17.958117Z
0 likes, 0 repeats
@mei @gynvael @wolf480pl > My proposed solution wasn't meant to be a serious proposal, but an example of applying the general principle of TOCTOU-resistant systems to the system of two humans who deal with invoices.Yeah, I did notice the cached-rendering/resolution. For static data that is appropriate, though it ultimately relies on the existence of data with a non-broken parser.The re-creation of the data, I think, also potentially moves some of the liability onto the converting user.
(DIR) Post #AvkKijQhlh0n0tak76 by wolf480pl@mstdn.io
2025-07-03T05:21:22Z
0 likes, 0 repeats
@lispi314 @mei @gynvael the whole point is that the re-creatong user is the one with knowledge and authority go tell which data is good. The goal is that the second person will only receive data that the verifier person understood, so any hidden bits that the attacker can manipulate without the verifier's knowledge don't get transmitted
(DIR) Post #AvkLeAmojHaEMgKBTE by lispi314@udongein.xyz
2025-07-03T05:30:19.445966Z
0 likes, 0 repeats
@wolf480pl @gynvael @mei I suppose that is one way of viewing it.I simply prefer the option of a more static & reliable format where, if it is corrupt, liability and blame for the mistake (or malicious action) falls unambiguously to the external provider.In this case though, why not have the re-creator just file the data in some internal form/filling system (submitting said form to payments)?
(DIR) Post #AvkLeBjJDoN5I5gtdo by wolf480pl@mstdn.io
2025-07-03T05:31:47Z
0 likes, 0 repeats
@lispi314 @mei @gynvael yeah, that's a more faithful imolementation of that idea
(DIR) Post #Avkp74jfCcvMfPz25w by LukeAlmighty@gameliberty.club
2025-07-03T11:01:57Z
0 likes, 0 repeats
@gynvael How do you even collect the info needed to pull something like this off?
(DIR) Post #Avkrjyi7jiw5BQwPvU by alyx@gameliberty.club
2025-07-03T11:31:22Z
1 likes, 0 repeats
@LukeAlmighty @gynvael Probably long term monitoring. What I'm more curious about is where in the chain was the zip file created. As in, did they hack the email server and manually changed up the attachments before the mail was actually sent of? Did they implement a complex virus that created all of it when the company was trying to zip the invoice for email?
(DIR) Post #Avkvqk0hBru7R06mGm by beardalaxy@gameliberty.club
2025-07-03T12:17:26Z
0 likes, 0 repeats
@alyx @LukeAlmighty @gynvael what if the company did it themselves, maybe it was an inside job :thonktinfoil: