Turkish Clicker: Another Reason Even Offical App Stores Aren't Guaranteed Free Of Malware

From Turkish Clicker: Check Point Finds New Malware on Google Play

The Check Point research team has discovered an extensive malware campaign on the Google Play™ store. Check Point Mobile Threat Prevention detected the first samples of malware we call “Turkish Clicker” on several customer devices.

The malicious code was found in the apps “Fruit Life,” “City HD Wallpapers,” and “Adiyef Puzzle.” Google has removed all of these apps from Google Play.

Like BrainTest, which Check Point researchers discovered in September 2015, this demonstrates how easy it is for fraudsters to publish malicious apps on official app stores like Google Play.

While official App Stores such as Google Play and Apple’s App Store are no guarantee of a malware-free experience, they do a level of checking on apps submitted to ensure they are what they say on the tin and not doing something nefarious behind the scenes. Malicious app makers are engaging in a sort of cat-and-mouse game to try and sneak their apps through the review process, though once found, these malicious apps are removed from the official app stores.

Worse things can happen with unofficial applications or even ones that look official, but are sideloaded. Avoid it if you can. Meanwhile, if you have corporate data on your personal device, that data should be protected with a solution like Check Point’s Mobile Threat Prevention,

From Press Backspace 28 times to own unlucky Grub-by Linux boxes:

A pair of researchers from the University of Valencia’s Cybersecurity research group have found that if you press backspace 28 times, it’s possible to bypass authentication during boot-up on some Linux machines.

The problem’s not a kernel nor an operating system problem, but rather one in the very popular bootloader Grub2, which is used to boot an awful lot of flavours of Linux.

Essentially, if you enable Grub2’s password protection during system startup, it won’t do you much good – it can be easily defeated. (Luckily, the vast majority of distributions of Linux do not enable this by default.)

I don’t want to say this is a non-issue, because it’s not. That said, it helps to have some perspective on the impact of a potential vulnerability so you know what you should do about it at what priority.

When I worked in the TAC back when I was at Nokia, I was the guy who would decipher the latest “OMG, my scanner found your firewalls are vulnerable to this new CVE, fix it.” This meant reading the actual CVE to figure out if this could lead to remote code execution, cross-site scripting, or similar.

Because of how Nokia IPSO was hardened, many of the vulnerabilities had no particular impact, either because the vulnerable component wasn’t there or it was configured in a more secure configuration than the default.

Or, better yet, in order to leverage the exploit, you had to have a specific kind of access to the machine (say, shell access) that could lead to far more dangerous things than the vulnerability in question.

This Grub bug is one of those things. First of all, this bug only shows up in a non-default configuration and requires physical access to boot. Ok, so maybe also a serial console might work, too. Either way, this limits the potential scope of a potential attack. Furthermore, if you actually have physical access, unless you’ve performed some sort of drive encryption, that physical access could be leveraged to, say, steal or clone the drive. Which is a far more serious threat.

In the grand scheme of things, this bug would not be a huge priority to deploy a patch for in all cases. Unlike, say, the backdoor in Juniper/Netscreen gear which can be remotely exploited.

Bridging The Information Security Gap

You may have noticed a marked increase in the amount of posts I’ve done to this blog lately. Or maybe you haven’t because I’m just one of many people in your Twitter, RSS, LinkedIn, Medium, or however you read and/or ignore my stuff.

Whether you read these ports or not, all these new posts aren’t necessarily an accident. There is a underlying motivation driving me to put thoughts around Information Security to digital bits once again.

What is it? A sense of purpose that, quite honestly, I haven’t felt in a while. About the Information Security industry. About where I see things happening and some things we need to do to affect positive change, creating a more “secure by default” environment for everyone and everything.

Do I think it will happen overnight? No. Do I have all the answers about how to get there? No. That said, 20 years in this industry has given me some ideas about what works and what doesn’t.

What I do know is that the bottom-up approach that many are taking to affect change isn’t working that well. By that, I mean that initiatives for Information Security are usually not coming from the people in charge, but rather the IT (Security) personnel who, innately, understand something needs to be done, but they can’t explain it to the people who write the checks in a way that will get the necessary funding required to affect change.

