I enjoyed the... I guess "narrative Q&A" style would be a good enough way to describe it? Regardless, it's fun.
> The security team at Seznam - a Czech search engine and email provider - did not believe me when I reported this issue. They assume that as they are not actively using that key (beta._domainkey.seznam.cz), that means that it cannot be used to forge emails. This is, of course, not true.
Maybe consult a lawyer first, but the entertaining answer would surely be to tell them about the problem in an email from their own domain? (Though seriously, double-check that that's not illegal; funny isn't worth getting arrested.)
Couple of years ago, I noticed some weird Outlook headers on our internal company e-mails and decided to take a look. It turned out our company Outlook (or Exchange? who knows) mail server was configured to relay mail through some 3rd-party SPAM filter and the SPAM filter trusted some headers which weren't stripped on ingress. So you could send an e-mail with the headers set and they would reach the SPAM filter unmodified. As the company had a 3rd-party SPAM filter, all Outlook security was disabled. This allowed me to send e-mail with forged sender. Outlook in its amazing brilliance would attach the "sender's" company photo and show some kind of a "Trusted" badge or something.
I reported the issue and the admins weren't impressed. They insisted that this wasn't a major problem since the only way to make the e-mail appear to come from somebody in the company was to use you company account (outside e-mail would be filtered correctly). After some back and forth, I just told the admin to check his mailbox. It said something like, "if you don't think this is serious, you're fired" and it was "from" the CEO, with his smiling photo next to the name.
That's the IT sec version of placing your CV on their server to apply :)
That being said, a company which is that lax with reported vulnerabilities is not likely to handle "fun" well and even if what you are doing is legal, being involved in a lawsuit is no fun and probably not worth it, since, in the end, you are trying to help them.
I did this, kind of. I was interviewing for a financial company that went to some effort to hide their location for operational security, met them at a local cafe where we talked about physical security, and then casually mentioned that I was staying at an airbnb across the road from their office and we could walk back together. It took a couple of calls to find someone who happily told me their registered address. They were creeped out but hired me anyway.
Wouldn't their registered address be public information? I understand that corporations may use agents/lawyers for that kind of thing, with layers of shell companies, but in theory this kind of info is able to be discovered and deduced from tax records, incorporation documents, and for publicly traded companies, SEC filings, etc.
Cool story! I'm glad you got the job! Anything else about your sleuthing you'd care to add? I'm intrigued.
A business needs a registered address, but it doesn't need to be the address of their main offices. It's quite common to have a registered address which is just a forwarding agency.
I guess you could mail a cellphone or AirTag to their registered address, then even if they find it and don’t forward it, you could follow the person(s) who fetch or deliver the mail to the company location.
You could maybe even skip the mailing step and just watch the registered address and trace the movements of everyone who visits that location.
Watching the location is a bad idea. I’d hazard a guess that most forwarding agencies have more than 1 customer, so you’ll be on a bunch of wild goose chases.
Also forwarding agencies probably don’t visit the clients locations often.
While you can forge the DKIM signature there is a good chance there is also SPF configured. SPF tells which servers are allowed to send mail for the domain. So your email would likely still end up in the spam folder.
It turns out there is a bit of an exception to this, which is that plain SPF only applies to the envelope from address, not the From: field, and failure of plain SPF is sometimes (I don't know how often) considered independently from DMARC.
oh wow, didn't know that. That's actually pretty bad. Why on earth was it designed in such a way that didn't require both tests to pass if both of them are configured.
Because SPF has many design flaws that will break SPF for legitimate use-cases (such as relaying/forwarding). You wouldn't want to rely on SPF, you should always on DKIM instead.
SPF should be considered legacy at this point. But of course DMARC had to be designed with backwards compatibility in mind, thus it'll still consider the email to be DMARC alignment with just SPF alignment (without DKIM alignment). Also, understand that 'alignment' is different from a 'pass', so it's not as bad as many commenters here make it look.
There are proposals of adding a flag to the DMARC policy to have the receiver ignore SPF alignment, thus enforcing DKIM alignment. However, that is not final yet.
Because both of them rely on DNS. DKIM is trivial to bypass if you can create a TXT record with your own key, and SPF is trivial to bypass if you can create a TXT record containing an SPF record with your own IP address / hostname / whatever. Presumably if you can compromise one of them, you can compromise both.
> DKIM is trivial to bypass if you can create a TXT record with your own key
This is exactly what DMARC prevents. With DMARC the alignment requirement is added, so signing an email with a different domain key will no longer work.
For a DMARC pass you need DKIM alignment. DKIM alignment means that the email is correctly signed with a DKIM key that is published under the sender (rfc5322.From) domain.
Yes, and if you can get modification access to the TXT records for the sender's domain, you can compromise both DKIM and SPF. That's my point. Edit: More specifically, that it doesn't make sense to force both of them to pass when they both share a single point of failure.
If your DNS is compromised it's game over anyway, because then everything is compromised. DNS is a single point of failure. You'll also be able to reroute inbound email, MITM HTTP traffic, order rogue TLS certificates, etc. etc.
Saying DKIM is flawed because you can create rogue keys with DNS access is the same as saying the entire PKI is flawed because you can order certificates using DNS-01 verification.
I didn't say DKIM was flawed. I wasn't complaining about DKIM at all. You may want to re-read the comment I was replying to. I'm well aware of the consequences of a DNS compromise.
I simply said, twice, that DMARC forcing both SPF and DKIM to align and pass doesn't add anything of value; if you are capable of subverting one of them, you are almost certainly capable of subverting both of them at the same time.
A message satisfies the DMARC checks if at least one of the supported
authentication mechanisms:
1. produces a "pass" result, and
2. produces that result based on an identifier that is in alignment,
as defined in Section 3.
I love this case, because every time someone cites it as a reason packagers shouldn't patch upstream software I get to point out that they had to go back over a decade to find an example of it going bad. Soon it's going to be two decades.
That was one factor of multiple, and the malicious actor chose to exploit it that way. liblzma is in enough critical stuff that they could have chosen to exploit something different had it not been for that.
You're confused there. The xz backdoor made use of a Debian OpenSSH patch, but it wasn't "caused" by it. Without the patch, the malicious xz maintainer could have written a different backdoor without making use of the OpenSSH patch -- for example, since debian packages are compressed with xz, the backdoor could have modified the sshd binary while unpacking the next OpenSSH security update.
That would have been slower (attacker might have needed to wait a long time for a security update), and more discoverable since the modified file would be persisted to disk; but it also wouldn't have caused the performance issues that ended up in the discovery of the backdoor.
It would be discoverable but only if you ran an additional hash to check the final binary after updating and checking with an out of band source what the hash of the binary should be.
How many people double check that apt actually updated the package to the right version, if it’s output is compromised?
this is such a spin! that bug was two years worth of James Bond-level insertions into a situation that "was caused" by systemd ! if you want to get creative in the rewriting of fact
This isn't about systemd. OpenSSH is one of the most (if not the most) security-critical program in the distribution. Many systems run with just ssh enabled. That's why you don't mess with it.
Which library pulled the vulnerability in is mostly irrelevant.
You'd think it woukd work fine, after all, init systems for half a century have worked fine without it.
But no. Newer versions of systemd have issues, and this was what systemd pushed. Just why do you think all these distros had the sane patch? For fun?
Arch would have ended up with it eventually. It wasn't Arch being prescient, Arch wasn't using the same systend version as Debian Unstable, and other distros bleeding edge branches.
Do you really think there was no other avenue? There are tons and tons of things that link against liblzma, including stuff that commonly gets run as root such as apt, udev, and grub.
_sigh_ the backdoor was found because Debian also made those patches. Nearly all major distros were affected. The reason why Debian made the news is because the researcher who found the issue was using Debian. Had he been using Ubuntu, Arch, Fedora... those would have been in the news instead.
According to Arch: "openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. Arch does not directly link openssh to liblzma", so at least one of your examples is wrong. That specific vulnerability was not in Arch.
The xz package was potentially vulnerable (although not in reality because "the build script was configured to only inject the bad code in Debian/Fedora based package build environments", while this was a choice by the attacker, it's still true the vulnerability wasn't there), but patching OpenSSH made OpenSSH specifically vulnerable when used with a malicious xz install.
Right... I may have wrongly named Arch in my comment. Thanks for the correction.
I'm curious about Arch's claim that "the build script was configured to only inject the bad code in Debian/Fedora based package build environments". Were Debian and Fedora specifically targetted, and the other distros who also got affected just happened to use similar packaging routines, or is this claim a guess?
The malicious build script included heuristics to only include the backdoor if you were building a .deb or .rpm package (the Debian and Fedora formats respectively). Other distros would have been affected if they used the same packaging setup -- Ubuntu also uses .deb, for example, because it's based on Debian.
And some distros IIRC considered themselves "affected" if they ever used a malicious version of the code, just in case, even if the backdoor didn't actually get compiled in to their version.
Does this happen for official packages or just the AUR? I was pretty sure that when possible they build the packages from source themselves rather than bundling pre-existing binaries, and I'd assume that they wouldn't likely have the sources in the final package. IIRC Debian doesn't even like to bundle the headers in with libraries in preference of splitting them off into a separate file, so I'd be kind of shocked if they put the entire source of each library in the .deb files they distribute.
Arch package maintainer here; we generally encourage building from source for packages provided by the official repositories. As far as I know, we only ship pre compiled binaries if there is no source available, i.e. commercial programs such as reaper.
>"openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. Arch does not directly link openssh to liblzma", so at least one of your examples is wrong. That specific vulnerability was not in Arch.
This is such a weird formulation though, because "other distributions" apparently included insignificant parts of the linux landscape like Fedora (i.e. the testing variant of the RedHat world) and SUSE.
And if the three largest upstream distris in the linux world have this mistake, calling that "Well some distris, but screw mostly Debian" doesn't sound like a strong point.
Every day, Ted Unangst is vindicated more and more[1] for his work forking OpenSSL.
If you do a little digging, you'll see that there was no real technical reason why your distro of choice has abandoned implementing LibreSSL[2][3], or just never implemented it at all[4]. They just somehow wanted to keep using the faulty software with exploit mitigation countermeasures[5][6]. Totally organic.
PyPI has only implemented the "server signs whatever's uploaded with that account" part of TUF; there are no Publisher Signatures for packages uploaded to pypi (because GPG ASC support was removed from PyPI, the ad-hoc signature support was removed from wheel, and only server signatures are yet implemented).
https://SLSA.dev/ recommends TUF and Sigstore.dev and trusted containers for build-signing.
Someday, Twine should prompt a PyPI package uploader to sign the package before uploading it, and download it to (prime the CDN cache and) check the Publisher and Package repo signature(s) at least once.
PyPI doesn’t currently implement any part of TUF in a public facing manner, so I’m not sure where you got that from :-). There’s some limited deployment experiments with rstuf, but these are not part of any current server-side package signing scheme.
PEP 740 does the rest of what you’ve described, however. And twine already has initial support for it, although it isn’t part of a release yet.
for those interested in deploying BIMI, I wrote this HOWTO.
> If the complexity of using BIMI exceeds your desire, you must at a minimum provide for one BIMI DNS TXT record that tells everyone that your BIMI is “disabled” … just to prevent others from impersonating you.
> The TXT record for a properly disabled BIMI must look like this:
> That's why you don't change upstream code without reason.
They did have a reason; they were running analysis on the code, and one of their tools specifically called openssl out for using uninitialized memory, which is absolutely a red flag. But not to worry; rather than blindly patching it to fix the bug, they went out of their way to go ask upstream about it, appeared to get a favorable response to their patch, and then went ahead.
This is why you don't change any code without understanding.
Is it broken? no? then don't fix it! I find it super hard to believe this wasn't the very first supply chain attack discovery. (If anyone knows of a verified early one, I'd love to be corrected!)
If it were a supply chain attack, I find it hard to believe that a) it would have originated from Debian at all, and b) that the people making the patch would have posted to the openssl-dev mailing list to ask their opinion on the correctness of the patch before including/shipping it.
https://news.ycombinator.com/item?id=40320166
To soon?
(Note I run Debian all over the place, and am generally happy with it.)