Category Archives: Uncategorized

When they posted a video, I thought I’d check them for sensitive information disclosure, like actual customer ICCIDs and chip numbers.

However, what I found was far funnier. On one of their own promotional videos, they show a close up of an member of staff using some kind of operations/support portal, but they are also logged into Hotmail.

To the left, the partially obscured tab says “o Be Loved?” – a dating site maybe?

An article entitled “Why The Internet of Things and the Cloud Should Break Up” showed up on Reddit and Twitter earlier this week. It sounded promising – I’m a proponent of decoupling IoT systems so that they don’t rely on the cloud, even if they still use the cloud most of the time. What I was greeted with was a terrible opinion piece, full of misinformation.

I don’t know where to start, it’s so bad.

A FitBit wristband connects via Bluetooth with your smartphone but sends your activity data to a FitBit cloud app. Does your personal health data really need to sit in the cloud or can you extract sufficient value from it by simply keeping the data stored locally on your smartphone?

This isn’t the IoT. That’s a Bluetooth device connecting to a phone. He seems to be one of these people who will call anything connected and not a full blown machine “IoT”.

For most of the IT industry — let’s just get this on the table — the cloud today is the hammer and there’s almost nothing that isn’t a nail. And the cloud is an easy place to build an IoT application and operates without the messy hassles of embedded software, endpoint security, FCC regulations, or fertility risks, to name a few.

Firstly, using the cloud generally means adding functionality to endpoints. Take a standard IP camera, accepting connections on port 80, using port-forwarding for remote access. Add cloud functionality to allow remote streaming and the system takes more time to develop. It is not a freebie.

Secondly, using the cloud normally makes endpoint security much less of an issue. Traditional architectures, such as port-forwarding to devices, or customers running their own infrastructure, involve inbound connections to your network and endpoints. Many cloud connected devices have absolutely no ports open at all – SmartThings v2 hub for example. Because of this, endpoint security becomes a lot less difficult.

Thirdly, regardless of your architecture, if you want to use wireless connectivity, you need to deal with RF. I don’t see how the cloud avoids this.

It’s cheap and everywhere. Like beer in your dorm, the cloud today is so popular and so well-capitalized that infecting the IoT was only a matter of when, not if. Spin-offs like cloud analytics or cloud perimeter security (no laughing!) are simply too affordable and too visible to pass up. Traditional enterprise IoT pilots that used to cost $250,000 in enterprise software and systems integration services can be executed at a fraction of this price now due to the cloud.

Developing cloud systems and operating robust, secure cloud systems is a cost and complexity. People are not doing it to avoid cost.

Tools. Compared to older desktop-based tools, cloud-based environments and API’s are vastly simpler to use and integrate while offering robust functionality.

He seems to be conflating using a cloud-based development environment with operating in the cloud. Nearly all cloud based solutions need significant development in traditional languages, on a desktop. It’s not point and click.

Weak endpoints and edges. Endpoints that don’t do analytics, support real-time queries, or even support full two-way messaging tend to spew data remorselessly to an edge router and/or the cloud. Bluetooth, ZigBee, 6lowPAN, and others are all guilty as charged and as a result, they end up driving their users to the cloud.

He seems to have a bee in his bonnet about how “stealthy” wireless protocols are. There really is no link between the wireless protocol used and how much data ends up getting sent to the cloud. They are different layers – one a transport protocol, the other application. Zigbee does send a fair amount of beacon traffic, but none of this ends up outside the PAN. If your app sends a lot of traffic over Zigbee and then your gateway sends it to the cloud, that is not the fault of Zigbee.

It’s not secure. This one is hard to overstate as crummy IoT security is the sordid “yeah, but” in so many discussions about the IoT. IDC predictsthat nearly every IT network will have an IoT security breach by the end of 2016 and IT departments are in full freakout mode now. Endpoint security is comically bad and compounded with a hacker-friendly cloud, what could go wrong?

There is absolutely nothing inherent in the cloud architecture that makes it insecure. In fact, there can be a lot of advantages:

Waiting 2–3minutes for a cloud app to make time for you is a non-starter.

This is just pure misinformation. Going over the Internet adds latency. It doesn’t add “2-3 minutes”, it adds milliseconds typically. 2-3 minutes means the system has been designed badly, and this would be an issue regardless of where it operates.

