Cheesy Tomato Dreams – ASW #181
Full Audio
View Show IndexSegments
1. API Security (Shadow APIs) – Himanshu Dwivedi – ASW #181
It is hard, if not impossible, to secure something you don’t know exists. While security professionals spend countless hours on complex yet interesting issues that may be exploitable in the future, basic attacks are occurring every day against flaws in code that receives little review. For example, a “dated trend” by effective yet lazy hackers is to search for APIs unknown by security teams, coined “Shadow APIs”, then connect to these APIs and extract data. SQL Injection used to be the hack of choice, as a few simple SQL commands would either mean pay dirt or “move on to the next target”. Now the same can be said for Shadow API: Find, Connect, Extract. Himanshu will discuss one of many methods that are used in the wild to target Shadow APIs and export large volumes of data with a few clicks of a button or a few lines of code in Python.
Announcements
Don't forget to check out our library of on-demand webcasts & technical trainings at securityweekly.com/ondemand.
We're always looking for great guests for all of the Security Weekly shows! Submit your suggestions by visiting https://securityweekly.com/guests and completing the form!
Guest
![](https://image-optimizer.cyberriskalliance.com/unsafe/1920x0/https://files.scmagazine.com/wp-content/uploads/2022/05/himanshu-0-1.jpeg)
Himanshu Dwivedi is the CEO of Data Theorem, Inc., an application security company focusing on API Security (RESTful & GraphQL), mobile apps (iOS &Android), Cloud Apps (Serverless), and Single Page WebApps (SPAs). Himanshu has been an avid start-up entrepreneur since 1999, where he and 3 friends started the west coast office of @stake, an information security firm that was later acquired by Symantec. In 2004, Himanshu co-founded iSEC Partners, an application security company that was acquired by the NCC Group in 2010. Himanshu has several publications, including six different books (Mobile Application Security, Hacking VoIP, Hacking Exposed: Web 2.0, Hacker’s Challenge 3, Storage Security, and Implementing SSH) as well as the owner of one patent (Patent number 7849504). He has also presented at numerous conferences, including 6-time BlackHat speaker. Himanshu received a B.S. from the Carlson School of Management (University of Minnesota), where he was awarded the Tomato Can Loving Cup Award, which is given to the school’s top graduating student.
Hosts
2. IndexedDB Leak, Linux Kernel Bug, Zoom Security, SSRF & Allow Lists, Security Courses – ASW #181
In the AppSec News, Safari fixes a privacy leak in IndexedDB, integer arithmetic flaw leads to Linux kernel bug, a look back on Zoom security, SSRF from an URL allow list bypass, a security engineering course and lectures, 25 years of HTTP/1.1
Announcements
Don't miss any of your favorite Security Weekly content! Visit https://securityweekly.com/subscribe to subscribe to any of our podcast feeds and have all new episodes downloaded right to your phone! You can also join our mailing list, Discord server, and follow us on social media & our streaming platforms!
CRA's Business Intelligence Unit has launched its next survey on Zero Trust! What are Your Barriers to Zero Trust Implementation? Take our survey and enter to win a $500 Tango card by visiting https://securityweekly.com/zerotrust. Report results will be released at our upcoming Zero Trust E-Summit in March!
Hosts
- 1. Exploiting IndexedDB API information leaks in Safari 15Browsers perform more and more sensitive functions and are used to access more and more sensitive data. And while their internal security architectures continue to improve with process isolation and (eventual) adoption of memory-safe languages like Rust, they still rely on security models like the Same Origin Policy. Creators of web standards pay attention to the interaction of new features and the browser's origin, for both security and privacy reasons. But as we all know, secure designs don't always mean secure implementations. All that lead up is to say, here's an example of an inference attack against the IndexedDB API in Safari that would enable someone to obtain a user's identity information or correlate a user's identity information that might be stored within the IndexedDB. This kind of cross-origin behavior is exactly what the standards want to avoid. Additional resources - https://github.com/fingerprintjs/blog-indexeddb-safari-leaks-demo -- Example of an attack - https://github.com/WebKit/WebKit/commit/f73005ed826014988f8ee447de23927749fb56e5 -- The fix in WebKit (Safari's browsing engine)
- 2. Nasty Linux kernel bug found and fixedHere's the first Linux kernel bug we've covered this year. (It's only January; there'll be plenty more.) It's in code related to filesystem functions and can be leveraged into a local privilege escalation or container escape. One interesting aspect about the flaw is how the vulnerable code is at once so simple and so subtle. It's in a conditional statement that's doing integer arithmetic: if (len > PAGE_SIZE - 2 - size) With all the code review practices we have and all the integer sanitizers, compiler warnings, and SAST tools, this is still the kind of bug that gets past those solutions and doesn't get noticed for a while -- it looks like over two years in this case. It's also interesting that the fix is so simple; change the calculation to "size + len + 2 > PAGE_SIZE". Which from a style perspective also looks cleaner. I'd prefer to have all the arithmetic on the side with the variables and compare to the constant -- but that would have been purely a stylistic choice based on preference as opposed to insight into potentially vulnerable code. Unfortunately, we can't rely on luck to create secure code. Read the disclosure, which has links to the original insecure commit and the fix, at https://seclists.org/oss-sec/2022/q1/54
- 3. Zooming in on Zero-click ExploitsAnother great write up from Project Zero that looks back on vulns and vuln analysis in Zoom. It highlights a vuln in the Windows client revealed in 2021's Pwn2Own competition as well as referencing analysis with tools like AFL (for fuzzing) and Frida (for reverse engineering). Two items that stood out were (1) a lack of ASLR and (2) having to spend money in order to access and research some of the proprietary formats Zoom uses. The ASLR feels like a simple oversight and, fortunately, looks like it was easily addressed. The closed nature of the protocols in use is a more complex problem. Companies can innovate and choose their architectures, but doing so can impede security research.
- 4. Stealing administrative JWT’s through post auth SSRF (CVE-2021-22056)While the target of the vuln may not be too common, the nature of the vuln is worth reading about because URL composition and handling is very common. The SSRF in this case stems from how the app builds a URL and compares it against allow lists. An attacker can add a "@" symbol to the path, which turns the origin into an authority section and lets the attacker influence the origin with their own value inside the path itself. It's not a new attack -- we've seen plenty of examples over the years of payloads along the lines of https://[email protected]/rest of path" -- but that doesn't make it less useful or clever. This is a nice write up that shows how even security recommendations like using allow lists to protect against SSRF attacks required careful scrutiny to make sure they're implemented correctly. If there's a recurring theme in this episode's news, it's the unfortunate chasm between secure design and insecure implementation.
- 5. Security engineering courseLast year we touched on security-oriented courses at the college level with a few guests and a few of the news segments. It's an area we'd love to highlight more, so send us good examples you have of courses and content that we should share. This article is a small one, but it links to a useful book (Security Engineering) and two lectures (so far). If you're on the building or DevOps side of appsec or want to get into that discipline, check it out.
- 6. Secrets of Successful Security Programs – Part 1We're covering another article from Phil Venables this week (and likely will again since this is part 1 of a series). The article helps set strategic thinking for setting the vision and execution of a successful security program. A few items that speak directly to appsec are programs that address these areas: - Mitigates whole classes of attacks - Eliminates sets of pain - Reduces risk from configuration errors - Web Proxy Default Deny
- 7. Celebrating 20 Years of Trustworthy ComputingOne reason to look back on two decades of shifting towards more secure applications, aka trustworthy computing, is to examine what approaches seemed to work and which ones didn't. Microsoft put a lot of effort into developer eduction, added compiler options to harden binaries, and rearchitected software like IIS. If there are mixed results in the Windows ecosystem, it's helpful to try and understand if that's because solutions weren't adopted, couldn't be adopted because of compatibility reasons, or the solutions weren't effective. Another reason to look back is to give us a reference of where to look ahead. We've seen messy security throughout Android's lifetime, Chrome and Safari each have critical 0days every month or so, and cloud service providers have had their own security missteps and insecure defaults.
- 8. Hypertext Transfer Protocol — HTTP/1.1 (Looking at the spec 25 years later)The HTTP/1.1 spec came out in January 1997. Noting it here more as a curiosity and to mark the occasion. Although, if you're looking into fuzzers or in search of the next HTTP Request Smuggling style of flaw, going back to the protocol's standards and exploring its edge cases and assumptions can often lead to interesting discoveries. Maybe another appsec presentation is just waiting on someone to dive into a dusty corner that's been implemented for ages, but rarely used. Having specs on hand are also useful when you want to go through exhaustive header manipulation for payloads like the JNDI strings for log4j. They can also be fun to read in retrospect. Check out the "Security Considerations" section 15.6, which notes: "HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords, encryption keys, etc.), and SHOULD be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources. We very strongly recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers and implementers be particularly careful in this area. History shows that errors in this area are often both serious security and/or privacy problems, and often generate highly adverse publicity for the implementer's company." Indeed, even the spec describes why organizations must take security seriously. With luck, that phrase will be used more often in the design and implementation stages as opposed to the familiar opening to far too many breach notifications. The spec is further updated by https://datatracker.ietf.org/doc/html/rfc2616, which in turn has links to additional updates and errata.