Saturday, 16 August 2014

Playing with google

So I was recently having a discussion with a vendor about the insecurity versus usability of the google play store, yep there is malware there, yep there are copycat scam apps. But google will eventually get it under control, just as apple has done...

Ok so you can't trust either of them, but I think Apple is actually doing a better job of keeping the look-a-like scam apps out, at least I haven't heard of any yet, and this is coming from me a very anti-apple person.

So what do you do if you have written an Android app. Well you could host it on your own site, but then you need to reduce your customers security by making them set their device to allowing apps be installed from anywhere, opening them up to drive by downloads that are becomming prevelent in Android land (mainly due to some manufacturers enabling this setting by default).
You could host a QR code on your site and point this to your play store app...

Maybe just a link on your site back to the play store to ensure they get the right version of the app.

This got me thinking, it doesn't really protect you from those that just look through the store for apps from your company, so you should protect yourself in some other way. I use google alerts already to monitor stuff I am interested in, as well as comments about things I am interested in for security reasons.

This is where I thought I could make a search alert for: appname
I wanted to try it out first, so I did: commbank
Commbank is a big bank in Australia, and they have a few apps, one caught my attention;
Looks to me like Commbank trust the store so much they trust a third party to put up an app for them for their users to access the intranet. The company that listed the app at time of writing was who's site looks like it is what is being loaded for the app;

The domain was suspiciously registered on the 28th of January this year.
I might need to reinstall this app and do a packet capture to see what web services it is trying to hit on this site, but this site is not https, and is hosted on a shared host that has unencrypted ftp, smtp and imap enabled. I let someone I have met from Commbank's IT security team know and this was all amazingly fixed within a few hours. Props to them.
I did a packet capture post their fixes and it is all over ssl/tls now.

So anyway I guess the take-a-way is, if you want to add some security even for google play apps, you can setup a google alerts at and do one for appname set it for As-it-happens and hope you never get that email.

Monday, 7 April 2014

Service hiding/protection

This is a bit of operational security, but it took me a lot longer than I would have liked to do, and no one had an example like the below. This command will use the open source Access control list command line utility SetACL to lockdown a service so that the user specified can't stop or start it, on testing it is even better than that the service dissapears from the services manager.

setacl.exe -ot srv -on "Service Name" -ace "n:domain\username;p:start_stop;m:deny" -actn ace

This is obviously a really good idea if you have admins of a box that you don't want to be able to stop a key service, it could also allow you to stop a malicious user from seeing a specific service, depending on the malicious users method of getting onto your server.

Monday, 25 November 2013

Password Hints

OK let me preface this by saying this: I absolutely hate password hints and secret questions. Generally speaking anything you put in there can be found by friending someone on facebook, a quick google or simply guessing. They are the epitome of a bad idea, sure they have some use. If you forget your password the hint if constructed correctly could remind you and only you, however most people don't understand this.
If it is a secret question an answer, where the question is predefined such as mothers maiden name, it can take a few guesses (smith anyone), or a quick search and you will have it. Everything else is trivial, and this was how Sarah Palin's yahoo email account was humorously compromised back in 2008.

Forgetting all that, adobe gave us another insight as to why it is bad.

I know a lot has been said about adobe, including the excellent (although conservative number of users impacted) article by Brian Krebs here.

But there is something else that needs to be learnt from this breach.
Sure your password hint could be terrible but maybe the web application logs someones IP when they go to that for later alerting etc if a bad guy does compromise the account. But what if the DB gets walked, and all those juicy password hints or secret questions and answers are stored in plain text... then you have a problem even if you correctly store you passwords (which adobe didn't).

So lets say you do correctly store your password as a per-user salted sha1+ hash, good, but now you allow users to have a password hint like adobe. When someone has their password hint as their password in another language then they fail very quickly. For example (this is not a real entry, but made to look like one from the adobe breach);

78114563-|--||-BsscHGd8aIjiwxG2CaWrHSw==-|-Gato x3|--

If we forgive the obviously non-hashed password in the 4th column, we see in the last column the password hint is simply Gato x3, or you know maybe Cat typed out three times. So even if this entry had an irreversible hashed password, the hint would give it all away if the DB where accessed.
Maybe they should instead store their hint as a reversible encrypted string with an individual key for each user. This would mean the server when the user wants to use their password hint would look up the key from the internally accessible internal key server for the username and decrypt the hint. It would mean if the db is walked via an SQL injection or direct attack they aren't necessarily going to get the keys to decrypt the password hint. For a secret question and answer, you should salt and hash the answer and if you are using user defined questions you should encrypt those too just to reduce what is leaked...

Using an encrypted password with the same decryption key for all users or using an unsalted hash means that the resulting password string whether it is BsscHGd8aIjiwxG2CaWrHSw== or 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8 will be the same across all users meaning if you break one you break them all, the same goes for your password hint or secret question and answer should people take my advice and start encrypting them.

Of course all of this only works if you care about security, if you aren't going to hash your passwords, or worse store them in plain text as Cupid Media did then you probably don't care about users password hints, and will probably store them in plain text.
Realistically no-one has any excuse now, google authenticator for two factor has been open sourced, OpenID, SAML can be used to authenticate you to a central store and then you are done, like UbuntuForums did post their breach moving to UbuntuOne the openID provier. People like adobe should really switch to one of these, to reduce their authentication load. The users should be forced at these central providers to 2-factor auth. If you forget your password at one of these central providers then you have a convoluted way to retrieve it via out of band identification, via either partnership with a bank or other multi-vendor approach, eg go into these news agencies and show 100 points of ID to get your password reset.

My point I am trying to make is this, if it is used for authentication it should be encrypted, preferably and sufficiently strong hash (SHA1 or greater) that is salted. Nothing but the username and row ID of your authentication table should be plain text. It is only a matter of time before these passwords in the 10gb adobe database are broken and the key used to decrypt them is found, if it hasn't happened already.

Add these ~130million adobe accounts with the 42million from the Cupid Media and I think we should declare this month, change password November, I know the few sites that used the same password as my account on adobe have now all been changed, have yours? If you use the same password everywhere, then now is the time to look at keepass or lastpass to store your single use passwords in a manner that allows for your protection. Heck even Google's Chrome and Firefox have built in password managers with cloud sync and encryption, so there really is no excuse.