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.
