22 ms·
Hitting a vendor web server on plaintext HTTP? That right there is a massive red flag. If this were legitimate traffic, that'd be enough reason to drop the vend
by marcan_42 6y ago
Hitting a vendor web server on plaintext HTTP? That right there is a massive red flag. If this were legitimate traffic, that'd be enough reason to drop the vendor right then and there.
If this were HTTPS then it wouldn't need the obfuscation to pass by undetected. And then there isn't much you could do at that point to find it via traffic analysis, assuming the uncompromised app makes similar HTTPS connections, other than perhaps going deeper into traffic pattern analysis if you're lucky.
Once the threat is identified some other way, it might be possible to develop blocking rules that work at the ciphertext layer (e.g. from packet size patterns exhibited only by the backdoor requests).
- nl 6y agoI wouldn't read too much into the missing "S" in the write-up. It's unclear from that one rule but the majority of the Snort rules for this exploit stop HTTPS. Note the "port 443" in the rules.
- marcan_42 6y agoAnd those rules are matching TLS ciphertext (record headers and SNI). The path rule is matching plaintext, so it's obviously not inspecting TLS.
- Wheaties466 6y agoI wish that were the case, but unfortunately some credit card processors still send some credit card processing payloads over http in some circumstances.
- colejohnson66 6y agoIs the actual payload encrypted, but just sent over HTTP? In that case, it’s bad, but not as bad as unencrypted over HTTP.