Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

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.)

View on HN

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 finally did the trick.

EDIT: typos.

You're allowed to say that the 3rd party spam checker was mailinblack. If it wasn't, then I know from experience they would have reacted the same.

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.

> That's the IT sec version of placing your CV on their server to apply :)

Has this actually ever happened or been solicited? That’s an interesting thought experiment.

https://en.wikipedia.org/wiki/Calling_card_(crime)

https://en.wikipedia.org/wiki/Website_defacement

https://attrition.org/mirror/

https://www.zone-h.org/archive

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.

Do you have any other methods you can think of?

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.

So what do you suggest?

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.

DMARC only requires one of SPF or DKIM to pass. DKIM passing and SPF failing won't deter DMARC; the message will land in the inbox.

That is a common DMARC configuration but not the only one. The failure tolerance is configurable.

I don't believe this is true, the only knob to tune is for relaxed or strict alignment checks for DKIM and SPF.

How do you configure DMARC to require both of DKIM and SPF?

The RFC says:

https://datatracker.ietf.org/doc/html/rfc7489#section-4.2

   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.

It seems you are correct. I was confusing the configurable failure reporting option (fo) as a failure tolerance option.

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 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.

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.

Reply on news.ycombinator.com