Podcast Detail

SANS Stormcast Thursday, June 4th, 2026: swagger.json Scans; Android Fake Call Detection; Anthropic Dashboard

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/9958.mp3

previous
Podcast Logo
swagger.json Scans; Android Fake Call Detection; Anthropic Dashboard
00:00

My Next Class

Click HERE to learn more about classes Johannes is teaching for SANS

Podcast Transcript

 Hello and welcome to the Thursday, June 4th, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. This episode is brought to you by
 the SANS.edu undergraduate certificate program in
 Cybersecurity Fundamentals. Today's diary is nothing earth
 -shattering new, but I noticed that we still get a ton of
 requests with a somewhat sort of increasing tendency for
 swagger.json. Swagger.json is a file that defines REST web
 services using the Swagger open API standard. This is
 usually sort of reconnaissance. They either
 look for what particular API functionality is supported,
 but also often what type of API it is. If it's some kind
 of standard package or so that can be identified via the
 swagger.json metadata, which often includes something like
 a name of the particular API. So that can then be used to,
 for example, look for vulnerable APIs. Swagger.json
 is certainly something that you should keep installed if
 the API is intended to be sort of for public consumption. On
 the other hand, well, it's I think something where you
 should really stay ahead of the attackers here and should
 proactively scan sort of your internal API attack surface to
 figure out if there's anything that's outdated that's not
 supposed to be there or just not supposed to be public. And
 Google published an interesting blog post how
 they're going to roll out a new type of caller ID
 verification. Now spoof caller ID is nothing new, has been
 done for decades probably now, but it has become more and
 more of a problem because of course AI is now being used to
 accurately impersonate the voice and in some cases even
 sort of the face and video calls. So what Google is doing
 here is Google is actually taking advantage of RCS. So
 RCS that's the new SMS standard that actually
 supports digitally signed and encrypted messages. What
 happens is if you're receiving a call from someone, then RCS
 is being used to essentially ping the device that is
 calling you and verify that this device is actually
 currently on a call. At least out of, that's how it's
 described on in the blog post here. This is an Android only
 feature. Actually, it's a phone by Google only feature.
 So this only works if you're using Google's built-in phone
 app in Android. They're rolling it out for newer
 Android devices and pixel only first and are sort of having a
 staggered rollout of the feature to other Android
 devices as well. A couple of questions I have, not quite
 really answered here, is does it really only check for
 example if the other phone is actually in a call because an
 attacker could easily well call the person they're
 claiming to call from and after that person answers
 their phone they're calling you and then of course your
 phone sees that the other person is on a call. Doesn't
 necessarily mean that they're on a call with you. So that's
 not really clear yet also well what's the privacy implication
 of this. Can anybody basically ping your phone and check if
 you're currently on a call or not. I doubt it and that's
 sort of maybe where the digital signatures and such
 come in with RCS but yes that's not really explained
 there. Sounds like a cool feature. Telecom operators of
 course have tried to sort of do some verified caller ID in
 the past and as far as I can tell that hasn't really sort
 of fully taken off yet. The other issue of course is
 interoperability. If something like this would also work like
 you know across let's say iOS and Android with iOS now also
 supporting at least part of the RCS standard. So maybe
 they're doing something similar in the future
 hopefully interoperable with Android. And Anthropic has of
 course made big news in recent weeks with its bug discoveries
 or vulnerability discoveries. In order to further highlight
 this Anthropic now came up with a dashboard showing how
 many vulnerabilities they found and well in what status
 of remediation. And they are pretty interesting kind of the
 overall numbers here. 1600 overall disclosed
 vulnerabilities. Only 27 fixed which I think sort of shows
 one of the big problems that many people have talked about.
 And these are vulnerabilities fixed in the actual
 distribution. So in the library or such. So this
 doesn't mean they're fixed with the end user. And that's
 of course probably a similar ratio I would almost be afraid
 of between what's fixed by the vendor and what's then
 actually fixed by the end user. So we'll see how this
 all develops but nice to sort of keep an eye on it. Not a
 lot of details of course for vulnerabilities that have not
 been made public yet. Disclosed here means disclosed
 to the vendor, not disclosed to the public necessarily. And
 then we have a denial of service vulnerability in many
 popular HP2 implementations. This is a classic compression
 bomb issue where you have a fairly small compressed piece
 of data that once decompressed actually expanded into
 gigabytes of data. In this particular case one client can
 easily fill 32 gigabytes of RAM exploiting this
 vulnerability. The compression algorithm in HP2 is called
 HPC. It's the header packing. So the headers are being
 compressed here in HP2 and that algorithm is affected by
 this vulnerability. The author of the blog post states that
 they were actually part of the review of the original
 specification but well missed this particular vulnerability.
 Well and this is it for today so thanks for listening,
 thanks for linking, thanks for recommending this podcast. As
 always I do have some links to classes I'll be teaching at
 SANSFIRE in DC in July. So thanks and talk to you again
 tomorrow. Bye. you