Navigating the Complexities of Development to Create Secure APIs – Kristen Bell – ASW #248

While the exploit scenario may be low risk, the effort and write-up for this exploit is highly informative. It also highlights how many libraries could benefit from further hardening to prevent them from being leveraged in an attack like this.

Here's a curious situation that emerged from a CTF. A participant identified and exploited a zero-day in Chromium. However, only later did a CTF organizer -- not the original researcher -- report the bug to the project and receive a $10K bounty for it. The situation is probably more notable for how onlookers interpret this example as a success or struggle for bug bounty programs.

A project shutting down because "we now find ourselves facing an escape so complicated that fixing it seems impossible."

Fortunately, there are more secure alternatives. It must be hard to close a project that's gone for so long, but it's commendable to know when risk can't be effectively addressed. I wonder how much security could be improved within organizations by getting rid of systems and code quickly rather than letting them linger in insecure states.

More consequences of IAM complexity and security researchers poking at cloud configurations.

Nothing too exciting or new in this list. What's curious is seeing overlaps and gaps with other lists we've covered on the show like the OWASP AI Security and Privacy Guide.

This is a bit older (from June), but I wanted to bring it up in relation to industry talk of SBOMs and supply chains. We need reliable information about packages or we may need scanners to just keeping inspecting packages rather than relying on what they say they contain.

It's great to see lists of recommended tools, especially open source ones that can help with cloud security. But...I'm not too excited about this list?

I'm curious how these in particular were chosen. Of course, your cloud security strategy should rely on security practices and frameworks, with tools assisting the implementation (and scaling) of that strategy. But this list feels a bit distant from good strategies. As a question for our listeners, what should a list contain that would be organized by cloud security posture, baselines, monitoring, and incident response?

p.s. yes, it's still funny and fun to see untitled goose tool make a list like this -- we've come a long way from tool names like SATAN.

I learned a lot of infosec by studying protocols -- TCP/IP, DNS, UDP, HTTP, and a few other more obscure or long-forgotten ones. So, this resource was sure to catch my eye.

This reference isn't for everyone. But if you're interested in reading about protocols and reasoning about potential flaws (aka threat modeling), this would make for a good time. Many of the implementations are also probably great targets for fuzzing and just waiting for more vulns to be identified. One drawback just being the potential difficulty of setting up or finding environments for testing. Considering that this summer's Black Hat promises to bring more BGP protocol issues to light, there's no reason to ignore the ones that show up on this list.

More efficient fuzzing in order to find more bugs -- security or otherwise!

Some researchers took a look at satellites and their firmware, and were left unimpressed. Part of what's interesting here is that the security through obscurity worked until recent years, where ground stations - the earth-part that talks to the satellite - have become financially accessible for individuals to purchase, or they can just rent them from AWS or Azure.

In this paper the researchers go over a variety of flaws found after re-creating firmware setups in their lab and doing some "experimental testing." Most of the work focused around smaller cube sats, which might be partially why there's more security issues (cheaper, smaller satellites may mean smaller security budgets)

(h/t Wired)

The FCC is working on the "US Cyber Trust Mark," which would allow consumers to have a better sense of the security of a "device" and "product"(eg device + cloud). I like the use of those two phrases, as frequently people seem to think about the security of an IOT thing without thinking about what it's connecting to.

For those in the hardware space, seeing the title here might make one first think of "Rigol," as the community is fond of hacking these devices, and that would be a correct guess in this case.

This has a neat walkthrough of how you get the firmware, emulate it, and work on finding a vulnerability (in the web interface, in this case).

(h/t hackaday)

Terrestrial Trunked Radio is a system used by "globally" by law enforcement, military, critical infrastructure. The security of this system was kept behind closed doors until some researchers recently got access. Along with finding a collection of vulnerabilities, they also found a backdoor in the system.