22 ms·
Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
- miduil 3y agoSuper impressed how quickly the community and in particular amlweems were able to implement and document a POC. If the cryptographic or payload loading functionality has no further vulnerabilities, this would have been also at least not introducing a security flaw to all the other attackers until the key is broken or something. Edit: I think what's next for anyone is to figure out a way to probe for vulnerable deployments (which seems non-trivial) and also perhaps possibly ?upstreaming? a way to monitor if someone actively probes ssh servers with the hardcoded key. Kudos!
- rst 3y agoWell, 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 agoIt's a POC nevertheless, it's a complete implementation of the RCE minus obviously the private key.
- nindalf 3y agoIt 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 agoAre you saying POCs are pointless unless a script kiddie can use it?
- nindalf 3y agoThe 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 agoCould the provided honeypot print out keys used in successful and unsuccessful attempts?
- bheadmaster 3y agoI 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 agoProbing 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 agoShould 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 agoLooks 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.
- supriyo-biswas 3y agoAll these efforts are appreciated, but I don't think the attacker is going to leak their payload after the disclosure and remediation of the vuln.
- chonkerz 3y agoThese efforts have deterrence value
- acdha 3y agoHas anyone tried the PoC against one of the anomalous process behavior tools? (Carbon Black, AWS GuardDuty, SysDig, etc.) I’m curious how likely it is that someone would have noticed relatively quickly had this rolled forward and this seems like a perfect test case for that product category.
- bobby_the_whale 3y ago[dead]
- knoxa2511 3y agoSysdig released a blog on friday. "For runtime detection, one way to go about it is to watch for the loading of the malicious library by SSHD. These shared libraries often include the version in their filename." The blog has the actual rule content which I haven't seen from other security vendors https://sysdig.com/blog/cve-2024-3094-detecting-the-sshd-backdoor-in-xz-utils/ https://sysdig.com/blog/cve-2024-3094-detecting-the-sshd-bac...
- acdha 3y agoThanks! That’s a little disappointing since I would have thought that the way it hooked those functions could’ve been caught by a generic heuristic but perhaps that’s more common than I thought.
- RamRodification 3y ago
- arnaudsm 3y agoHave we seen exploitation in the wild yet?
- winkelmann 3y agoI assume the operation has most likely been called off. Their goal was probably to wait until it got into stable distros. I doubt there is a large number of unstable Debian or Fedora Rawhide servers with open SSH in the wild.
- rwmj 3y agoIf it hadn't been discovered for another month or so, then it would have appeared in stable Fedora 40, Ubuntu 24.4 and Debian, and then it definitely would have been exploited. Another year it would have been in RHEL 10. Very luck escape.
- bclemens 3y agoNope, it wouldn't have been in RHEL 10 or any of the rebuilds. CentOS Stream 10 already branched from Fedora / ELN. The closest it would have gotten is a Fedora ELN compose, and it's doubtful it would have remained undiscovered long enough to end up in CentOS Stream 11.
- rwmj 3y agoWe likely would have backported the change. I'm already planning a big rebase of packages that missed the Fedora 40 / C10S branch (related to RISC-V in that case).
- asveikau 3y agoIt's pretty interesting that they didn't just introduce an RCE that anyone can exploit, it requires the attacker's private key. It's ironically a very security conscious vulnerability.
- haswell 3y agoI suspect the original rationale is about preserving the longevity of the backdoor. If you blow a hole wide open that anyone can enter, it’s going to be found and shut down quickly. If this hadn’t had the performance impact that brought it quickly to the surface, it’s possible that this would have lived quietly for a long time exactly because it’s not widely exploitable.
- declan_roberts 3y agoI agree that this is probably about persistence. Initially I thought the developer was playing the long-con to dump some crypto exchange and make off with literally a billion dollars or more. But if that was the case they wouldn't bother with the key. It'd be a one-and-done situation. It would be a stop-the-world event. Now it looks more like nation-state spycraft.
- meowface 3y ago>But if that was the case they wouldn't bother with the key. It'd be a one-and-done situation. It would be a stop-the-world event. Why not? It's possible someone else could've discovered the exploit before the big attack but decided not to disclose it. Or that they could've disclosed it and caused a lot of damage the attacker didn't necessarily want. And they easily could've been planning both a long-term way to access a huge swath of machines and also biding their time for a huge heist. They have no reason to not restrict the backdoor to their personal use. And it probably is spycraft of some sort, and I think more likely than not it's a nation-state, but not necessarily. I could see a talented individual or group wanting to pull this off.
- varenc 3y ago
- bobby_the_whale 3y ago[dead]
- jobs_throwaway 3y agoImagine how frustrating it has to be for the attacker to meticulously plan and execute this and get foiled so late in the game, and so publicly
- Alifatisk 3y agoMust be punching the air right now
- cellis 3y agoOr...falling back on less noticed contingency plans...
- Ekaros 3y agoMy pet theory is that this was just one project they have been running for years. They are likely doing many more at same time. Slowly inserting parts in various projects and getting their contributors inside the projects.
- 0cf8612b2e1e 3y agoThat seems like a safe bet. If you are planning a multi year operation, it would be silly to do it all under a single account. Best to minimize the blast radius if any single exploit gets discovered.
- guyomes 3y agoSome of this activity was actually documented through the alleged data breach of a hacking company [1]. [1]: https://en.wikipedia.org/wiki/Hacking_Team https://en.wikipedia.org/wiki/Hacking_Team
- SAI_Peregrinus 3y agoIf it's an intelligence agency exploit, this is nearly certain. Getting agents hired as employees of foreign companies to provide intelligence is an ancient practice. Getting agents to be open source maintainers is a continuation of the same thing.
- herpderperator 3y ago> Note: successful exploitation does not generate any log entries. Does this mean, had this exploit gone unnoticed, the attacker could have executed arbitrary commands as root without even a single sshd log entry on the compromised host regarding the 'connection'?
- sureglymop 3y agoYes.. The RCE happens at the connection stage before anything is logged.
- udev4096 3y agoThat's insane. How exactly does this happen? Are there no EDR/IDS who can detect an RCE at the connection stage?
- bawolff 3y agoAn IDS may detect something depending on what it is looking for. The grandparent is saying that sshd doesn't log anything. Which is not that surprising since sshd is atracker controlled.
- gus_ 3y agoAn EDR would have detected an inbound connection to port 22. Then it'd have detected the attacker's activity (opened files, executed commands, etc) If the EDR is capable of intercepting the forks, clone() execves, open(), etc, then you can follow the traces. If it's able to deny certain activity based on rules like modifying /etc/ld.so.preload or download files with curl/wget, it'd have made the attacker's life a bit more difficult. If the attacker loaded a rootkit, then probably you'd have lost visibility of what the attacker did after that. Also not all the EDRs hook all the functions, or they have bugs, so many times you are not able to follow a trace (without pain/guessing). This telemetry usually is sent to a remote server, so the attacker could not have deleted it.
- saagarjha 3y agoIt is very difficult for EDR to detect something like this, because it would look like a SSH connection.
- Joel_Mckay 3y agoToo bad, for a minute I thought it was something useful like adding a rule to clamav to find the private key-pair signature ID of the servers/users that up-streamed the exploit. "Play stupid games, win stupid prizes"
- dec0dedab0de 3y agoStuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. 20 years ago, I was working at an ISP/Telco and one of our vendors had a permanent admin account hardcoded on their gear, you couldn't change the password and it didn't log access, or show up as an active user session. Always limit traffic to just what is necessary, does the entire internet really need to be able to SSH to your box?
- herpderperator 3y agoThe thing about port knocking is that if you're on a host where you don't have the ability to port-knock, then you're not able to connect. This can turn into a footgun: you're away from your usual device, something happens and you desperately need to connect, but now you can't because all the devices in your vicinity don't have the ability to perform $SECURITY_FEATURE_X so that you can connect, and you're screaming at yourself for adding so much security at the expense of convenience. This could happen as easily as restricting logins to SSH keys only, and not being able to use your SSH key on whatever host you have available at the time, wishing you'd have enabled password authentication.
- pajko 3y agohttps://github.com/CERN-CERT/pam_2fa https://github.com/CERN-CERT/pam_2fa
- herpderperator 3y agoWhat does this have to do with port knocking?
- nequo 3y agoThis is great but would this neutralize the xz backdoor? The backdoor circumvents authentication, doesn't it?
- Joel_Mckay 3y agoPort knocking with ssh over https using client certs. And port knocking is one of the few effective methods against the standard distributed brute forcing slow attacks. Note if you blanket-ban IN/RU/UK/CN/HK/TW/IR/MX/BZ/BA + tor/proxies lists, than 99.998% of your nuisance traffic issues disappear overnight. =)
- mrob 3y agoDo we know if this exploit only did something if a SSH connection was made? There's a list of strings from it on Github that includes "DISPLAY" and "WAYLAND_DISPLAY": https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01 https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01 These don't have any obvious connection to SSH, so maybe it did things even if there was no connection. This could be important to people who ran the code but never exposed their SSH server to the Internet, which some people seem to be assuming was safe.
- cma 3y agoCould that be related x11 session forwarding (common security hole on the connectors' side if they don't turn it off when connecting to an untrusted machine).
- rdtsc 3y agoThose are probably kill switches to prevent the exploit from working if there is a terminal open or runs in a GUI session. In other words someone trying to detect, reproduce or debug it.
- yodsanklai 3y agoDo we know who's the attacker?
- toasteros 3y agoThe name that keeps coming up is Jia Tan (https://github.com/JiaT75/ https://github.com/JiaT75/) but we have no way of knowing if this is a real name, pseudonym, or even a collective of people.
- pphysch 3y agoGiven the sophistication of this attack it would indeed be downright negligent to presume that it's the attackers' legal name and that they have zero OPSEC.
- xvector 3y agoHe used ProtonMail. I wonder if ProtonMail can pull IP logs for this guy and share them.
- eklitzke 3y agoIt might be worth looking into, but: 1) Probably by design protonmail doesn't keep these kinds of logs around for very long 2) Hacking groups pretty much always proxy their connection through multiple layers of machines they've rooted, making it very difficult or impossible to actually trace back to the original IP
- xvector 3y agoFor [1], unfortunately it does. True regarding the second point. [1]: https://techcrunch.com/2021/09/06/protonmail-logged-ip-address-of-french-activist-after-order-by-swiss-authorities/ https://techcrunch.com/2021/09/06/protonmail-logged-ip-addre...
- ajross 3y agoIt's also worth pointing out, given the almost two years of seemingly valuable contribution, that this could be a real person who was compromised or coerced into pushing the exploit.
- faxmeyourcode 3y agoEdit: I misunderstood what I was reading in the link below, my original comment is here for posterity. :) > From down in the same mail thread: it looks like the individual who committed the backdoor has made some recent contributions to the kernel as well... Ouch. https://www.openwall.com/lists/oss-security/2024/03/29/10 https://www.openwall.com/lists/oss-security/2024/03/29/10 The OP is such great analysis, I love reading this kind of stuff!
- davikr 3y agoLasse Collin is not Jia Tan until proven otherwise.
- robocat 3y agoPassive aggressive accusation. This style of fake doubt is really not appropriate anywhere.
- pavon 3y agoNo, he likely is not. But the patch series includes commits co-developed by Jia Tan, and lists Jia Tan as a maintainer of the kernel module.
- verytrivial 3y agoSpeaking only hypothetically, but two points: 1) No-one has been is proven to "be" anyone in this case. Reputation is OSS is built upon behaviour only, not identity. "Jia Tan" managed to tip the scales by also being helpful. That identity is 99% likely to be a confection. 2) People can do terrible things when strongly encouraged or worse coerced. Including dissolving identity boundaries. The first problem can be 'solved' by using real identities and web of trust but that will NEVER fly in OSS for a multitude of technical and social reasons. The second problem will simply never be solved in any context, OSS or otherwise. Bad actors be bad, yo.
- Denvercoder9 3y agoThe referenced patch series had not made it into the kernel yet.
- gghffguhvc 3y agoIs there anything actually illegal here? Like is it a plausible “business” model for talented and morally compromised developers to do this and then sell the private key to state actors without actually breaking in themselves or allowing anyone else to break in. Edit: MIT license provides a pretty broad disclaimer to say it isn’t fit for any purpose implied or otherwise.
- kstrauser 3y agoYes. This would surely be prosecutable under the CFAA. Honestly, if I were involved in this, I'd hope that it was, say, the FBI that caught me. I think that'd be the best chance of staying out of the Guantanamo Bay Hilton, laws be damned.
- gghffguhvc 3y agoEven with the MIT disclaimer and the author not being the distributor or have any relationship with the distributor. Publishing vulnerable open source software to GitHub with a disclaimer that says it isn’t fit for any purpose seems like a bit of an oversight of using MIT license in distros to me.
- gghffguhvc 3y agoTHE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
- account42 3y agoBY READING THIS COMMENT YOU AGREE THAT THE AUTHOR CAN TAKE ALL YOUR WORDLY POSSESSIONS. YOU ALSO INDEMNYFY THE AUTHOR FOR ANY HARM THEY MIGHT CAUSE YOU AT ANY TIME. I own you now. Sucks to be you I guess. Or maybe that's not how things work a) limits to what licenses can allow you to do and b) limits to who is bound by the license at all.
- MuffinFlavored 3y agoInstead of needing the honeypot openssh.patch at compile-time https://github.com/amlweems/xzbot/blob/main/openssh.patch https://github.com/amlweems/xzbot/blob/main/openssh.patch How did the exploit do this at runtime? I know the chain was: opensshd -> systemd for notifications -> xz included as transient dependency How did liblzma.so.5.6.1 hook/patch all the way back to openssh_RSA_verify when it was loaded into memory?
- jeffrallen 3y agoifunc
- deleted 3y ago[deleted]
- tadfisher 3y agoWhen loading liblzma, it patches the ELF GOT (global offset table) with the address of the malicious code. In case it's loaded before libcrypto, it registers a symbol audit handler (a glibc-specific feature, IIUC) to get notified when libcrypto's symbols are resolved so it can defer patching the GOT.
- MuffinFlavored 3y ago> When loading liblzma, it patches the ELF GOT (global offset table) with the address of the malicious code. How was this part obfuscated/undetected?
- bewaretheirs 3y agoit was part of the binary malware payload hidden in a binary blob of "test data". In a compression/decompression test suite, a subtly broken allegedly compressed binary blob is not out of place. This suggests we need to audit information flow during builds - the shipping production binary package should be reproduceably buildable without reading test data or test code.
- 3y ago
- declan_roberts 3y agoOne thing I notice about state-level espionage and backdoors. The USA seems to have an affinity for hardware interdiction as opposed to software backdoors. Hardware backdoors make sense since much of it passes through the USA. Other countries such as Israel are playing the long-con with very well engineered, multi-year software backdoors. A much harder game to play.
- wolverine876 3y ago> The USA seems to have an affinity for hardware interdiction as opposed to software backdoors. What are some examples?
- nick238 3y agoThe Clipper chip? Not sure if that's what they had in mind. Nowadays it's maybe just how the NSA has rooms attached to backbone providers like https://theintercept.com/2018/06/25/att-internet-nsa-spy-hubs/ https://theintercept.com/2018/06/25/att-internet-nsa-spy-hub...
- AlexCoventry 3y agohttps://en.wikipedia.org/wiki/Tailored_Access_Operations https://en.wikipedia.org/wiki/Tailored_Access_Operations
- acid__ 3y agoBe sure to check out the mentioned catalog. [1] The NSA's capabilities back in 2008 were pretty astonishing: "RAGEMASTER" A $30 device that taps a VGA cable and transmits the contents of your screen to the NSA van sitting outside! Crazy stuff. Makes you wonder what they've built in the last 15 years. [1] https://en.wikipedia.org/wiki/ANT_catalog https://en.wikipedia.org/wiki/ANT_catalog
- masklinn 3y agoToday you’ve got open access USB cable which can stream your shit out on WiFi, no doubt the NSA has worse.
- nix0n 3y ago[flagged]
- deleted 3y ago[deleted]
- wolverine876 3y agoHave the heads of the targeted projects - including xz (Lasse Collin?), OpenSSH (Theo?), and Linux (Linus) - commented on it? I'm especially interested in how such exploits can be prevented in the future.
- strunz 3y agohttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...: >Lasse regularly has internet breaks and is on one at the moment, started before this all kicked off. He has posted an update at https://tukaani.org/xz-backdoor/ https://tukaani.org/xz-backdoor/ and is working with the community.
- gowld 3y agoOpenSSH and Linux were not targeted/affected. xz and the Debian distribtion of OpenSSH were targeted.
- cpach 3y agoFedora too.
- pama 3y agoThe core source of the vulnerability (symbol lookup order allowing a dependency to preempt a function) might theoretically be fixed at the Linux+OpenSSH level.
- wolverine876 3y agoIt's in their ecosystem; they should be concerned about other similar attacks and about addressing the fears of many users, developers, etc.
- formerly_proven 3y agoDamien Miller (OpenSSH maintainer, OpenBSD committer) has written a patch that implements the relevant libsystemd functionality without libsystemd: https://bugzilla.mindrot.org/show_bug.cgi?id=2641#c13 https://bugzilla.mindrot.org/show_bug.cgi?id=2641#c13
- loeg 3y ago> The ciphertext is encrypted with chacha20 using the first 32 bytes of the ED448 public key as a symmetric key. As a result, we can decrypt any exploit attempt using the following key: Isn't this wild? Shouldn't the ciphertext be encrypted with an ephemeral symmetric key signed by the privkey? I guess anyone with the public key can still read any payload, so what's the point?
- rcaught 3y agoThat action would create extra noise.
- thenewwazoo 3y agoThis is a NOBUS attack - Nobody But Us. By tying it to a particular key owned by the attacker, no other party can trigger the exploit.
- loeg 3y agoI don't think this is responsive to my comment.
- kevincox 3y agoEncrypting the payload will allow you to get by more scanners and in general make the traffic harder to notice. Since the publicly available server code needs to be able to decrypt the payload there is no way to make it completely secure, so this seems like a good tradeoff that prevents passive naive monitoring from triggering while not being more complicated than necessary. The only real improvement that I can see being made would be adding perfect forward secrecy so that a logged session couldn't be decrypted after the fact. But that would likely add a lot of complexity (I think you need bidirectional communication?)
- aborsy 3y agoWhy ED448? It’s almost never recommended, in favor of curve 25519.
- stock_toaster 3y agoI believe ed25519 offers 128 bits of security, while ed448 offers 224 bits of security. ed448 has larger key sizes too, which does seem like an odd choice in this case. Maybe it was chosen for obscurity sake (being less commonly used)?
- throitallaway 3y agoAs I understand it Ed448 was only recently added to openssh, so maybe it was chosen in order to evade detection by analysis tools that scan for keys (if such a thing is possible.)
- juitpykyk 3y agoSome tools scan for crypto algorithms, typically by searching for the magic numbers, Ed448 is so new many tools probably don't recognize it. Malware authors frequently change the crypto magic numbers to prevent detection.
- hakdbha 3y ago[dead]
- Linda231 3y ago[dead]
- mkeymaker 3y agothese things are why focus on assuming compromise should be the default. Stop focusing all the effort on identifying the exploit instead focus on the behaviour of the attacker after exploit.
- heeen2 3y agoI wonder if separating the test files out into their own repo, so that they would not have been available at build time could have made this harder. The reasoning being that anything available and this potentially involved in the build should be human readable.
- Zuiii 3y ago> Anything available and this potentially involved in the build should be human readable. That's actually a good principle to adopt overall. We should treat this attack like an air plane accident and adopt new rules that mitigate the chances of it being successfully carried out again. We might not be able to vet every single person who contributes, but we should be able to easily separate out noisy test data.
- cgh 3y agoComment I saw on Ars: >Interestingly enough, "Jia Tan" is very close to 加蛋 in Mandarin, meaning "to add an egg". Unlikely to be a real name or a coincidence.
- picture 3y agoJia Tan could mean literally anything as pinyin since it doesn't have diacritics for tone. 嘉坛 (Jiā tán) could be a totally plausible name, and so could 佳檀 (also Jiā tán). Chinese names can largely use any character that doesn't come with a really bad meaning
- AnotherGoodName 3y agoYeah a quick Google brings up lots of real Jia Tans who clearly aren't behind this and hopefully aren't being wrongly accused here. But it is clearly a real and common name.
- shp0ngle 3y agoAs other poster said, Chinese has diacritics that got usually removed when put into English websites
- shp0ngle 3y agoThere are many real Jia Tans on LinkedIn
- xign 3y agoJia Tan is absolute a possible real name. Most people commenting on this topic aren't even Chinese native speakers lol. Each pinyin can map to a lot of different Chinese characters because they are missing the tone of the character anyway. Tan is a real Chinese surname, and could be mandarin or hokkien. Either way the name is likely made up. Obviously the attacker wasn't going to just use their real names.
- AlexanderTheGr8 3y agoIs there any progress on identifying the attacker? This would make it much easier to find out it this was really a state-sponsored attack. If this backdoor can be classified as a crime, github logs can identify the IP/location/other details of the attacker which is more than enough to identify them, unless their OPSEC is perfect, which it almost never is (e.g. Ross Ulbricht).
- bilekas 3y agoThis whole thing has been consuming me over the whole weekend. The mechanisms are interesting and a collection of great obfuscations, the social engineering is a story that’s shamefully all too familiar for open source maintainers. I find most interesting how they chose their attack vector of using BAD test data, it makes the rest of the steps incredibly easier when you have a good archive, manipulate it in a structured method (this should show on a graph of the binary pattern btw for future reference) then use it for a fuzzy bad data test. It’s great. The rest of the techniques are banal enough except the most brilliant move seems to be that they could add “patches” or even whole new back doors using the same pattern on a different test file. Without being noticed. Really really interesting, GitHub shouldn’t have hidden and removed the repo though. It’s not helpful at all to work through this whole drama. Edit: I don’t mean to say this is banal in any way, but once the payload was decided and achieved through a super clever idea, the rest was just great obfuscation.
- mondrian 3y agoA main culprit seems to be the addition of binary files to the repo, to be used as test inputs. Especially if these files are “binary garbage” to prove a test fails. Seems like an obvious place to hide malicious stuff.
- bilekas 3y agoIt is an obvious place for sure, but it also would have been picked up if the builds where a bit more transperant. That batch build script should have been questioned before approval.
- j16sdiz 3y agoBy whom? The attacker have assumed the maintainer role. Nobody is reviewing.
- NarcissistDev 3y agoThere’s a severe and dangerous lack of paranoia in this dev space. If I was letting someone maintain my codebase, I would 1 Billion percent be reviewing everything… if there was a binary added, I’d be building it myself and comparing the checksums. Trust absolutely no-one. If you can give a close friend or a loved one a loan of money and it is so easy for them to never pay you back, it should be a reminder that devs you’ve never met are even more likely to scam you.
- dxthrwy856 3y agoThe parallels in this one to the audacity event a couple years back are ridiculous. Cookie guy claimed that he got stabbed and that the federal police was involved in the case, which kind of hints that the events were connected to much bigger actors than just 4chan. At the time a lot of people thought its just Muse Group that's involved, but maybe it was a (Russian) state actor? Because before that he claimed that audacity had lots of telemetry/backdoors which were the reason he forked and removed in his first commits. Maybe audacity is backdoored after all? Have to check the audacity source code now.
- CommitSyn 3y agoCookie guy?
- cookiengineer 3y agoCareful, APT28 is pretty dangerous. They are merging their ops with APT29 these days, and I wouldn't wake the cozy bear if I were you.
- dxthrwy856 3y agoSo it was a state level actor that organized the doxxing campaign?
- cookiengineer 3y agoWell, I've pivoted to cyber defense for a reason. The executives are hopelessly overwhelmed with anything related to APTs. In their minds, criminals want money and if there's no money to follow, they can't do squat about it.
- EasyMark 3y agoThis whole thing makes me wonder if AI could detect "anomalies" like the human who found the actual hack did. Observe a system (lots of systems) and use that data to spot anomylous behavior from "new" versions of packages being added, throw up a red flag that is like "this really doesn't act like it did in the past because parameter(s) are unusual given previous versions"
- pixelfarmer 3y agoJust needs a fine grained enough set of parameters that are observed on a system, aka "monitoring", and flag anything that sticks out. No need for "AI" unless the parameters that are monitored have more of a (complex) pattern to them than some value +/- deviation or similar things. "AI" is, in an abstract way, a pattern matcher and replacer, but also a big cannon that is often not needed and simpler heuristics work faster and better (and are usually deterministic).
- lpapez 3y agoAnomaly, fraud, outlier detection... AI has been trying to solve that for several decades and in my experience in production these systems usually end up being a set of expert written rules saying "if X is greater than Y, notify someone to check".
- mjburgess 3y agoThe issue is that fraud is anti-inductive: when it's discovered, it changes. Statistical AI systems are just naive induction, and so largely useless.
- duckyoufan 3y agoSo many important points in dead and downvoted comments. Who the hell runs this site?
- otterley 3y agoI’d recommend upvoting and commenting on the important points and adding your own useful comments.
- deleted 3y ago[deleted]
- amberpow8 3y ago[dead]