Ask Hackaday: Why Did Modular Smart Phones Fail?

Remember all the talk about modular smart phones? They sounded amazing! instead of upgrading your phone you would just upgrade the parts a bit like a computer but more simplistic. Well it seems modular phones are dead (video, embedded below) even after a lot of major phone manufacturers were jumping on the bandwagon. Even Google got on-board with Google Ara which was subsequently cancelled. LG released the G5 but it didn’t fare too well. The Moto Z from Motorola seemed to suffer from the same lack of interest. The buzz was there when the concept of these modular phones was announced, and people were genuinely exited about the possibilities. What went wrong?

For a start people expect their phones to have everything on board already, whether it be cameras, GPS, WiFi, high-capacity batteries or high-resolution screens. Consumers expect these things to come as standard. Why would they go out and buy a module when other phones on the market already have these things?

Sure you could get some weird and wonderful modules like extra loud speakers or perhaps a projector, but the demand for these items was small. And because these extras are already available as separate accessories not locked down to one device, it was a non starter from the beginning.

When we did our user studies. What we found is that most users don’t care about modularizing the core functions. They expect them all to be there, to always work and to be consistent. — Lead engineer Project Ara

The hackability of these phones would have been interesting to say the least, had they come to the mainstream. It just seems the public want thin sleek aluminum phones that they treat more as a status symbol than anything else. Modular phones have to be more bulky to accommodate the power/data rails and magnets for the modules, so they’ll lose out in pocketability. Still, we hope the idea is revisited in the future and not left on the scrap-heap of obsolescence.

Would you buy a modular smart phone? Even if it is bigger or more expensive? Is that really why they failed?
Continue reading “Ask Hackaday: Why Did Modular Smart Phones Fail?”

Half Baked IoT Stove Could Be Used As A Remote Controlled Arson Device

[Pen Test Partners] have found some really scary vulnerabilities in AGA range cookers. They are connected by SMS by which a mobile app sends an unauthenticated SMS to the AGA to give it commands for instance preheat the oven, You can also just tell your AGA to turn everything on at once.

The problem is with the web interface; it allows an attacker to check if a user’s cell phone is already registered, allowing for a slow but effective enumeration attack. Once the attacker finds a registered device, all they need to do is send an SMS, as messages are not authenticated by the cooker, neither is the SIM card set up to send the messages validated when registered.

This is quite disturbing, What if someone left a tea towel on the hob or some other flammable material before leaving for work, only to come back to a pile of ashes?  This is a six-gazillion BTU stove and oven, after all. It just seems the more connected we are in this digital age the more we end up vulnerable to attacks, companies seem too busy trying to push their products out the door to do simple security checks.

Before disclosing the vulnerability, [Pen Test Partners] tried to contact AGA through Twitter and ended up being blocked. They phoned around trying to get in contact with someone who even knew what IoT or security meant. This took some time but finally they managed to get through to someone from the technical support. Hopefully AGA will roll out some updates soon. The company’s reluctance to do something about this security issue does highlight how sometimes disclosure may not be enough.

[Via Pen Test Partners]

IOT Startup Bricks Customers Garage Door Intentionally

Internet of Things startup Garadget remotely bricked an unhappy customer’s WiFi garage door for giving a bad Amazon review and being rude to company reps. Garadget device owner [Robert Martin] found out the hard way how quickly the device can turn a door into a wall. After leaving a negative Amazon review, and starting a thread on Garadget’s support forum complaining the device didn’t work with his iPhone, Martin was banned from the forum until December 27, 2019 for his choice of words and was told his comments and bad Amazon review had convinced Garadget staff to ban his device from their servers.

The response was not what you would expect a community-funded startup. “Technically there is no bricking, though,” the rep replied. “No changes are made to the hardware or the firmware of the device, just denied use of company servers.” Tell that to [Robert] who can’t get into his garage.

This caused some discontent amoung other customers wondering if it was just a matter of time before more paying customers are subjected to this outlandish treatment. The Register asked Garadget’s founder [Denis Grisak] about the situation, his response is quoted below.

 It was a Bad PR Move, Martin has now had his server connection restored, and the IOT upstart has posted a public statement on the matter.– Garadget

This whole debacle brings us to the conclusion that the IoT boom has a lot of issues ahead that need to be straightened out especially when it comes to ethics and security. It’s bad enough to have to deal with the vagaries of IoT Security and companies who shut down their products because they’re just not making enough money. Now we have to worry about using “cloud” services because the people who own the little fluffy computers could just be jerks.

Gigabytes the Dust with UEFI Vulnerabilities

At this year’s BlackHat Asia security conference, researchers from Cylance disclosed two potentially fatal flaws in the UEFI firmware of Gigabyte BRIX small computers which allow a would-be attacker unfettered low-level access to the computer.

Gigabyte has been working on a fix since the start of 2017. Gigabyte are preparing to release firmware updates as a matter of urgency to only one of the affected models — GB-BSi7H-6500 (firmware vF6), while leaving the — GB-BXi7-5775 (firmware vF2) unpatched as it has reached it’s end of life. We understand that support can’t last forever, but if you sell products with such a big fault from the factory, it might be worth it to fix the problem and keep your reputation.

