Tuesday, 6 March 2018

HTTP is dead, long live HTTPS

"FTP is deprecated, HTTP is deprecated, at least it should be now that we have secure replacements"

Really not sure where I read that quote. One of the traps of being in the industry so long. It might have been on a security mailing list back in the early naughties. I remember vehemently nodding in agreement... I've been sad for years that my own site was still not running SSL/TLS. I've endeavored a number of times to get it up to HTTPS. But see I am cheap, and I use Bloggers free service for my domain (blogger for your domain), so HTTPS wasn't available.
Well it is now, and I thought I'd do a quick how to, for those that also have blogger.

It is really simple, like blogger has been for all those years. But it looks to be a beta feature (how long did google stay in beta for...). So you need to visit https://draft.blogger.com. If you are already logged in to blogger, you'll be logged in here too.

Now simply click on settings and scroll down to the HTTPS section. Change the first drop-down to: "Yes".
Now wait about 20minutes as google generate you a https://letsencrypt.org certificate and apply it your site. Come back to this section and change the HTTPS redirect to "Yes" as well. And if like me you have multiple blogs, go through each and change them all to the same.

Obviously not a super technical post this time, but good to see even free (as in beer) services get security features of sorts.
Of course, if you have any other kind of hosting, get a letsencrypt cert and use it, the future is encrypted.

Wednesday, 28 June 2017

Ransomware to make money?

Ransomware can be used to make money, no hear me out. Ransomware as a vector to make money... no it is not what you think.
So the latest ransomware(s) are doing the rounds after the horror that was Wannacry, we now have Petya (sorry this went active months ago), NotPetya and GoldenEye all go active overnight. Petya has been around a while but the new ones uses the same vulnerability WannaCry did (EternalBlue), plus they now steal local credentials and re-use them to infect PC's across the network and world that use the same credentials, regardless of their patch level. These viruses have been seen on everything from Point of sale systems in the Ukraine to chocolate factories (seriously chocolate, do beer next and watch Australians find you, and tear you limb from limb).

Anyway, so ransomware often holds your files at ransom by encrypting them with a key only the attackers know. They ransom your files asking for payment in the somewhat untraceable Crypt-currency called bitcoin (BTC). Bitcoin can be traded in online markets for real money. Only issue is, they never get much. You can actually tell by looking at the digital wallets connected to the ransomware (amount as of 28/07);

Petya(original from March)   .0002btc US$0.50 (FAIL)
NotPetya 3.39btc ~US$9,000
GoldenEye 0btc US$0 (early days yet, and maybe the same wallet as NotPetya)
WannaCry had loads of wallets; First one 17.5btc ~US$45,000, Second one 19.75btc ~US$50,000, third one 14.4btc ~US$36,000. Total of around 150,000 in total earnings. Thanks to https://twitter.com/actual_ransom.

So why do they do this, they don't actually make an amount equal to the development time or disruption they cause. I've thought about this a lot. Surely there are better ways to make money. One virus (Adylkuzz) was recently found that also used the same vulnerability WannaCry did. However Adylkuzz sat silently on the PC it infected slowly infecting others... and mining a different Crypt-currency called Monero. Now that is a much smarter long term money maker.
Proofpoint have a good breakdown of Adylkuzz here and as of the 15th of May, likely only a few weeks into their virus mining crypt-currency, they had around US$50,000. This is important as the mining crypt-currency takes time. Sorry I can't link directly to the wallets, as Monero doesn't work like Bitcoin in this regard. They seem to be using lots of Monero wallets too, so they are likely making a lot more.

This mining by malware I thought was an interesting method, though it isn't making them millionaires it is still a slow steady source of money.

The Bitcoin wallets used for the ransomware don't seem to make much, not for the effort put in to code and distribute their malware. No the bad guys are performing, I think, a writ-large pump and dump scheme.
Bitcoin has gone from around US$500 a year ago to US$2500 as of writing this. It is slated to get to US$5000 by end of year. In fact if you look at the spikes they have almost always coincided with ransomware releases, some spikes have gone before the malware hit, perhaps indicating a buying frenzy of knowledgeable parties.

