SecureMac, Inc.

Checklist 137: Security Breach on Pump Four

May 10, 2019

On this week’s Checklist by SecureMac: Security breach on pump four, A U.S. city under cyber siege, and Keeping 12-year-olds off of dating apps.

Checklist 137: Security Breach on Pump Four

The last time you went to pump gas into your car, did you stand there and think about security breaches while watching the numbers tick upward? Probably not — though you might have had some choice words about the price of gas today. As we’ll find out on today’s show, you might have something else on your mind next time you stop for a fill-up. That, plus a story about ransomware rising again, and some concerning dating apps on the App Store that allow underage users to sign up for accounts — that’s our list for today. We’re checking off:

It’s another week, another list, and time again to delve into the details. So, what do you need to know about what might be going on at the local gas station? 

Security Breach on Pump Four

Like most people, we wouldn’t usually think very much about the systems that keep gas stations going. As long as it works when you put your card in the machine, you’re probably more concerned with getting back to your day. As it turns out on closer examination, though, there are a lot of gas stations run on “one stop shop” systems — meaning one system does everything, all at once. According to a story from TechCrunch, a company called Orpak makes a software package known as “SiteOmat,” which serves to provide gas stations with a range of abilities such as monitoring the underground gas storage tanks for safety, setting the prices at the pump, and — of course — handling credit card payments, too. 

Basically, if it has a computer or a sensor, SiteOmat interfaces with it and provides gas station employees with all the digital support they need. Of course, since you’re hearing about it here on The Checklist, you can safely assume we’re not here to “wow” you with stories about all its amazing functionality. On the contrary, Homeland Security says it’s got some big holes!

Not only that, but DHS says you’d only need a “low” level of expertise to take advantage of many of those exploits. The number of holes and what they could allow bad guys to do led the DHS subagency called CISA, the Cybersecurity and Infrastructure Security Agency, to give it an extremely high risk-rating. On a scale of 1 to 10, the severity of SiteOmat’s numerous vulnerabilities ranks at a staggering 9.8. One of the most glaring issues the report identified was a manufacturer-created, hardcoded password. That single password acts like a universal skeleton key for SiteOmat, unlocking access to everything.

Keep in mind: even if a gas station owner wanted to do something about this, they couldn’t. A hardcoded password is one that’s baked right into the programming of the software — only the manufacturer could take it out and close off that pathway. We talk all the time about how you shouldn’t use one password for everything, so why would a big developer of enterprise software do something like this?

There are, of course, many possible reasons. It could be a simple matter of laziness on the part of the coders, or perhaps it was a necessary cost-cutting measure implemented to meet a deadline. It could also be a case of efficiency — allowing employees to quickly access different parts of the system without needing to memorize a long list of passwords. Unfortunately, no matter how easy it might be to use, it’s still a very bad idea — especially in a place that handles so much payment processing on a daily basis. If a hacker discovered that hardcoded password, they might be able to steal that info or cause chaos at the pump by changing the price of gas.

Did we mention that SiteOmat is Internet-capable, and any system connected to the Internet is remotely exploitable? Oh yes — in fact, according to TechCrunch, nearly 600 of these vulnerable systems are out there on the web. 205 of them, representing hundreds of different gas stations, are in the US.

Unfortunately, there’s not a whole lot our listeners can do directly about this story — this is something Orpak needs to remedy, and hopefully before an actual problem emerges as a result of a bad guy getting their hands on a system’s hardcoded password — or finding another way inside the system. SiteOmat software is also vulnerable to “buffer overflow” attacks and “code injection” schemes. Not sure what those are? These terms come up a lot in security news, and often it’s taken for granted that readers know what they are — let’s crack open the dictionary for a helpful refresher before we move onto our next story.

What is a buffer overflow? Let’s use a visual example to explain this.  Buffers are temporary spaces your computer uses to store bits of data. Imagine that your home’s backyard is your device’s memory. You have a small area that you haven’t landscaped off to the side — that’s your buffer, your “just in case” area. Now, one day, you see a weed in there. No problem, right? Just pluck the weed. The next day, you see that there are so many weeds in there, they’ve spilled over into your nice landscaped area. In computer terms, this can happen when hackers find a way to make programs behave in ways they weren’t designed to, causing buffers to become too full. When the “weeds” spill over, that could be malicious code.

Which leads us to code injections — buffer overflows can be used to “inject” code. In other words, you’re able to splice in some new and malicious instructions into a running program with no one being any the wiser. Imagine if someone wrote a piece of code to invisibly shave a few cents off the price of gas during every transaction — it would be tough to find! 

There’s one ray of good news in this story: the bugs have been patched in a new version of SiteOmat. The downside? Operators must contact Orpak directly to request the update. Have they even notified users that such a critical update is available? Nobody knows. Fingers crossed, though…