Sometimes, security initiatives are actually driven from above as well. Frequently, it comes after a major incident that makes the news. I bet Information Security suddenly became a lot more important at the various retailers that had millions of PCI and/or PII data records stolen. However, there’s no evidence those efforts have resulted in improved security or that other, similar organizations have started taking the necessary actions to improve their information security practices before they are the next target.

There’s a lot of platitudes and sound bytes out there about how organizations can be more secure. There’s a lot of noise from vendors in the space about their solutions and how, if you buy and deploy their stuff, they will keep you secure (and those other vendors who have competing products won’t).

This problem, and the solutions, are far more nuanced than any sound byte can capture or any single product suite can solve. It’s about bridging the gap between the technical information security people who know what’s going on and the people making the strategic decisions and writing the checks.

This is the kernel of the idea I have. The details of how to do this need a bit more refinement. When I put these ideas out there, I expect the Internet to tell me how wrong I am:

I’m not afraid of that. In fact, I welcome it. One lesson I learned from maintaining the old FireWall-1 FAQ was that when I put wrong information out there (not intentionally, of course), someone will tell me and give me the right information. Then I can share that information with others, as I’ve done for 20 years.

When the time comes, I would like to share these ideas with a much wider audience than my old FireWall-1 FAQ was able to reach. If you have any suggestions or feedback, I’d love to hear your thoughts.

Cybersecurity: Protection From an Existential Threat

From Cybercrime poses a potential existential threat to our society, and we’re completely unprepared:

Connecting our cars and pacemakers and planes and power grids to computers gives us access to computing power that was unimaginable decades ago.

But it also means that we have security threats that were unimaginable decades ago, which Goodman says is a potential existential threat to society, the sort of thing that needs to be a national priority as big as the space race or the Manhattan project.

The premise of this article is that the lack of cybersecurity around critical infrastructure and the increased prevalence of cybercrime poses an existential threat to society. Existential meaning “of or relating to existence.”

It’s a pretty bold statement. It’s also, based on the cross-section of companies and security experts I’ve talked to, a very real possibility.

Where I disagree with the article is the fact that we need some sort of Manhattan Project-type effort to solve the problem. As if developing a single nuclear-type weapon will be enough to prevent all cybercrime.

Those of us who’ve been in the industry for a couple of decades already know how to significantly reduce the risks. It doesn’t even require new technology, though some organizations will undoubtedly need to acquire some.

The one thing that it will surely require from all organizations and all persons is applied effort. And sadly, the only way I see the majority committing to that is for a nuclear-type event to occur. Only, it will be much more harmful than Trinity was.

The Security Impediment

From Chip Cards Take So Long, Some Retailers Disabled Them For The Holidays:

It could be that, among other things, retailers are reacting to shoppers’ sentiments. One in five consumers names transaction time as their biggest concern when using an EMV-enabled credit or debit card, according to a recent survey by point-of-sale firm Harbortouch.

It takes about seven to 10 seconds to process a chip card at the register versus two to three seconds to process a swipe. “While seemingly small, during busy times like the holidays, these increased processing times could add up quickly,” Jared Isaacman, founder and CEO of HarborTouch, said in the press release.

This is not a hypothetical problem that’s pointed out here. In a super-busy store, slowing down the entire point-of-sale system for added security can mean less customers go through the checkout, meaning the retailers make less money.

The problem is even more acute in stock trading. Delays of even a fraction of a second in receiving a trade order can cost serious money.

Organizations of all kinds often make a tradeoff between transaction speed and ensuring that transaction is authorized and legitimate. They usually err on the side of speed versus secure.

There is no right or wrong answer, because part of security is accepting risk for specific behavior that is less secure. This can happen because:

  • The cost to mitigate the risk is too high
  • The cost of failure of a mitigating security control is exceptionally high
  • The likelihood of occurence of the relevant events are very low

Security measures are often viewed–rightfully so, in some cases–as impeding business. Of course, they also enable business as well. I doubt e-Commerce would have flourished the way it did had Netscape not invented Secure Sockets Layer.

Those of us in the security industry need to ensure the solutions we are offering are not impeding business while providing a high level of security and reliability. That way, organizations won’t have to accept as much risk as they do today.