Care of Coindesk

Combine this with some companies speculatively buying bitcoin in case they get ransomware (as reported on the risky business podcast), and other people buying simply due to the value increasing and you have yourself a criminal led massive pump and dump scam.
The criminals probably bought and mined bitcoin years ago, and are sitting on it. They then pump the demand and thus the price up by doing these virus releases, selling them as ransomware as a service to unsuspecting clients... then the price rises and rises... then they sell out all their bitcoin. The market crashes... but they have millions. Better yet their bitcoin wallets are not in anyway related to the ransomware transactions so it becomes difficult to catch them, apart from the usual untraceable nature of bitcoin transactions.

So there you have it, don't play into their game... maybe, or if you do jump out before the bad guys dump out and kill the market, good luck with that.

Oh and protect yourself from this an all other ransomware by doing backups, not opening files from people you don't know, removing admin rights, making the admin password unique per machine, and maybe even rolling app white-listing into your environment.

In this particular instance;
Patch WindowsXP+ against MS17-010
Create the file c:\windows\perfc as per this
The LAPS tool from is free from MS and should be investigated and used to ensure unique passwords on all domain joined computers.
Add perfc.dat and PSEXEC.EXE to your app whitelisting to be denied as per https://twitter.com/HackingDave/status/879779361364357121

Saturday, 16 January 2016

2015 Vulnerabilities - Android VS IOS (iPhone OS)

This is the second post on from http://security.morganstorey.com/2016/01/2015-vulnerabilities-windows7-vs-macosx.html

I was sent this interesting article; http://venturebeat.com/2015/12/31/software-with-the-most-vulnerabilities-in-2015-mac-os-x-ios-and-flash/

So I hate Apple, but in the last analysis I did I found that OSX wasn't actually that bad compared to Microsofts most popular OS at the moment Windows7, I would have to say on par, go to the link at the top to read this. This time I am similarly analysing Google's Android and Apple's iPhone OS(IOS).
Now to precursor this, I am almost an Android fanboi, I have android tablets (4 at last count, 3 from dx.com that all died), and my although my first smartphone was Symbian, all since have been Android. My kids do have iPads and my wife does have an iPhone though, but this is more for the apps available. There are things on both platforms that I wish the other would do, but Android is far and away more flexible, but like last time... don't get me started on my Apple-hate.

Now onto the Andorid/IOS analysis, as I started with MS last time, I'll start with Android this time.

Google's Android (as opposed the Motorola version that is listed at CVEDetails) had 130 vulnerabilities in 2015. With an average across those vulnerabilities of 8.37 (seems a bit high), standard deviation was 2.23. If we then round all the scores (down if they are .4 and below, up if they are .5 and above we get the below);

This shows there are an awful lot of vulnerabilities ranked at the ominous CVSS score of 10. Not many of these are going to be third party vendors as they don't really allow third party code to hook into the OS like desktop OS's.
But I did find the almost obligatory Adobe Flash vulnerabilities in there. 21 of the 61 CVSS 10's were flash, good thing Google dropped it from their 4.1 (KitKat) release of the OS... an OS released 4 and a half years ago. So I don't think these should be included, still an awful lot of CVSS score 10's lets look at some.

In case you didn't know this is the decade where security researchers learned some marketing, and started to brand their discoveries with cool names and logos like heartbleed. Well Stagefright was a bug of this ilk that was actually a big deal on Android. Patched no less than 38 times, of these 49

With words like libstagefright (where the bug got its name), MPEG4Extractor, Skia, Sonivox and mediaserver these are all related to stagefright, in fact of the CVSS 10 bugs remaining after Adobe and Stagefright there seems to be only one CVE-2015-1474.
Here are two examples of some obscurely described but Stagefright related bugs;

libutils in Android before 5.1.1 LMY48X and 6.0 before 2015-11-01 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted audio file, aka internal bug 22953624.

The Parse_wave function in arm-wt-22k/lib_src/eas_mdls.c in the Sonivox DLS-to-EAS converter in Android before 5.1.1 LMY48I does not reject a negative value for a certain size field, which allows remote attackers to execute arbitrary code or cause a denial of service (buffer overflow) via crafted XMF data, aka internal bug 21132860.

