This Week In Security: Project Zero’s IPhone, BBC The Onion, Rooting Androids, And More

November 1, 2019 by Jonathan Bennett 11 Comments

The always interesting Project Zero has a pair of stories revolving around security research itself. The first, from this week, is all about one man’s quest to build a debug iPhone for research. [Brandon Azad] wanted iOS debugging features like single-stepping, turning off certain mitigations, and using the LLDB debugger. While Apple makes debug iPhones, those are rare devices and apparently difficult to get access to.

[Brandon] started looking at the iBoot bootloader, but quickly turned his attention to the debugging facilities baked into the Arm chipset. Between the available XNU source and public Arm documentation, he managed to find and access the CoreSight debug registers, giving him single-step control over a core at a time. By triggering a core halt and then interrupting that core during reset, he was able to disable the code execution protections, giving him essentially everything he was looking for. Accessing this debug interface still requires a kernel level vulnerability, so don’t worry about this research being used maliciously.

The second Google Zero story that caught my eye was published earlier in the month, and is all about finding useful information in unexpected places. Namely, finding debugging symbols in old versions of Adobe Reader. Trying to understand what’s happening under the hood of a running application is challenging when all you have is a decompiler output. Adobe doesn’t ship debug builds of Reader, and has never shipped debug information on Windows. Reader has been around for a long time, and has supported quite a few architectures over the years, and surprisingly quite a few debug builds have been shipped as a result.

How useful could ancient debugging data be? Keep in mind that Adobe changes as little as possible between releases. Some code paradigms, like enums, tend to be rather static as well. Additional elements might be added to the end of the enum, but the existing values are unlikely to change. [Mateusz Jurczyk], the article’s author, then walks us through an example of how to take that data and apply it to figuring out what’s going on with a crash. Continue reading “This Week In Security: Project Zero’s IPhone, BBC The Onion, Rooting Androids, And More” →

Be Anyone Or Anything With Facial Projection Mask

October 31, 2019 by Dan Maloney 18 Comments

In the market for a low-poly change to your look? Hate the idea of showing up for a costume party only to find out someone is wearing the same mask as you? Then this face changing front-projection mask may be just the thing for you.

To be honest, we’re not sure just how much [Sean Hodgins]’ latest project has to do with cosplay. He seems to be making a subtle commentary about dealing with life in the surveillance state, even though this is probably not a strategy for thwarting facial-recognition cameras. [Ed Note: Or maybe it’s just Halloween?]

The build consists of a Raspberry Pi and a pico projector of the kind we’ve seen before. These are mated together via a custom PCB and live inside a small enclosure that’s attached to the end of a longish boom. The boom attaches to the chin of 3D-printed mask, which in turn is connected to the suspension system of a welding helmet. Powered by a battery pack and controlled by a smartphone app, the projector throws whatever you want onto the mask – videos, effects, even images of other people. Even with some Photoshop tweaks to account for keystone distortion from the low angle of projection, there’s enough distortion that the effect is more artistic than masquerade. But honestly, having your face suddenly burst into flames is pretty cool. We just wonder what visibility is like for the wearer with a bright LED blasting into your eyes.

As a bonus, [Sean] has worked this build into a virtual treasure hunt. Check out 13thkey.com and see what you can make from the minimal clues there.

Continue reading “Be Anyone Or Anything With Facial Projection Mask” →

The Young Engineers Guide To Career Planning

October 28, 2019 by Lewin Day 41 Comments

It’s often said that engineers aren’t born, they’re made. Or more accurately, taught, tested, and accredited by universities. If you’re in high school, you’re probably starting to think about potential career paths and may be considering an engineering degree. A lot of work goes into a good college application, and it might seem like the hardest part is getting in. However, if your end goal is to get yourself a great engineering job at the end of your studies, it pays to have your head up from day 1!

I Just Need A Degree, Right?

Back in my freshman days, there was a saying that was popular on campus, particularly with those studying STEM topics. “Ps get degrees.” Your college’s grading system might use different letters, but the basic gist was that a pass mark was all that was required to get your piece of paper at the end of your four years. While this is technically true, it’s only really a useful ethos if your aim is to simply get a degree. If your goal is to use that degree to score yourself a plum job in your field, it would be unwise to follow this credo.

This attitude will net you plenty of wonderful memories at the bar, but it will dent your chances of landing a solid job upon graduation. All in moderation!

The reality of the modern job market is that it’s highly competitive. Recruiters can receive hundreds of applications for a single job, meaning the vast majority of applicants don’t even make it to the interview stage. To trim down the pile, various criteria are used to pick out the ideal candidates. An easy way to do this is to sort by grades. Having a low GPA can therefore see your application relegated to the trashcan, before you even get a chance to impress anyone with your carefully honed skills. Continue reading “The Young Engineers Guide To Career Planning” →

DNS-over-HTTPS Is The Wrong Partial Solution

October 21, 2019 by Maya Posch 51 Comments

Openness has been one of the defining characteristics of the Internet for as long as it has existed, with much of the traffic today still passed without any form of encryption. Most requests for HTML pages and associated content are in plain text, and the responses are returned in the same way, even though HTTPS has been around since 1994.

But sometimes there’s a need for security and/or privacy. While the encryption of internet traffic has become more widespread for online banking, shopping, the privacy-preserving aspect of many internet protocols hasn’t kept pace. In particular, when you look up a website’s IP address by hostname, the DNS request is almost always transmitted in plain text, allowing all the computers and ISPs along the way to determine what website you were browsing, even if you use HTTPS once the connection is made.

