Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A webshell and a normal file that have the same MD5

github.com

Post reply on HN
Print view View original

41–49 of 49 posts

Re: A webshell and a normal file that have the same MD5

#41

Post by lisper »

alkonaut wrote: post #39
lisper wrote: post #10

Earlier quoted context omitted.

If you don't know, then you aren't the target audience. 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.

> system under some very obscure set of circumstances that you are very unlikely to encounter in the real world. 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.

> Is there any way to use HN karma?

Nothing other than vanity AFAIK.

It's actually a bit of a scam because karma accumulates and never expires. I've been on the leaderboard for a long time, not because I'm making particularly valuable contributions (I only post a few times a week) but just because I've been on HN since it launched.

Re: A webshell and a normal file that have the same MD5

#42

Post by IshKebab »

jgalt212 wrote: post #33
IshKebab wrote: post #17

Earlier quoted context omitted.

There's no need to rescan. You just need to use a secure hash.

Secure for now, rather. A solid game plan would be to have your code base set up to easily swap in a new hashing method when called for. I believe Django automatically promotes passwords stored with insecure hashes to secure ones the next time a user logs in.

Yeah not really an issue for a cache since you can just invalidate the cache when you change algorithm.

Re: A webshell and a normal file that have the same MD5

#43

Post by bawolff »

ramses0 wrote: post #34
bawolff wrote: post #32

Earlier quoted context omitted.

> If you don't know, then you aren't the target audience. 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).

Someone with more karma motivation could post this as a top level story, but Plex offers to validate their Debian public key via MD5: https://support.plex.tv/articles/235974187-enable-repository... Such security! Much wow!

While this is a bad idea, as far as i know its secure since nobody has broken md5 second preimage.

Re: A webshell and a normal file that have the same MD5

#44

Post by edgineer »

sltkr wrote: post #28
gruez wrote: post #26

Earlier quoted context omitted.

I only see new CPUs benchmarked, maybe that's because newer CPUs have SHA acceleration extensions? I'd expect SHA256 to be more complex and therefore be more computationally expensive.

Yes, SHA256 is faster than MD5 only if you have hardware accelleration. But SHA256 itself is pretty slow compared to the state of the art. For example, BLAKE3 is just as secure as SHA256 but an order of magnitude faster. 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 sha256…

>BLAKE3 is just as secure as SHA256 but an order of magnitude faster

Is this not an oxymoron? E.g. b3 then ought to be an order of magnitude easier to brute force.

Re: A webshell and a normal file that have the same MD5

#45

Post by sltkr »

edgineer wrote: post #44
sltkr wrote: post #28

Earlier quoted context omitted.

Yes, SHA256 is faster than MD5 only if you have hardware accelleration. But SHA256 itself is pretty slow compared to the state of the art. For example, BLAKE3 is just as secure as SHA256 but an order of magnitude faster. 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 sha256…

>BLAKE3 is just as secure as SHA256 but an order of magnitude faster Is this not an oxymoron? E.g. b3 then ought to be an order of magnitude easier to brute force.

I'm talking about theoretic security, i.e. number of operations needed to perform certain attacks.

For a 256-bit cryptographic hash function, it should take an expected 2^256 attempts to find a message with a given hash (preimage attack) and around 2^128 attempts to find any collision (due to the birthday paradox), and a few other properties like that. This holds for both SHA-256 and Blake3 (as far as we know—neither algorithm has proven security*) but not for MD5.

MD5 is insecure not just because its output size of 128 bit is too short (though that's a problem too), but also because it has weaknesses that allow constructing collisions with much less than the 2^64 attempts than you would expect on the basis of its output size. That's why MD5 is considered insecure even for its size.

Generally speaking, you want your hashing primitives to be as fast as possible. The practical security then comes from the output size. If someone discovered a secure 320-bit cryptographic hash that is a trillion times faster than even Blake3 (10^12 or about 2^40), everyone should adopt it, because it would be much faster and even more secure against brute force attacks than SHA-256/Blake3 are (since 320 > 256 + 40).

While there are use cases for deliberately slow hash functions too (notably password hashing) those can be constructed using fast hash functions as primitives. For example, one of the strongest password hashing schemes (Argon2) is based on one of the fastest hashing primitives (Blake2), not a slow one as you might have expected.

Re: A webshell and a normal file that have the same MD5

#46

Post by [deleted] »

eptcyka wrote: post #14
0points wrote: post #11

Earlier quoted context omitted.

> The answer is likely wordpress, because its default wp_hash algorithm is still MD5. 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.…

> As usual, you cannot make a coherent understanding on just about any subject by reading headlines alone. The amount of sweet, sweet irony displayed here will make me diabetic. Did you read the article at all? Salting? What are you on about? Honestly, it feels that some HN commenters are LLMs instructed to defend a given entity.

[deleted]

Re: A webshell and a normal file that have the same MD5

#47

Post by h4ck_th3_pl4n3t »

0points wrote: post #11
h4ck_th3_pl4n3t wrote: post #9

Earlier quoted context omitted.

The answer is likely wordpress, because its default wp_hash algorithm is still MD5.

> The answer is likely wordpress, because its default wp_hash algorithm is still MD5. 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.…

Your source described wp_hash_password(), not wp_hash().

As the OP article/PoC is about hashing uploaded files, not passwords btw, I think you should read it again.

Because as I pointed out, wp_hash() is used to check against uploaded files.

Oh, and source: https://developer.wordpress.org/reference/functions/wp_hash/

And as I cannot resist quoting you for trying to smartass while literally not having read the source code the PoC was about:

> 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.

Re: A webshell and a normal file that have the same MD5

#48

Post by oconnor663 »

edgineer wrote: post #44
sltkr wrote: post #28

Earlier quoted context omitted.

Yes, SHA256 is faster than MD5 only if you have hardware accelleration. But SHA256 itself is pretty slow compared to the state of the art. For example, BLAKE3 is just as secure as SHA256 but an order of magnitude faster. 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 sha256…

>BLAKE3 is just as secure as SHA256 but an order of magnitude faster Is this not an oxymoron? E.g. b3 then ought to be an order of magnitude easier to brute force.

This is a common misconception, based on the difference between password hashing and other general uses for a cryptographic hash. Password hashing is special, because we want to protect people who pick terrible passwords, so we need guess-and-check to be expensive. But for most other use cases, like say HMAC or signing, the number of possible inputs is so astronomically large that guess-and-check would be impossible even if each guess was e.g. just a single add instruction. This distinction is why we say never to use a general purpose hash with passwords.

Re: A webshell and a normal file that have the same MD5

#49

Post by sim7c00 »

Blahagun wrote: post #36
sim7c00 wrote: post #21

honestly, normal.php is not a valid php file. i do understand that it might bypass some checks if say normal.php was somehow flagged as a valid / benign file but in all honesty that would be really bad sec product u wanna swap with something that more intelligently classifies files... additionally, most products these days also use sha1, sha2 and sometimes things like ssdeep to have multiple hash variants to check. t…

normal.php is a perfectly valid php file. Sure, it doesn't contain php code but that doesn't make it invalid php file. If it did have <?php somewhere and if the following wasn't a syntactically valid PHP code, then you could say it's not a valid php file.

yeah ok fair point. from the interpreter perspective. but that is not the tool which checks security. in that context validity is determined by another tool, which will look beyond merely being interpretable by the php interpreter.

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

Post reply on HN