Hello and welcome to the Tuesday, May 27th, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich and this episode brought to you by
the SANS.edu Master's Degree Program in Information
Security Engineering is recorded in Jacksonville,
Florida. Well, today's diary was a little bit inspired by a
YouTube comment stating that, well, you have problems doing
steganography in a lot of these sort of pixel bitmap
based image formats because they're often then compressed.
And as a result, some of the detail is lost that you're
usually after when you're doing steganography. So, for
example, in particular with formats like JPEG, for
example, you have various compression levels and
sometimes even on download, for example, mobile ISPs
famously often do that, where they, if they're able to
intercept a bit stream, are then able to further compress
images, losing some of the detail. An alternative to
these bitmap based formats is SVG. Now, SVG as an image
format is very popular on the web, on our website. For
example, a lot of the icons use SVG because SVG is an XML
based format and easily embedded as part of HTML. And
being vector based, of course, usually no compression
happens. And also they nicely scale with the size of the
image. And what you can do with SVG is not just create
little icons and line based drawings, but you can convert
some of the bitmap based images to SVG. And what you
end up with then is basically areas in the image that have a
certain color. And that color can then be adjusted just the
same way that has been done with pixel based images. Well,
that's sort of what's at least calmly done these days with
SVG, where the colors are just slightly shifted. Basically
the same algorithm that is being used for pixel based
images, but with vector based images, you actually have
additional options. So, for example, if you do have a
particular line in the image, you could split that line into
two. And as long as these two lines line up with each other,
well, there is no real visible change to the image. And then,
for example, you could encode values in the ratio between
these two parts of the line. Since the coordinates here are
float, they're not integer. Remember, we are not dealing
with pixels here with these images, but more with
distances and such. And everything is supposed to be
easily scalable. So, in that case, we can actually, even
for a short line, still sort of have the full float outer
space here in order to encode data in this line. The image
would become larger. And, of course, the one attractive
part of SVG is that for little line drawings, they're very
compact. But certainly something that wouldn't
necessarily be noticed unless you specifically look for it.
And a recipient or someone who is decoding the image doesn't
even need a special key or so that you often need in order
to decode some of the more traditional steganography
methods. Of course, you could still add something like this.
But I would rather recommend, if you actually want some form
of encryption, just encrypt the data before you encode it
in the image. So, just something a little bit to play
with. As I mentioned in Diary, I may actually publish a
little proof-of-concept tool implementing this kind of
steganography later in the week. But it depends on what
else is coming up. And about a week ago, on May 13th,
Fortinet published an update for a number of its products
fixing an already exploited buffer overflow vulnerability.
This particular vulnerability does allow full access to the
system remote code execution without the need to
authenticate. Well, we now got a write-up from Horizon3.ai
telling us a little bit more about how this particular
vulnerability works and how to write an exploit for it. The
problem here, turns out, is related to the authentication
cookie. It's an ASP cookie, or APS cookie. That's what they
call it here. And this particular cookie, when it's
decrypted, then, well, the buffer overflow may be
triggered. Also interesting, they're not just sort of
walking us through how this particular cookie works, but
also through how they use the GitHub Copilot with Chihitra
in order to actually find the vulnerability and then being
able to exploit it. And we got an interesting new attack
against, well, AI code assistants. Of course, there
have been a number of similar papers, blog posts, and attack
proposals. This one comes from Legit Security and I think is,
well, pretty legit, but also a little bit new and interesting
in the way it works. It particular targets the GitLab
Duo AI assistant. Now, the basic problem here is that as
part of your source code, you may add comments that are then
directed at GitLab Duo. And they essentially, well, are
commands that you want GitLab Duo to execute or, well,
that's basically here where the prompt injection happens.
This will now modify how a victim who is, for example,
approving a pull request or so, views the code. These can
be encoded using Unicode and such to make them invisible.
One trick they, for example, demonstrated is where you tell
a GitLab Duo to include a link and then entice the user into
clicking on the link by giving it an unsuspecting label. Like
that, you find more details about the pull request, this
particular URL. But the URL itself, for example, may then
include source code or secrets that GitLab has access to.
Interesting attack and, yep, yet something else to be aware
of if you're using these type of assistants. Well, that's it
for today. Thanks for listening. There was no
podcast on Monday because it was Memorial Day here in the U
.S. Forgot to announce that on Friday, so sorry for that.
And, well, talk to you again tomorrow. Bye.
