Coming up this week on Breaking Badness. Today we discuss: Can I Put a Bug In Your Ear?, Vulnerabilities Aren’t My Cup of IoT, and our fun new game, two truths and a lie.
Here are a few highlights from each article we discussed:
Can I Put a Bug In Your Ear?
- So IlluSIonOfChaos, along with many others, have had some particularly bad response times from Apple. They’ve waited over 120 days since reporting their bugs with no progress on processing the bounty. Understandably they’re looking to publish as soon as they can and collect the cash. For many bug bounty hunters it’s not just a side gig now but their actual main job so delays in payment, particularly for big bugs with big payouts, means a hit to their income. Though, that’s not necessarily Apple or anyone else’s problem, but still.
- All of the bugs they discovered deal with the leaking of private data to applications without having to request permissions. In this I can see how Apple may prioritize bugs coming in that are serious security issues dealing with RCEs or something first, but we don’t know what they have in the hopper and privacy violating bugs seem pretty huge. In this case these bugs, given Apple’s stance on privacy, have to be considered high severity. They can leak Apple ID, email, contacts database, wireless network information, and a whole host of other things.
- The earliest bugs they submitted back in March of 2021. They’ve since requested status updates a number of times from Apple with sometimes no response. This really shows how Apple operates as a company though. They tend to not collaborate well with outsiders, hold things close to their chest, and keep things quiet, not leaking a lot of data outside. I respect that actually since it develops this interesting internal culture that’s very focused inward on their products and services and not so much on outer contributions if that makes sense, but in this case they do need to be responding to people sooner if they don’t want to lose this gift of the security community coming to them with bugs instead of selling them elsewhere.
- I think bug bounty and security programs are fantastic. We need ways to get high profile bugs to manufacturers and developers that can then be rapidly fixed. The third party, gray market for high profile bugs is a massive problem for security.
- In terms of what makes bug bounty programs effective; good communication and high payments is really what it comes down to for these companies. If you pay well and interact quickly with bug bounty hunters they’re going to spend time poking at your platform and finding you bugs. Communication is key as well since as you know from your marketing experience Kelsey a lot can come from that positive public imaging. Congratulating researchers for finding a bug and being open about its implications can be hugely impactful.
- Bug bounty reflects an organization’s willingness to think securely about their products. I think a good way to spot companies that probably don’t have a full time security staff and team is to check for the ones without bug bounty programs. It’s a great litmus test for how seriously security is taken at an organization.
Vulnerabilities Aren’t My Cup of IoT
- Internet of THINGS. I’m pretty certain that all of our listeners know that much, but what is a little less obvious even within the community is what devices count as IoT. The kinds of things that are in the gray zone might be things like ATMs, where there’s a full on (usually Windows!) computer in them that runs a familiar operating system that you could connect to with a keyboard and mouse or a RAT. And in the industrial control space, people who are particularly close to those technologies – we’re talking about plant automation, programmable logic controllers and safety systems in oil, gas, electric, etc., – make a distinction between those devices and IOT. But in general, there’s agreement about what the main definition of IOT is – things like webcams, other home “security” and automation devices, pretty much anything called “smart,” medical devices, and other little gizmos that are computers but aren’t shaped like computers.
- As you can imagine, we need a way to talk to all of these devices, and to hand over control of them at a massive scale to evil actors (oh wait….). So NanoMQ, (which sort of stands for nano message queue) monitors IoT devices in real time, then acts as a “message broker” to deliver alerts that atypical activity has been detected. So as you might imagine, this tool and others like it are used to monitor medical devices (and the humans they’re attached to), as well as to monitor vehicle systems, city automation systems, stuff like that.
- As is so often true with these things, the vulnerability has to do with memory management. We’ve all heard of buffer overflows, and specific kinds like heap or stack overflows. All of those are where you get an undesigned condition in memory when something sent to the system differs from what’s expected. Specifically here, (quoting Zsolt Imre from Guardara, “when the MQTT packet length is tampered with and is lower than expected, a ‘memcpy’ operation receives a size value that makes the source buffer location point to or into an unallocated memory area,” and this crashes the system. Now, notice that I didn’t say that it allows RCE. An attacker exploiting this vulnerability can’t take over the system, so this is a type of denial of service rather than a hijacking.
- The good news is that the developer of NanoMQ has issued patches for this, so anyone using these devices needs to check with their vendor to acquire and install the patches. However, and this isn’t really mentioned in the articles I’ve seen about this, patching in the IoT world is complicated. For one thing, it’s not unheard of for patches to have unexpected and unintended negative consequences. When it comes to IoT devices, this can be dangerous, and also, you’re often looking at a very large scale – lots and lots of devices that need the update. I’m not saying there’s anything wrong with these patches for NanoMQ. I’m just saying that “patch immediately” is not without its complications. Some operators of automated equipment have policies where they only patch on a specific schedule, and that schedule can be as long as 6 or 12 months. (In a lot of cases that is for the sort-of-not-quite-IOT things like ICS devices).
- It’s on an upward trajectory when it comes to attacks related to the internet of things, on both sides of that equation. The more of these devices that get into circulation, the more vulnerabilities there are going to be, not necessarily because vendors are getting worse, but simply because of the volume. Kaspersky has some kind of insane numbers around this where they claim to have seen 1.5 BILLION attacks against IOT devices this year. I’ve got to think that what makes that number so huge is the number of targeted devices, rather than the number of efforts launched by attackers. Still, however you count it, there’s really no reason that criminals would not be picking up heavily on these devices as targets.
Two Truths and a Lie
Introducing our newest segment on Breaking Badness. We are going to play a game you are all likely familiar with called two truths and a lie, with a fun twist. Each week, one us with come prepared with three article titles, two of which are real, and one is, you guessed it, A LIE.
You’ll have to tune in to find out!
Current Scoreboard
This Week’s Hoodie/Goodie Scale
Can I Put a Bug In Your Ear?
[Chad]: 8/10 Hoodies
[Tim]: 7/10 Hoodies
Vulnerabilities Aren’t My Cup of IoT
[Chad]: 7/10 Hoodies
[Tim]: 5/10 Hoodies
That’s about all we have for this week, you can find us on Twitter @domaintools, all of the articles mentioned in our podcast will always be included on our podcast recap. Catch us Wednesdays at 9 AM Pacific time when we publish our next podcast and blog.
*A special thanks to John Roderick for our incredible podcast music!