It may not be faithful. The integrity of your data in the cloud is only as good as the people and systems hosting it. Sensors in your manufacturing facility in Taipei showing you running at 50% below your normal run rate or showing a supply chain hiccup? Hedge funds and competitors enjoy learning about this kind thing!

The integrity of your data on your self-hosted platform is only as good as the people and systems hosting it. Again, nothing inherent about cloud. I would rather have a skilled operations team managing intrusion detection, performance monitoring and disaster recovery than burden a sysadmin with yet another system in-house.

Getting out may be easier than getting in. Once you’ve married a cloud service, how easy will it be to disengage/migrate to another solution at some future date? Is standardization and interoperability in a state that will increase the risk of vendor lock-in? What if the cloud vendor is bought by your competitor and changes policies?

Which is equally true of any bought-in platform. Just remove the word “cloud” from the above paragraph. Vendor lock-in is real however.

A new golden rule of IoT network design is to store sensor data as close as possible to its point of origin and limit its sharing across the network unless absolutely necessary.

You can’t just invent golden rules. Many people want low-cost, low-power endpoints with no storage and no persistence, pushing everything to more powerful gateways or servers. The AWS and Azure IoT platforms both accommodate for this. This is Pat Burn’s golden rule, to sell his product.

The endpoint is key to the golden rule. Better processors, cheaper memory, and better networking stacks from companies like Haystack are evolving endpoints from dumb terminals to independent, distributed computing devices with real-time query (think Google for the IoT) and NoSQL-like filesystem support. Endpoint-centric designs also have the bonus of being more stealthy and secure, faster, cheaper, and better stewards of battery life and wireless bandwidth. In short, good IoT network design should begin with the endpoint in mind and “dumb” endpoint technologies that beacon or create unnecessary security risks should be phased out

I just don’t know where to begin on this.

The enemy of security is complexity. Are you actually trying to argue that having hundreds of endpoints in a distributed network, able to store data and be queried, are going to be more secure than, say, a memory-based RFID tag? Or a transmit-only 8-bit PIC based humidity sensor?

Firstly, that is very, very specific. “Poor architecture of the wireless protocol”. Not “Weak implementation of the wireless protocol” or “devices using wireless protocols”.

Secondly, neither of the links provided are breaches. A breach is the result of a system being exploited. One is information leakage, the other is a report of a vulnerability.

Thirdly, the Jeep hack was nothing to do with the wireless protocol. Jeeps could be using wired Ethernet and the same issues would have been present.

Fourthly, nearly every IoT breach in recent news has been carried out over the Internet. Not local attacks to the wireless protocol. There is a lot of research into wireless security, and there are a lot of noise at conferences, but the bulk of issues occur over the Internet remotely. Hackers are not sat outside homes and business cracking your Zigbee or wireless burglar alarm.

Avoiding or minimizing the chances of unauthorized discovery is not technically difficult. But today’s IoT technologies like Bluetooth, 6lowpan, Sigfox, LoRaWAN, and others make unauthorized discovery very easy and it creates the worst kind of angst in IT departments.

Most of the protocols make discovery easy because it is intentional. They layer security with discoverability, enabling systems which people can actually use and are actually deployed (unlike Dash7).

The link doesn’t support that unauthorised discovery is causing angst in IT departments. He seems to often do this – provide a link which is vaguely related but doesn’t support the argument. It would be fair to say “IoT is causing angst in IT departments”.

Most wireless IoT technologies were originally conceived as ways to stream large files (Bluetooth, WiFi) while some were designed to be “lighter” versions of WiFi (e.g., ZigBee). Today they are being re-positioned as “IoT” technologies and security, to put it nicely, is an afterthought. Oh yes — some have tried to “layer on” security and may profess to support encryption

Layering encryption onto a transport protocol is completely valid. It’s widely acknowledge that ZigBee, Z-Wave and WiFi, if implemented correctly, are secure from the risk profile that is involved. Skilled hackers are not sat outside your house, waiting for you to pair you Hue bulbs to the hub and grab the keys. It is not happening. Even if they did, all they can do is turn your lights on and off.

I have no idea why they “profess” to support encryption. They all offer encryption. WPA2 is actually a very secure protocol.

hacks for all of these technologies are quite public yet fundamentally traceable to one original sin:

these wireless IoT technologies don’t know how to keep quiet.