The two vulnerabilities that have been discovered seem like a massive oversight from Gigabyte, They didn’t enable write protection for their UEFI (CVE-2017-3197), and seem to have thrown cryptography out of the window when it comes to signing their UEFI files (CVE-2017-3198). The latter vulnerability is partly due to not verifying a checksum or using HTTPS in the firmware update process, instead using its insecure sibling HTTP. CERT has issued an official vulnerability note (VU#507496) for both flaws.

Attackers may exploit the vulnerabilities to execute unsigned code in System Management Mode (SMM), planting whatever malware they like into the low level workings of the computer. Cylance explain a possible scenario as follows:

The attacker gains user-mode execution through an application vulnerability such as a browser exploit or a malicious Word document with an embedded script. From there, the attacker elevates his privileges by exploiting the kernel or a kernel module such as Capcom.sys to execute code in ring 0. A vulnerable SMI handler allows the attacker to execute code in SMM mode (ring -2) where he finally can bypass any write protection mechanisms and install a backdoor into the system’s firmware.

With all this said, it does raise some interesting opportunities for the hacker community. We wonder if anyone will come up with a custom UEFI for the Brix since Gigabyte left the keys in the door.

Fail of the Week: NASA Edition

There’s a reason we often use the phrase “It ain’t Rocket Science”. Because real rocket science IS difficult. It is dangerous and complicated, and a lot of things can and do go wrong, often with disastrous consequences. It is imperative that the lessons learned from past failures must be documented and disseminated to prevent future mishaps. This is much easier said than done. There’s a large number of agencies and laboratories working on multiple projects over long periods of time. Which is why NASA has set up NASA Lessons Learned — a central, online database of issues documented by contributors from within NASA as well as other organizations.

The system is managed by a steering committee consisting of members from all NASA centers. Public access is limited to a summary of the original driving event, lessons learned and recommendations. But even this information can be quite useful for common folks. For example, this lesson on Guidance for NASA Selection & Application of DC-DC Converters contains several bits of useful wisdom. Or this one about IC’s being damaged due to capacitor residual discharge during assembly. If you ever need to add a conformal coating to your hardware, check how Glass Cased Components Fractured as a Result of Shrinkage in Coating/Bonding Materials Applied in Excessive Amounts. Finally, something we have all experienced when working with polarized components — Reverse Polarity Concerns With Tantalum Capacitors. Here is a more specific Technical Note on polarized capacitors (pdf): Preventing Incorrect Installation of Polarized Capacitors.

Unfortunately, all of this body of past knowledge is sometimes still not enough to prevent problems. Case in point is a recently discovered issue on the ISS — a completely avoidable power supply mistake. Science payloads attach to the ISS via holders called the ExPRESS logistics carriers. These provide mechanical anchoring, electrical power and data links. Inside the carriers, the power supply meant to supply 28V to the payloads was found to have a few capacitors mounted the other way around. This has forced the payloads to use the 120V supply instead, requiring them to have an additional 120V to 28V converter retrofit. This means modifying the existing hardware and factoring in additional weight, volume, heat, cost and other issues when adding the extra converter. If you’d like to dig into the details, check out this article about NASA’s power supply fail.

Thanks to [Jarek] for tipping us about this.

OWL Insecure Internet of Energy Monitors

[Chet] bought an electricity monitor from OWL, specifically because it was open and easy to hack on at him within the confines of his home network. Yay! Unfortunately, it also appears to be easy to hack read outside of his home network too, due to what appears to be extraordinarily sloppy security practices.

The short version of the security vulnerability is that the OWL energy monitors seem to be sending out their data to servers at OWL, and this data is then accessible over plain HTTP (not HTTPS) and with the following API: http://beta.owlintuition.com/api/electricity/history_overview.php?user=&nowl=&clientdate=. Not so bad, right? They are requiring username and password, plus the ID number of the device. Maybe someone could intercept your request and read your meter remotely, because it’s not encrypting the transaction?

Nope. Much worse. [Chet] discovered that the username and password fields appear not to be checked, and the ID number is the device’s MAC address which makes is very easy to guess at other device IDs. [Chet] tried 256 MACs out, and got 122 responses with valid data. Oh my!

Take this as a friendly reminder and a cautionary tale. If you’re running any IoT devices, it’s probably worth listening to what they’re saying and noting to whom they’re saying it, because every time you send your data off to “the cloud” you’re trusting someone else to have done their homework. It is not a given that they will have.

Fail Of The Week: How I Killed The HiPot Tester

Have you ever wired up a piece of test equipment to a circuit or piece of equipment on your bench, only to have the dreaded magic smoke emerge when you apply power? [Steaky] did, and unfortunately for him the smoke was coming not from his circuit being tested but from a £2300 Clare H101 HiPot tester. His write-up details his search for the culprit, then looks at how the manufacturer might have protected the instrument.

[Steaky]’s employer uses the HiPot tester to check that adjacent circuits are adequately isolated from each other. A high voltage is put between the two circuits, and the leakage current between them is measured. A variety of tests are conducted on the same piece of equipment, and the task in hand was to produce a new version of a switch box with software control to swap between the different tests.

This particular instrument has a guard circuit, a pair of contacts that have to be closed before it will proceed. So the switch box incorporated a relay to close them, and wiring was made to connect to the guard socket. At first it was thought that the circuit might run at mains voltage, but when it was discovered to be only 5V the decision was made to use a 3.5mm jack on the switch box. Inadvertently this was left with its sleeve earthed, which had the effect of shorting out a DC to DC converter in the HiPot tester and releasing the smoke. Fortunately then the converter could be replaced and the machine brought back to life, but it left questions about the design of the internal circuit. What was in effect a logic level sense line was in fact connected to a low current power supply, and even the most rudimentary of protection circuitry could have saved the day.

We all stand warned to be vigilant for this kind of problem, and kudos to [Steaky] for both owning up to this particular fail and writing such a good analysis of it.

Our Fail Of The Week series has plenty to entertain the reader who is not of a nervous disposition. This isn’t the first fail to feature a suspect bit of connector wiring, not an unexpected short or even some magic smoke.