https://github.com/angea/pocorgtfo#0x14
And yes, documents are not normally supposed to be able to display their own MD5 hash.
Also, a more recent innovation in MD5 collisions is textcoll, which creates colliding blocks that are completely plaintext. This would allow for colliding PHP source files like in OP but without any obvious binary artefacts (although this requires identical prefixes).
https://github.com/cr-marcstevens/hashclash?tab=readme-ov-fi...
[1]: https://lemire.me/blog/2025/01/11/javascript-hashing-speed-c...
Try this on your own system:
$ head -c 1000000000 /dev/urandom > random-1gb
$ time md5sum random-1gb
ef72a3616aad5117ddf40a7d5f5d0162 random-1gb
real 0m2.428s
user 0m2.192s
sys 0m0.202s
$ time sha256sum random-1gb
ec7d7f31c4489acae8328fddbe54157f1cb9e97b220ef502a07e1f9230969310 random-1gb
real 0m3.894s
user 0m3.697s
sys 0m0.181s
$ time b3sum random-1gb
11fe11cc5721faf65369d18893d7b7631f6178b4692bc0bb03b1b180273cd384 random-1gb
real 0m0.282s !!!
user 0m0.876s
sys 0m0.124s
$ time b3sum --num-threads=1 random-1gb
11fe11cc5721faf65369d18893d7b7631f6178b4692bc0bb03b1b180273cd384 random-1gb
real 0m0.597s
user 0m0.488s
sys 0m0.107s
The only CPUs still likely to be in use and without SHA support are the Intel Core CPUs until and including the Skylake derivatives (i.e. up to Comet Lake, i.e. up to 6 years ago).
The Intel Atoms have received SHA support many years before Intel Core, because they competed with ARM, which already had such support.
The support in Intel Core has been added due to AMD Zen, but the products with it have been delayed by the failure of Intel to achieve acceptable fabrication yields in their 10-nm CMOS process, before 2019/2020.
1. You can upload scripts that get scanned for malicious code 2. These scripts can be executed once deemed "safe" 3. The server is using MD5 hashes to determine if you uploaded the same file or if it should re-scan it
3. Is where the issue is. It should probably always re-scan it and it definitely should not be using MD5.
Wouldn't the sensible thing for a server that gets an upload matching an existing file's hash be to just treat it as an idempotent no-op? What reason would it have to replace the old version with a presumably identical copy? What am I missing?
Most I've seen (sec scans, backup validation/dedup etc) pushed to phase out md5 very long time ago.
But there are two applications: the first is breaking in to a system under some very obscure set of circumstances that you are very unlikely to encounter in the real world. The second is to bump up your karma on HN.
If you do know, then you also know md5 being broken is really really old news.
Seriously. Cryptographers have been warning that md5 seems weak since 1996. There are probably people reading this thread who weren't even alive yet. (It got totally broken in 2004 but the warning signs were way earlier).
Is there any way to use HN karma? Like, can I sell my account on some shady exchange like people sell big twitter accounts? And if I can, what's the going rate for internet points these days? Asking for an unscrupulous friend.
The thing that makes this blog post not realistic is:
* Such tricks would make much more sense with normal programs, where you're trying to trick an user to download and execute it. Webshells are downloaded by the attacker knowingly.
* Md5 is not used anymore (although I know security vendors who used it for embarrassingly long time). If this was SHA256, that attack would be devastating for many more severe reasons.
But it's still a fun PoC.
That's only true if you ignore all the details.
As usual, you cannot make a coherent understanding on just about any subject by reading headlines alone. Life would have taught you by now that the devil is in the details.
WP uses salt and multiple rounds of hashing, fully mitigating the md5 collisions being topic of discussion here.
So no, wp doesn't "use md5" in the sense that they would be vulnerable to this type of attack.
Source: https://developer.wordpress.org/reference/functions/wp_hash_...
> Can use it bypass some cached webshell detections.
if normal.php had actual php code in there, being really 'normal' as the name implies, this would be much more severe / interesting because it might be more easy to convince modern security products it's actually a benign file.
Currently if it would be analysed, it would be flagged as suspicious simply because its not a valid file. and really, it dont need to be php, it could be any valid file format as long as it's an actually file that has benign behavior or contents.
plaintext might be easier to generate, but you'd need it to be 'executable' format or something interpretable like a script to have it actually stored in databases marking files as malicious or benign. matching filetype with the malicious file, in a valid form that does actual benign behavior would be 'best'.
don't take me wrong tho. still fun to see these things and honestly props, if it bypasses anything that's always a 'nice result' :)
its funny often web basted languages have this property tho , i mean, how else you gonna poison logs and execute them :')... js and php are just adorable for providing opportunities :D