4 ms·

Super impressed how quickly the community and in particular amlweems were able to implement and document a POC. If the cryptographic or payload loading function

• rst 3y ago
  Well, it's a POC against a re-keyed version of the exploit; a POC against the original version would require the attacker's private key, which is undisclosed.
  • miduil 3y ago
    It's a POC nevertheless, it's a complete implementation of the RCE minus obviously the private key.
    • nindalf 3y ago
      It doesn't matter. The people with the private key already knew all of this because they implemented it. The script kiddies without the private key can't do anything without it. A POC doesn't help them in any way. A way to check if servers are vulnerable is probably by querying the package manager for the installed version of xz. Not very sophisticated, but it'll work.
      • miduil 3y ago
        > It doesn't matter. To understand the exact behavior and extend of the backdoor, this does matter. An end to end proof of how it works is exactly what was needed. > A way to check if servers are vulnerable is probably by querying the package manager Yes, this has been know since the initial report + later discovering what exact strings are present for the payload. https://github.com/Neo23x0/signature-base/blob/master/yara/bkdr_xz_util_cve_2024_3094.yar https://github.com/Neo23x0/signature-base/blob/master/yara/b... > Not very sophisticated, but it'll work. Unfortunately, we live in a world with closed-servers and appliances - being able as a customer or pen tester rule out certain class of security issues without having the source/insights available is usually desirable.
        • nindalf 3y ago
          > we live in a world with closed-servers and appliances Yeah but these servers and appliances aren't running Debian unstable are they? I'd understand if it affected LTS versions of distros, but these were people living on the bleeding edge anyway. Folks managing such servers are going to be fine running `apt-get update`. We got lucky with this one, tbh.
      • doakes 3y ago
        Are you saying POCs are pointless unless a script kiddie can use it?
        • nindalf 3y ago
          The context of the conversation, which you seem to have missed, is that now that we have a POC, we need a way to check for vulnerable servers. The link being that a POC makes it easier for script kiddies to use it, meaning we're in a race against them. But we aren't, because only one group in the whole world can use this exploit.
          • miduil 3y ago
            > is that now that we have a POC, we need a way to check for vulnerable servers. You misunderstand me, the "need to check for vulnerable servers" has nothing to do with the PoC in itself. You want to know whether you're vulnerable against this mysterious unknown attacker that went through the all the hoops for a sophisticated supply chain attack. I never said that we need a way to detect it because there is a POC out, at least I didn't meant to imply that either. > script kiddies to use it, meaning we're in a race against them This is something you and the other person were suddenly coming up with, never said this in first place.
  • misswaterfairy 3y ago
    Could the provided honeypot print out keys used in successful and unsuccessful attempts?
    • bheadmaster 3y ago
      I don't think any (sane) client would sent its private key on login. Private key only serves as a "solver" of a puzzle created using the public key.
• cjbprime 3y ago
  Probing for vulnerable deployments over the network (without the attacker's private key) seems impossible, not non-trivial. The best one could do is more micro-benchmarking, but for an arbitrary Internet host you aren't going to know whether it's slow because it's vulnerable, or because it's far away, or because the computer's slow in general -- you don't have access to how long connection attempts to that host took historically. (And of course, there are also routing fluctuations.)
  • deleted 3y ago
    [deleted]
  • anonymous-panda 3y ago
    Should be able to do it by having the scanner take multiple samples. As long as you don’t need a valid login and the performance issue is still observable, you should be about to scan for it with minimal cost
    • cjbprime 3y ago
      Looks like the slowdown is actually at sshd process startup time, not authentication time. So it's back to being completely impossible to network-probe for.