What? What hacks of wireless protocols can be traced to not keeping quiet?

No, drones are being used to map Zigbee broadcast traffic. This is not enabling anyone to hack Zigbee anymore than putting your house number on the door of your house enables someone to pick your locks.

this type of hack provides all sorts of information about each endpoint, including manufacturer ID.

This is not a hack.

This need to be “discoverable” — and this is not limited to ZigBee, Bluetooth or WiFi but to most wireless IoT technologies — requires a near-constant advertising of a device’s presence, leading to any number of “disaster scenarios” that others have extensively written about.

The link, again, doesn’t support that a wireless protocol being discoverable will lead to any disaster scenario. Just pile the links on and hope no one checks.

There is no technical reason that the Internet of Things cannot embrace silence, or stealth as I prefer to call it, as a first principle of endpoint security. Stealth is not a silver bullet for IoT security (there is no silver bullet) and stealth alone won’t protect a network from intrusions, but dollar-for-dollar, stealth is the simplest, cheapest, and most effective form of IoT security protection available.

There is, quite literally, nothing to support this position.

A endpoint, receiving and sending plaintext, unauthenticated commands and data, will not see a noticeable improvement in security. Passive monitoring of the channel will still leak data, and active tampering will cause havoc. The stealth must be broken for the device to send, and this can be seen.

An endpoint, receiving and sending encrypted, authenticated commands and data, will not see a noticeable improvement in security. The data is still encrypted. Unauthenticated commands won’t be carried out.

This is just garbage.

Dollar for dollar, it might be worth making your nodes quieter, but not at the cost of switching from a widely adopted, widely inspected wireless standard to Dash7.

He tries to explain why:

Cloaking. It is harder to discover, hack, spoof, and/or “stalk” an endpoint if a hacker cannot locate the endpoint.

Endpoints need to send. Being stealthy can reduce the traffic but there will still be traffic. Stealth is only a weak layer of security through obscurity.

This has absolutely nothing to do with how stealthy communications are from the node. If you enable your node to be queried, it can be queried. In fact, querying and accessing data from the edge of a network almost negates attempts at being stealthy as you will see an increase in complex and important traffic of the wireless network.

Minimize interference. Less data being transmitted minimizes the opportunities for interference and failed message transmissions. Contrast this with the tragedy of the commons at 2.45 GHz, where WiFi, ZigBee, microwave ovens, and other countless other technologies engage in wireless gladiatorial combat and cause too many customers to return their IoT gadgets because they “don’t work”.

Again, this has very little to do with stealth. 434MHz – that Dash7 uses – has as many issues with contention as 2.4Ghz. In the UK, there are many more poor quality, untested, non-standards compliant transmitters in the 434MHz band than there are on 2.4Ghz.

Access control. Stealthy endpoints make it easier to control access to the endpoint by limiting who can query the endpoint.

Again, absolutely no link between stealth and access control. If you limit access to something, you limit access to it.

Storage. Less data being transmitted reduces storage costs. Storage vendors, on the other hand, love the non-stealthy IoT status quo.

Again, what? If your endpoint decides to ditch data, then your cloud can also decide to ditch data. This has nothing to do with stealth of the wireless protocol – it’s about volume of data at the application layer.

This looks like, for the 2nd matching term, run the spam function on it. The second term is substituted inside the spam() function, then executed. Maybe we can inject a command here.

I’ve recently done a couple of XSS tutorials/games, which have given me a fair bit of practice at command injection (in Javascript, though), and felt I was getting quite natural and good at it. However, this PHP one ended up being just a big case of trial and error.

I started trying to execute phpinfo() – it nearly always works and doesn’t need any parameters passing to it.

Most Linux systems use a shadow password file. The normal /etc/passwd file is visible in the open (it is used to map userid -> name etc.), but it has no password hashs. These are stored in /etc/shadow, which is permissioned such that unprivileged users can’t see the hashes.

So, let’s take a look at /etc/passwd:

Shell

1

2

3

4

level06@nebula:~$cat/etc/passwd|grepflag06

flag06:ueqwOCnSGdsuM:993:993::/home/flag06:/bin/sh

level06@nebula:~$cat/etc/passwd|greplevel06

level06:x:1007:1007::/home/level06:/bin/sh

Compare level06 (a normal account) to flag06 (legacy). ueqwOCnSGdsuM is the hash of their password.

