SANS Stormcast Wednesday, April 23rd: More xorsearch Updates; DKIM Replay Attack; SSL.com Vulnerability Fixed

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9420.mp3

previous

More xorsearch Updates; DKIM Replay Attack; SSL.com Vulnerability Fixed

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Wednesday, April 23rd, 2025
 edition of the SANS Internet Storm Center's Stormcast. My name is
 Johannes Ullrich and today I'm recording from Jacksonville,
 Florida. And we got yet another diary by Didier about an
 improvement to XOR search. So the last improvement was the
 ability to use YARA rule, which of course also allows
 regular expressions. Now in this diary, Didier talks about
 how to use what he calls ad hoc YARA rules. Usual YARA
 rules are written in a file and they span multiple lines.
 But there are things that you often want to do in these YARA
 rules, like simple things, like look for a regular
 expression, look for a string. So what these ad hoc YARA
 rules are, these are YARA rules in command line
 arguments that are essentially sort of abbreviations. So
 instead of spelling out the entire YARA rule, you just
 tell it, I would like to use a regular expression. Here's the
 regular expression. I would like to use a static string
 and the like. And that'll make it easier to use these YARA
 rules. In particular, if you're sort of just searching
 around, it's not necessarily some YARA rules that you would
 like to, for example, maintain as a standard configuration
 file. And then some security news from a couple days ago
 that I haven't had a chance to cover yet. And it involves
 DKIM, the email anti-spam standard. So DKIM adds a
 cryptographic signature header. However, that
 cryptographic signature only covers select headers.
 Typically, the from, the subject, maybe the to header.
 This is what's abused here in this particular attack. The
 email being sent here claims to be a subpoena from law
 enforcement. But the email itself claims to be sent on
 behalf of Google. So what attackers are doing here,
 they're taking a legitimate security email from Google.
 And then they are adding the signature from this email,
 including some of the headers that are verified by that
 particular signature to their email. So to their email body.
 And this kind of replay of digital signatures, of course,
 is a common problem in cryptography in general.
 Usually, you add something like maybe a timestamp or a
 serial number or something like this. But in DKIM, this
 doesn't really work. Like the attacker could also just spoof
 the timestamp of the email, just sort of, you know,
 backdate it essentially. In my opinion, probably the best
 somewhat technical solution here is to vary the subject
 field. So not just make it security alert, but security
 alert for and then maybe the name of the recipient or
 something like this. In order to make it a little bit more
 difficult to spoof and easier for the victim to figure out
 what exactly is going on here. Interesting attack and
 definitely something to be aware of. That DKIM is really
 not meant to ultimately authenticate the email. It's
 really more meant as a spam fighting tool. And with that,
 its scope is somewhat limited. And it's not a replacement for
 S-MIME, PGP or some of the other signature methods that
 actually verify the entire email, including the body of
 the message. For all the details about this particular
 attack, see the great blog post by EasyDMark. They
 recreated the attack, including how the email was
 sent, how the headers were copied and all of those
 details. So pretty good work here. And sadly, certificate
 authorities continue to have a hard time figuring out who is
 in control of a particular domain and who should be
 allowed to request certificates for this domain.
 Azel.com uses a method that at first sounds relatively
 straightforward to implement and should be as secure as
 other methods. And that's where you just add a special
 record to a particular domain's zone that allows the
 set of authority to look up an email address authoritative
 for that particular domain. The problem is that due to
 some interesting, I should say, logic error at SSL.com,
 the server authority that had this problem, you were now not
 only considered responsible for the domain that you added
 the DNS record to, which is the original intent, but you
 were also able to request certificates for a domain that
 your email address was using. So if you authenticated an
 email address at a webmail provider, like, let's say,
 gmail.com, well, you were also able to request certificates
 for this particular webmail provider. This is certainly a
 big issue in particular since, of course, webmail providers
 themselves are sort of a target of these machine-in-the
 -middle attacks that would be enabled by these fake
 certificates. Apparently, SEL .com has gone over its logs
 and found something like 11 instances where certificates
 were issued using the faulty logic. Not clear if they were
 all malicious or just innocently in the sense that
 maybe someone used an email address at their own domain or
 another domain that they owned and then obtained a
 certificate for those domains. Well, and that's it for today.
 At least that's all I've got time for. Should I have
 covered a story that you thought may have been more
 interesting what I covered or more relevant? Well, let me
 know. And any feedback, as always, is welcome. Thanks and
 talk to you again tomorrow. Bye.