Tagged: security

Caution Needed When Using CloudFlare and Better WP Security

There's a nasty WordPress hack doing the rounds at the moment. Essentially, it looks for WordPress blogs and then tries to log in to them using common username / password combinations. If you're still using "admin" and "secret" - now is the time to change them!

I've started using Better WP Security on my blogs. It automatically takes care of securing WordPress against the most common forms of attack. One thing it does particularly well is lock out people who repeatedly try an incorrect password to log in.

Additionally, I've also added CloudFlare to my sites. CloudFlare acts as a CDN - when people visit my site, they're actually hitting the CloudFlare service - CloudFlare caches my content, saving me bandwidth.

You can see where this is going, can't you?

CloudFlare Blocked By Better WP Security

That the IP address of CloudFlare! Due to my inability to perform homographic disambiguation I had repeatedly tried to enter the wrong login details in my management app (i.e. I thought the password had a capital I in it rather than a lower-case l).

All of a sudden, CloudFlaretly was locked out. No worries, I thought, I'll just go in to the database and remove the block.

Only, of course, I couldn't. My entire site was behind CloudFlare. CloudFlare couldn't access my site. Therefore, I couldn't access my site!

So, how to get out of this conundrum?

I could have changed the DNS records of my site to point back to my host - rather than CloudFlare - but that would have taken several minutes to propagate.
Luckily, my delightful web provider VidaHost has a Cpanel console which isn't behind my domain names.
From there, I was able to go into phpMyAdmin and access the Better WP Security lockout database - called "wp_bwps_lockouts". I found the offending IP address and removed it from the block.

That restored access, but how could I prevent it happening again?

CloudFlare offers Page Rules which allow you to disable CloudFlare for a partclar page, or set of pages.

Setting an exclude rule for 

http://example.com/wp-admin

will stop CloudFlare from proxying and cacheing requests to your WordPress admin panel.

It's also possible to "pause" CloudFlare temporarily but that would have lead to a rather large load on my website.

Conclusion

What have we learned today?

  • The unexpected interplay of two independent products can have an "interesting" effect on your service.
  • Always have a backup plan for accessing your server.
  • If someone is using a tool to automatically blacklist IP addresses, it's possible to provoke a Denial of Service attack by proxying requests through a critical piece of their infrastructure.
  • Avoid ambiguous characters in passwords - or at least ensure you use a font which clearly shows the difference between Il1, O0, 5S, etc.
  • Don't panic!

What Can Android Learn From Symbian's Security Model?

More bad news for Android owners. A huge Russian malware operation is infecting Android apps in the the Google Play Store. The malware - hopefully now removed - hijacks your personal details, and sends premium rate text messages to drive profits for its owners.

Nasty.

This is the price we pay for Android's open access policy. iPhone users can smirk all they want - but I like being able to run anything I desire on my phone, rather than be restricted to the puritanical walled garden of Apple's App Store.

The late lamented Symbian OS did many things wrong - but it had an interesting approach to keeping users secure from malicious apps.

The first time an app wanted to access a feature - like Internet, SMS, phonebook - the phone would prompt the user to grant the app permission.

Symbian Internet PermissionSymbian Internet Permission 2Symbian Secure Connection prompt

Now, the Symbian model wasn't without flaws. It would often forget that you'd granted an app permission or repeatedly ask annoying questions.

Is this what is needed for Android? the first time an app tries to access, say, the dialer - should Android say "Are you sure you want Angry Birds to make a phone call?"

Or, should Android take a leaf out of BlackBerry 10? When installing the app, the user can choose whether to grant certain permissions.

Finally, what about personal responsibility? The Android permission model is quite opaque to most users, it's true, but there are some basic precautions users can take.

I was recently hit by a "drive by installation". A malicious website automatically downloaded an app to my Android phone. When I clicked on it to install, this is what I got:

Legit App Permissions

If you think a Battery app needs all those permissions... I'm not sure encasing you in bubble-wrap is enough to keep you safe from yourself!

The price of freedom is eternal vigilance. Android needs to do more to allow users to enjoy their freedom.