It’s been a long time since I have done this, but the go-to password cracker was always John the Ripper, and it still appears to be that way.

This is available as a package in Ubuntu, so it could be installed with sudo apt-get install john. I don’t know the sudo password, so I can’t install this in the Nebula VM without using the admin account they give you. It’s perfectly possible to install it on your local machine, copy the passwd file across, and crack it there though.

Shell

1

2

3

4

5

andrew@Andrews-MacBook-Pro:~/nebula$john passwd

Loaded1password hash(Traditional DES[128/128BS SSE2-16])

hello(flag06)

guesses:1time:0:00:00:00100%(2)c/s:75300trying:123456-marley

Usethe"--show"option todisplay all of the cracked passwords reliably

I ran it on my Mac and it got the password very quickly – it’s just hello. Login and run getflag.

Aside

I haven’t managed to find an online password cracker that deals with this type of password hash, which is surprising. It is quite old-school though.

Can configure frequency, span, RBW and FSW. Minimum span is 0.2MHz, minimum RBW is 58kHz, minimum FSW is 1kHz. It seems that a lot of values here cause no display – span of 0.5MHz stops the display working.

Does realtime, max, average display.

Numeric entry validation is really irritating – it limits you whilst entering the value rather than after.

A lot of the UI doesn’t seem to like Windows 8 with scaling set to <>100%.

Crashes relatively frequently.

Mentions firmware and calibration data in the app, so it might be relatively well calibrated.

Source code for the app is available.

I’d be annoyed if I spent $250, but it’s great for £25. There is a lack of documentation on the hardware – there are a lot of passives between the SMA and CC430. It would be nice if this could be used for transmit as well as receive but I expect the passives will get in the way.

Today, my wireless alarm hacking posts ended up on Hackaday, and I received this comment:

Your average suburban burglar is gonna be way to dumb to figure this stuff out. And if you’ve got millions of dollars worth of art or whatever that might attract a higher class of crook, you’re not gonna scrimp on security eh?

I’ve had more than a few people reply with the same sentiment over the last few months, so I thought I’d reply here rather than in a comment.

Burglars are too dumb

The burglar doesn’t need to be clever. He just needs to buy a device from someone who is clever and immoral. It’s possible to use a CC1110 RF SoC to jam, disarm, and otherwise disable many of these alarms. It wouldn’t need any skill to operate and it wouldn’t cost much.

Burglars won’t bother

This was exactly what people said about keyless ignition and entry on cars. That quickly changed once exploits were available.

Anyone with sense would have a better alarm system

They might have an alarm system that looks better on paper. But they have absolutely no way of actually knowing if the alarm has any exploitable vulnerabilities or not. There is no requirement for alarms to be independently tested. I can confidently say that much more expensive alarms are no better than the Friedland alarm detailed in my posts.

As an aside from this – the higher grade alarms are really only there to satisfy insurance requirements. As long as it the system meets the requirements of the insurers, it shouldn’t matter if there are any vulnerabilities. Unless, of course, it looks like the alarm wasn’t set in the first place…

Conclusion

This doesn’t mean that burglars are exploiting vulnerabilities in wireless alarms. It does mean two things:

Consumers don’t have the means to tell if an alarm system is secure or not, due to poor standards and lack of third party testing.

Alarm and signalling manufacturers are happy to sell insecure equipment because of this.

Almost the same technique as yesterday, but a much bigger timesaver this time. Most Linux distributions come with the open OpenJDK installed. This is fine for most things, but I’ve noticed that apps that are graphically complex (PyCharm for one) have some rendering issues and CPU usage is high.

You can install the Sun/Oracle Java instead, but this seems to be a pain to do from the download. There is another PPA for this:

1

2

3

sudo add-apt-repository ppa:webupd8team/java

sudo apt-get update

sudo apt-get install oracle-java7-installer

It still downloads all however-many-megabytes of installer, but it’s fire and forget. No need to un-install OpenJDK, they can coexist.

I'm a security researcher and reverse engineer. By visiting this site, you must realise that any or all files on this site may be jam packed full of the finest exploits, tricks and other gubbins. You might also get geo-located and port-scanned for fun and profit.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRead More
If I really want to track you, by tricking you into visiting this site, then it's going to be a lot more subtle than a browser cookie.