![this-week-in-security:-bitwarden,-reverse-rdp,-and-snake-[hackaday]](https://i0.wp.com/upmytech.com/wp-content/uploads/2024/01/161017-this-week-in-security-bitwarden-reverse-rdp-and-snake-hackaday.jpg?resize=800%2C445&ssl=1)
This Week in Security: Bitwarden, Reverse RDP, and Snake [Hackaday]
This week, we finally get the inside scoops on some old stories, starting with the Bitwarden Windows Hello problem from last year. You may remember, Bitwarden has an option to use Windows Hello as a vault unlock option. Unfortunately, the Windows credential API doesn’t actually encrypt credentials in a way that requires an additional Windows Hello verification to unlock. So a derived key gets stored to the credential manager, and can be retrieved through a simple API call. No additional biometrics needed. Even with the Bitwarden vault locked and application closed.
There’s another danger, that doesn’t even require access to the the logged-in machine. On a machine that is joined to a domain, Windows backs up those encryption keys to the Domain Controller. The encrypted vault itself is available on a domain machine over SMB by default. A compromised domain controller could snag a bitwarden vault without ever even running code on the target machine. The good news is that this particular problem with Bitwarden and Windows Hello is now fixed, and has been since version 2023.10.1.
Reverse RDP Exploitation
We normally think about the Remote Desktop Protocol as dangerous to expose to the internet. And it is. Don’t put your RDP service online. But reverse RDP is the idea that it might also be dangerous to connect an RDP client to a malicious server. And of course, multiple RDP implementations have this problem. There’s rdesktop, FreeRDP, and Microsoft’s own mstsc that all have vulnerabilities relating to reverse RDP.
The technical details here aren’t terribly interesting. It’s all variations on the theme of not properly checking remote data from the server, and hence either reading or writing past internal buffers. This results in various forms of information leaks and code executions problems. What’s interesting is the different responses to the findings, and then [Eyal Itkin]’s takeaway about how security researchers should approach vulnerability disclosure.
So first up, Microsoft dismissed a vulnerability as unworthy of servicing. And then proceeded to research it internally, and present it as a novel attack without properly attributing [Eyal] for the original find. rdesktop contained quite a few of these issues, but were able to fix the problem in a handful of months. FreeRDP fixed some issues right away, in what could be described as a whack-a-mole style process, but a patch was cooked up that would actually address the problem at a deeper level: changing an API value from the unsigned size_t to a signed ssize_t. That change took a whopping 2 years to actually make it out to the world in a release. Why so long?
Two reasons for that long time lag. First off, it was a hardening change, not a response to a single vulnerability. It would have prevented a bunch of them all at once, but wasn’t a required change to fix any of them individually. But even more importantly, this was an API change. It would break things. So, throw it into the major version branch and wait. And here’s where there’s a bit of a dilemma. Should a researcher blast the problem online, or wait patiently? There’s no single solid answer here, as every situation has its own complexities, but [Eyal] makes the case that security researchers ought to be more concerned with projects getting fixes applied, and not just content to score another CVE.
Crawl Networks with SSH-Snake
We just discovered this clever tool this week: SSH-Snake. The concept is simple. The script looks for any SSH private keys, then tries them on the list of known ssh hosts. For each host that accepts a key, the script runs again. It doesn’t drop any files on the filesystem, and runs automatically without intervention, compiling a nifty graph of accessible systems at the end. Definitely a worthwhile tool to keep in your digital toolbox.
Bits and Bytes
In an amusing turn of online play, Mandiant lost control of their X account for a while this week. It was a fun cat-and-mouse game as posts pushing crypto scams would appear, disappear, and appear again. One can only imagine the frantic work done behind the scenes as this played out. Hopefully we can share a Mandiant blogpost about this in a few weeks. And yes, there’s an XKCD about that.
As you likely noticed, yesterday, Mandiant lost control of this X account which had 2FA enabled. Currently, there are no indications of malicious activity beyond the impacted X account, which is back under our control. We’ll share our investigation findings once concluded.
— Mandiant (@Mandiant) January 4, 2024
If you still have a Lastpass account, you may have gotten emails this week about a master password requirement change in the works. The TL:DR is that Lastpass has previously “required” a 12 character password. Starting soon, all password will actually have to be 12 characters long, including those from older accounts. It’d probably be best to get out ahead of that change anyway, if you have a shorter password.
It does seem a bit tone-deaf, that 23andMe blames the victims for the recent account breaches there. “users used the same usernames and passwords used on 23andMe.com as on other websites that had been subject to prior security breaches, and users negligently recycled and failed to update their passwords following these past security incidents”. Except, that’s technically correct. Users really were re-using passwords. And users really did opt in to sharing details with their genetic matches. The only real failure was that nobody at 23andMe spotted the credential stuffing attack as it was happening, but that’s admittedly difficult to discern vs normal traffic. So probably an A- for the technical point. And a D for the delivery.