Going down the Symbian path of insisting every app be signed by a third party and repetitively interrupting the user is probably not the right way to do things. What is clear from the current crop of malware is that simply telling the user of the permissions an app is requesting at installation time is insufficient.

Until Google makes things better for its users, it's worth installing an app like Permissions Denied which will allow you to see which apps have more access than they need - and restrict them if necessary.

Why Aren't Terrorists Bombing Queues?

In 2010 I wrote a blog post called "Why Aren't Terrorists Bombing the Queues?" - but I chickened out of publishing it.

Bombing a plane is hard, you have to buy a ticket, get past airport security, detonate it at just the right time, etc. By comparison, anyone can walk into a busy airport - say during the school holidays - wait for the shear number of people to build up, and then...

But it doesn't happen. Why not?

My conclusion, such as it was, is that either terrorists are particularly stupid, or bombs are too hard to build, or that the Government frequently foils such attacks, or - perhaps - there just aren't that many people interested in causing indiscriminate carnage.

There are so many large gatherings of people every day, and explosives are relatively easy to build, and there are so few (public) convictions for terror related offences, that the only real conclusion must be that people - in the main - are good.

Wanton destruction, untargeted menace, and psychopathic levels of violence are so uncommon that, when they do happen, their significance is artificially raised within our society to a level which is unwarranted.

As Bruce Schneier says in his book Liars and Outliers

The Virginia Tech massacre is precisely the sort of event we humans tend to overreact to. Our brains aren't very good at probability and risk analysis, especially when it comes to rare occurrences. We tend to exaggerate spectacular, strange and rare events, and downplay ordinary, familiar and common ones. There's a lot of research in the psychological community about how the brain responds to risk -- some of it I have already written about -- but the gist is this: Our brains are much better at processing the simple risks we've had to deal with throughout most of our species' existence, and much poorer at evaluating the complex risks society forces us to face today.

Novelty plus dread equals overreaction.

If you want to do something that makes security sense, figure out what's common among a bunch of rare events, and concentrate your countermeasures there. Focus on the general risk of terrorism, and not the specific threat of airplane bombings using liquid explosives. Focus on the general risk of troubled young adults, and not the specific threat of a lone gunman wandering around a college campus. Ignore the movie-plot threats, and concentrate on the real risks.

We don't know yet the cause of the Boston Marathon bombings, but we owe it to the victims and to ourselves not to over-react. A disproportionate response to rare events could end up being far worse than the terror it is trying to prevent.

New! Samsung Security Flaw - Disable Lockscreen - Total Control

I have discovered another security flaw in Samsung Android phones. It is possible to completely disable the lock screen and get access to any app - even when the phone is "securely" locked with a pattern, PIN, password, or face detection. Unlike another recently released flaw, this doesn't rely quite so heavily on ultra-precise timing.

Video.

Of course, if you are unable to download a screen unlocker, this security vulnerability still allows you to dial any phone number and run any app!

HOWTO

  1. From the lock screen, hit the emergency call button.
  2. Dial a non-existent emergency services number - e.g. 0.
  3. Press the green dial icon.
  4. Dismiss the error message.
  5. Press the phone's back button.
  6. The app's screen will be briefly displayed.
  7. This is just about long enough to interact with the app.
  8. Using this, you can run and interact with any app / widget / settings menu.
  9. You can also use this to launch the dialler.
  10. From there, you can dial any phone number (one digit at a time) and place a phone call.
  11. With Google Play, you can search for apps using the voice interface.
  12. You can download apps from the app store which will disable the screen lock.

Impact

This does not occur on stock Android from Google. This flaw only seems to be present on Samsung's version of Android. I have only tested it on a Galaxy Note II running 4.1.2 - I believe it should work on Samsung Galaxy SIII. It may work on other devices from Samsung.

My test phone was running 4.1.2 with the Touchwiz launcher from Samsung.

Defending Against This Attack

Until Samsung release a patch, the only way this can be defended against is by completely removing the Samsung firmware and replacing it with a 3rd party ROM.
This ROM for the Galaxy S III claims to have fixed the problem.
I'm sure there will be ROMs for other Galaxy devices in due course.

UPDATE 2013-03-20T16:54:12+00:00