The idea of also encrypting DNS requests isn’t exactly new, with the first attempts starting in the early 2000s, in the form of DNSCrypt, DNS over TLS (DoT), and others. Mozilla, Google, and a few other large internet companies are pushing a new method to encrypt DNS requests: DNS over HTTPS (DoH).

DoH not only encrypts the DNS request, but it also serves it to a “normal” web server rather than a DNS server, making the DNS request traffic essentially indistinguishable from normal HTTPS. This is a double-edged sword. While it protects the DNS request itself, just as DNSCrypt or DoT do, it also makes it impossible for the folks in charge of security at large firms to monitor DNS spoofing and it moves the responsibility for a critical networking function from the operating system into an application. It also doesn’t do anything to hide the IP address of the website that you just looked up — you still go to visit it, after all.

And in comparison to DoT, DoH centralizes information about your browsing in a few companies: at the moment Cloudflare, who says they will throw your data away within 24 hours, and Google, who seems intent on retaining and monetizing every detail about everything you’ve ever thought about doing.

DNS and privacy are important topics, so we’re going to dig into the details here. Continue reading “DNS-over-HTTPS Is The Wrong Partial Solution” →

The Arduino IDE Finally Grows Up

October 21, 2019 by Al Williams 105 Comments

While the Arduino has a very vocal fan club, there are always a few people less than thrilled with the ubiquitous ecosystem. While fans may just dismiss it as sour grapes, there are a few legitimate complaints you can fairly level at the stock setup. To address at least some of those concerns, Arduino is rolling out the Arduino Pro IDE and while it doesn’t completely address every shortcoming, it is worth a look and may grow to quiet down some of the other criticisms, given time.

For the record, we think the most meaningful critiques fall into three categories: 1) the primitive development environment, 2) the convoluted build system, and 3) the lack of debugging. Of course, there are third party answers for all of these problems, but now the Pro IDE at least answers the first one. As far as we can tell, the IDE hides the build process just like the original IDE. Debugging, though, will have to wait for a later build.

Continue reading “The Arduino IDE Finally Grows Up” →

Revisiting The BlackHat Hack: How A Security Conference Was Pwned

October 18, 2019 by Sharon Lin 1 Comment

Does anyone remember the Black Hat BCard hack in 2018? This hack has been documented extensively, most notoriously by [NinjaStyle] in his original blog post revealing the circumstances around discovering the vulnerability. The breach ended up revealing the names, email addresses, phone numbers, and personal details of every single conference attendee – an embarrassing leak from one of the world’s largest cybersecurity conferences.

To recap: The Black Hat conference badges included an embedded NFC tag storing the participant’s contact details presumably for vendors to scan for marketing purposes. After scanning the tag, [NinjaStyle] realized that his name was readily available, but not his email address and other information. Instead, the NFC reader pointed to the BCard app – an application created for reading business cards.

[NinjaStyle] decompiled the APK for the app to search for API endpoints and found that the participants each had a custom URL made using event identification values. After finding data that appeared to correspond to an eventID and badgeID, he sent a request over a web browser and found that his attendee data was returned completely unauthenticated. With this knowledge, it was possible to brute-force the contact details for every Black Hat attendee (the range of valid IDs was between 100000-999999, and there were about 18,000 attendees). Using Burp Suite, the task would take about six hours.

He was able to get ahold of BCard to reveal the vulnerability, which was fixed in less than a day by disabling the leaky API from their legacy system. Even so, legacy APIs in conference apps aren’t an uncommon occurrence – the 2018 RSA Conference (another cybersecurity conference) also suffered from an unprotected app that allowed 114 attendee records to be accessed without permission.

With the widespread publicity of leaked attendee data, event organizers are hopefully getting smarter about the apps that they use, especially if they come from a third-party vendor. [Yashvier Kosaraju] gave a talk at TROOPERS19 about pen testing several large vendors and discovering that Kitapps (Attendify) and Eventmobi both built apps with unauthenticated access to attendee data. It’s hard to say how many apps from previous years are still around, or whether or not the next event app you use will come with authentication – just remember to stay vigilant and to not give too much of your personal data away.

Replacing The 3D Printer And Router: A Tool For Manufacturing Human-Scale Forms

October 18, 2019 by Sharon Lin 27 Comments

The purpose of Geometer becomes apparent when you realize its simplicity: [David Troetschel]’s project is to create an easily understandable design tool that encourages goal-oriented design. The kit comes with physical components and digital counterparts that can be combined in a modular way. They each have a specific geometry, which provide versatility while keeping manufacturing simple.

For the prototyping phase, small snap-on parts 3D printed on a Formlabs printer mimic the module components on a smaller scale. Once a design is conceived and the Geometer Grasshopper program finalizes the module arrangement necessary for the model, the larger pieces can be used as a mold for a concrete or hydrocal mold casting.

The present set of modules is in its seventh iteration, initially beginning as a senior thesis for [Troetschel]. Since then, the project itself has had an extensive prototyping phase in which the components have gone from being injection-molded to 3D printed.

The overall process for prototyping is faster than 3D printing and more cost-effective than sending to a third-party shop to build, which adds to the project’s goal of making manufacturing design more accessible. This is an interesting initiative to introduce a new way of making to the DIY community, and we’re curious to see this idea take off in makerspaces.