A U.S. City Under Cyber-Siege

Hey, remember ransomware? It’s been a while since any ransomware made the news, but as we recorded this show, the city of Baltimore in Maryland was in the process of being held for ransom. We don’t mean a Dark Knight Rises situation with Bane in Gotham, but something is going on in Baltimore. The city’s Capital Gazette reported early in the week that computer systems throughout the city government had been stricken with a severe ransomware infection. The attack, of course, has kept many people from doing their jobs.

Since it’s been so long since we had a ransomware story on the show, here’s a quick recap: ransomware is a specific type of malware; it might be a virus or a worm, or it could be a complete software packaged installed directly with a hidden payload inside. Once it’s on a computer, it locks everything down, usually by encrypting the contents of the hard drive with a secret key. Unless the victim pays the bad guys some money, they can’t get their data back — without a backup copy, it’s gone forever.

While the Mayor’s office stressed that 911 lines and other “critical systems” were still up and running, the “majority” of servers providing the city with other digital capabilities were unavailable as a result of the infection. So, who did this and what do they want? We don’t know the answers to these questions: The Mayor’s office said Wednesday, a day after the infection began, that they did not want to publicly share any information that might indicate to hackers which systems were struck, as it could expose additional vulnerabilities. 

Is that really true? Well, this is probably a statement filtered down through several layers — it’s somewhat accurate, but may not be the whole picture. Likely what’s happening is that while Baltimore cooperates with law enforcement, they want to say as little publicly as possible to preserve the opportunity to — ideally — figure out the perpetrator. Meanwhile, there’s been some confusion in the city over how to combat the problem as employees sought to stop the spread and preserve their own work.

While there are many details we don’t know right now, there is one thing we do know: the type of ransomware involved. It’s called RobbinHood — not RobinHood, the investment company and app. According to BleepingComputer, a security researcher named Vitali Kremez went to work on this version of RobbinHood recently and reverse engineered it to find out what makes it tick. Inside, he found powerful ransomware code that could turn off nearly 200 Windows services, including encryption, database software, and antivirus programs. After turning off these services, it disconnects from network shares and encrypts the files. It then, of course, demands payment.

Baltimore’s mayor, speaking about the issue, said that it didn’t matter what the city put in place — hackers would always find a way to cause trouble. While we don’t necessarily agree with that defeatist attitude, it is true that every system has vulnerabilities. We don’t know how the ransomware made its way into Baltimore’s servers yet, though it could be anything from social engineering to spam to a careless employee. However it happened, the hackers are demanding about 13 Bitcoins, or $76,000, for the code to unlock the system.

For now, the infection has been quarantined and is no longer spreading. City officials couldn’t offer a timeline for when affected systems would be freed from the ransomware’s chains. 

Keeping 12-Year-Olds Off Dating Apps

Here’s a unique idea: maybe Apple should pay a little more attention to what’s going on in the App Store approval process. A story from Apple Insider brings us news that Apple (and Google, to be fair) both had to take down three apps in the store because kids 13 and under were able to download the app and sign up for an account. Oh — did we mention these are dating apps?

The apps in question were developed by a company based in Ukraine and called FastMeet, Meet24, and Meet4U. You might recall that on a recent episode of The Checklist, we discussed potential revisions to COPPA — the Children’s’ Online Privacy Protection Act. This is the law that requires websites to get parental consent for users younger than 13 — and these apps definitely did not do that. According to the FTC’s complaint letter, they identified numerous 12-year-old users of the site.

If it’s not bad enough to think about kids chatting with adults using dating apps, the developer, Wildec, also collected in-depth information on users, including location information – pretty typical of modern dating apps. Needless to say, there’s more than one violation of COPPA at play here. The apps were swiftly given the boot. However, it shouldn’t have happened in the first place. 

With that in mind, there are two ways we can address this. First, what can parents do? Well, this is an easy fix: parental controls would have done the trick here no problem. On iOS devices, you can find the parental controls in the “Screen Time” option under Settings. In there, you can do all kinds of things to prevent your kids from doing things you don’t want them doing. Apple is good about giving parents these robust tools, so be sure to take advantage of them. 

Now, Apple’s fix might not be quite so easy. Should they implement a more stringent look at what an app does and who it’s targeting before it goes up — at least if it’s going to be accessible to all age groups? One of Wildec’s other dating apps is still up in the store thanks to its 17+ rating. While Apple may not want to become the arbiter of content, situations such as these merit reviewing the rules and trying to improve the system. 

We’ve discussed parental controls and keeping your kids safe on their digital devices in the past, and we surely will in the future — but we can hope that Apple will continue to refine its App Store processes as well. For now, stay vigilant and keep a watchful eye out — not every developer plays by the rules.

Get the latest security news and deals