YouTube user "bicecream88" has alerted me to a way to partially defend against this attack.
By disabling your screen animations, it is possible to reduce the amount of time the screen is displayed.

Settings -> Developer Options -> Window animation scale -> off

Repeat for Transition animation scale and Animator duration scale.

The vulnerability is still present - but you need to be a lot quicker in order to exploit it.

Responsible Disclosure

I reported this flaw to Samsung in late February. They are working on a patch which they assure me will be released shortly.
I have delayed public disclosure of this vulnerability. I also asked if they wanted me to delay publication until a patch was ready - however they declined this offer.

If you discover a security issue with Samsung's mobile products, I strongly encourage you to email m.security AT samsung.com

They will provide their PGP public key if you wish to ensure your communications with them are secure.

Thanks

My thanks to Thang Chien of Vietnam, who first demonstrated a variant of this flaw in January.

Thanks also to David Rogers, Marc Rogers, Alec Muffett, and Glyn Wintle for their wisdom and advice around the subject of responsible disclosure. Any faults with this disclosure are mine and mine alone.

Samsung Lock Screen Security Flaw

Here's a rather nifty security flaw I discovered on Samsung's Android 4.1.2. It allows you - in limited circumstances - to run apps and dial numbers even when the device is locked.

Video:

This attack works against Pattern Lock, PIN, Password, and Face Unlock. There is no way to secure your phone against your home screen being accessed.

Notes

HOWTO

  1. Lock the device with a "secure" pattern, PIN, or password.
  2. Activate the screen.
  3. Press "Emergency Call".
  4. Press the "ICE" button on the bottom left.
  5. Hold down the physical home key for a few seconds and then release.
  6. The phone's home screen will be displayed - briefly.
  7. While the home screen is displayed, click on an app or a widget.
  8. The app or widget will launch.
  9. If the widget is "direct dial" the phone will start ringing.

Limited Scope

It's true, this attack is of limited value. That's one of the reasons why I've disclosed it.

Making a call relies on the phone having a direct dial widget on the home screen.

Running the apps is also of limited use - they go into the background immediately. If the app performs an action on launch (like recording from the microphone, switching on the flash, playing music, interacting with a server) that action will occur.

There is also the privacy concern that an attacker could see what apps you have installed on your homescreen - or see your calendar / emails if you use a widget which displays them.

Rapidly tapping the home button will - depending on your launcher - allow you to see what is on every home screen. Using an external video camera you should be able to clearly see all the user's calender & email widgets if they have enabled them.

Target

I've only tried this on one class of handset. Galaxy Note II N7100. Running 4.1.2 - the latest UK variant.
The two devices both ran the stock launcher and lock screen.
One device was rooted - the other was factory fresh.

I have not tested on any other devices.

Defending Yourself

This attack works against Pattern Lock, PIN, Password, and Face Unlock. There is no way to secure your phone against your home screen being accessed.

Your options are:

  • Do not use direct dial widgets on your homescreen.
  • Remove any calendar or email widgets which may show sensitive information from your homescreens.
  • Ensure that any apps which you do have on your homescreens do not automatically cost you money or act maliciously when launched.
  • Use an app locker to prompt for a password when apps are launched.
  • Changing to a different launcher will not protect you.
  • Using a 3rd party lock screen will not protect you if it accesses the emergency dialer.

Responsible Disclosure

Samsung don't have a dedicated responsible disclosure team. Nor do they offer a bug bounty.
The nearest I've found is this unlisted email address.


i don't find this anywhere publicly, but actually #samsung's mobile devision has a #security point of contact by now: samsung.com">m.security@samsung.com
12/09/2012 21:34 via webReplyRetweetFavorite
@iamnion
Nico Golde

I spoke to several external security people, and Samsung relationship managers within the industry, who have raised the issue directly with Samsung. I also tried emailing Samsung directly. I know that people within Samsung have been made aware of this bug.

Despite that, five days later, and Samsung's security team have not made any contact with me to discuss this bug or its disclosure.
I wonder if this is typical of Samsung's attitude towards their customers and the industry in general? Do they believe that if they ignore problems, they will disappear?

Conclusion

Samsung have a really poor record on Android security. Avoid purchasing their phones at all costs.