Interestingly three CVE-2014's (7915, 7916 and 7917) exist on this list, all related to stagefright. I believe these CVE id's were allocated prior to the bugs disclosure.

So the only non-Adobe, non-stagefright bug was;
Multiple integer overflows in the GraphicBuffer::unflatten function in platform/frameworks/native/libs/ui/GraphicBuffer.cpp in Android through 5.0 allow attackers to gain privileges or cause a denial of service (memory corruption) via vectors that trigger a large number of (1) file descriptors or (2) integer values.A pretty nasty one, allows a malicious app to escalate its privileges via the graphic buffer, though not remote exploitation. Essentially if a user installs a dodgy app they could give a bad guy access to more than they should.

Pretty sure all those Adobe bugs shouldn't be in there to be fair. And they probably should have fixed the stagefright bug in one go, but I guess it was a pervasive library, hence all the issues found and fixed.
Stagefright was pretty bad, it essentially meant with the right media file (audio on a webpage for example or the proof of concept MMS attachment), it could get your phone to run a command. So it is remote code execution, the ultimate vulnerability for any OS. But it was specific, you needed to know the app the user was opening your media file in, to be sure it used the library. I think it does deserve the CVSS score of 10, not sure about the adobe ones though seeing as most androids don't run it anymore.

On to iPhone OS (IOS)

IOS had a whopping 375 vulnerabilities last year. With a much lower average than Andorids at 6.13 (versus Android 8.37). It's standard deviation was also smaller at 1.82. This is probably due to the 61 CVSS 10's that android had. Lets have a look at the graph;

Interestingly there are a tonne of CVSS 7's there, a lot of those were a vulnerability in Webkit (Apple Safari) that allowed a remote attacker to crash the app with a specially crafted website. I am sure this probably allows the attacker to run code too, so it should probably be higher... Most denial of services if done right end in compromise, but anyway.

I'll have a look at some of the more interesting CVSS 10 rated vulnerabilities.

The kernel in Apple iOS before 9.1 and OS X before 10.11.1 does not initialize an unspecified data structure, which allows remote attackers to execute arbitrary code via vectors involving an unknown network-connectivity requirement.
This one looks particularity nasty, and also affected OSX and I mentioned it in the other post. Definitely worthy of its 10 score. On a mobile this could be very bad if the "unknown network-connectivity" included something sent over say the GSM cellular network.

The kernel in Apple iOS before 8.1.3, Apple OS X before 10.10.2, and Apple TV before 7.0.3 does not enforce the read-only attribute of a shared memory segment during use of a custom cache mode, which allows attackers to bypass intended access restrictions via a crafted app.

This one I didn't mention in the other post, but it isn't that bad. It essentially allows an application already on the phone or Mac to read memory it shouldn't be able to, this could allow this app to escalate permissions or disable some other security measure. I'd give this a solid 9, but 10 seems high.

Directory traversal vulnerability in afc in AppleFileConduit in Apple iOS before 8.1.3 and Apple TV before 7.0.3 allows attackers to access unintended filesystem locations by creating a symlink.
This one seems to be IOS/AppleTV only, which is interesting. Accessing locations just by creating a symlink is pretty cool. Not remotely exploitable, but could help out a bad guy already on a system. Again I don't think it is a 9, perhaps marked too harsh.

As with the other post, even though IOS has more bugs than Android, it isn't the number of bugs that matter so much, it is type and quality. Android has a higher average and a lot more rated 10's, with this all in account it is a pretty even match.
Yes Safari is insecure, stagefright was a big stuff up, flash and reader are terrible, but the OS's themselves seem to be pretty much on par.

Thanks to CVEdetails for their site and access to the list of vulnerabilities. The compiled spreadsheet is here, under fair use.

Feel like donating to me, Bitcoin; 1BASSxgFZ2j8VfXFrWJHNvYdQXDtJKAUuN or Ethererum; 0x2887D4B4fe1a7162D260CeA7E1131AF8926bd87F