Posted on

Quadrooter – major security bug in Qualcomm Android drivers

Check point software claims to have found what it calls a serious vulnerability in Qualcomm software running on LTE chip-sets used in many Android ‘phones. Apparently they informed Qualcomm about six months ago, and they’ve now modified their drivers to stop it in future, and issued patches, but I doubt many of the 900,000 of the devices already sold with the LTE chips will end up being patched. LTE is two-thirds owned by Qualcomm.

Check Point has released an App to check whether your phone is vulnerable, but it’s up to the device manufacturers to actually push the patch on to their users. The major ones may, but the majority of handsets are of the cheaper variety, sold in third world countries, and not as well supported.

Normally I’d treat stories like this with a bit of caution, and I’ve yet to fathom exactly how ti works. However, Check Point’s description is scary – and the Israeli company isn’t known for hype. Basically, the flawed Qualcomm chip-set drivers have flaws that allow a downloaded App to gain root access without the need for any unusual permissions. This is bad.

Check Points advice is to only trust Apps installed from Google Play, which is ironic given that as recently as this May they released a report saying you shouldn’t trust Apps from Google Play as too many nasty ones crept in.

Posted on

Parent Pay adds fuel to its fire

Following a disastrous software “upgrade” on 6th June, it appears that ParentPay, the controversial on-line payment system used by many schools, finally appears to have noticed it has a problem. In an email sent to all its 1.7 million victims users today, CEO Clint Wilson apologised that people were having difficulties with the new system and conceding their support service was overwhelmed. He promised to fix the problems and get it right over the summer.

Perhaps in order to emphasise the fact that he really don’t know much about this technology stuff, the email was sent in a Microsoft-only format, with an invitation to “view it in your web browser” if you weren’t using Hotmail, or whatever else it was designed for. It really doesn’t bode well.

The ParentPay website was always awkward, requiring very specific web browsers in order to operate, and using insecure technologies rather than HTML. The latest update relied very heavily on JavaScript and assumed specific screen resolutions, forcing people to upgrade browsers and wait for updates in order to use it – and it looks ridiculous on a desktop-sized screen.

At the same time ParentPay implemented a system where parents were made to pre-pay in to the account and then allocate funds later, rather than paying for the items at the time they were selected/purchased. Subsequently the company has sought to defend this tiresome system as an initiative to help low-income families, although exactly how pre-payment does this isn’t clear. The fact that ParentPay is left holding money for longer before the school gets is probably didn’t even cross their mind.

Parents, already leery about the whole ParentPay system and the way it has been imposed on them by schools in spite of widespread long-standing dissatisfaction, have taken to social media to slag off the crass software update and appalling customer service..

It’s a sad fact that schools and local authorities lack the necessary IT savvy to spot a turkey when its marching up and down in front of them, and instead opt for “safety” in numbers. I don’t actually blame the schools for this – it’s not their job. It’s the government and local authorities that are unable to provide good advice – but local authority and government IT projects are, of course, a byword for expensive shambles.

Posted on

Am I being phished?

Today I received an intriguing email with a Microsoft Word attachment implying I had money coming to me if I filled in a form. Yeah, right. I was just about to hit delete but I was a bit surprised the sender was addressing me as Prof. Leonhardt. It’s hardly the first time someone’s got this wrong – and to be on the safe side I can see why people might start high and work backwards through Dr. and so on, as people who are about such matters are only offended if you start too low.

But why would a botnet add the title?

On closer inspection I recognised it was a royalty payment enquiry from a publishing company that had actually done a book for about five years ago. I didn’t expect it to sell (it wasn’t that kind of book), so hadn’t thought much about out.

But I still haven’t opened the attachment. The email headers suggest it came from the publisher, but they can be forged. And this could be a clever spear-phishing attempt – after all, if you bought the book, which was largely about email security, you’d have the name of the publisher and my name – and the email address used can be found using Google.

I don’t believe I have ever been spear-phished before, so I’m feeling a bit more important than I did yesterday.

Time to fire up the sandbox!

Posted on

New mystery “Appear in Court” malware

In the early hours of the morning (BST) I intercepted a large number of emails of the “Appear in Court” variety, but unlike usual, these were not Microsoft documents but JavaScript (stored in a .ZIP file). They end in .doc.js, which means they obviously look odd.

I couldn’t resist running a few, to see what they did, and the answer is not much. They run cmd.exe and I’m pretty sure it does an egg hunt to find some code in core to execute, and it goes looking for DOCUME~1.DOC in various likely locations. But in my sandbox, it doesn’t get anywhere.

These are being spammed from clean IP addresses, no AV currently detects them by signature, so they’re going to get through. But what do they need to run, and what do they do if they succeed? Unfortunately I can’t stick around this morning to check further.

Posted on

Microsoft Windows Backup Dramas

brokengreenglassAlways take a backup. Everyone knows that. There are plenty of articles on the web singing the virtues of the the new (Windows 7, 8 and 10) backup utility, and how easy it is to use. But none on how to actually restore your data when things go wrong. ‘sfunny that.

A week ago, when my Windows PC decided to scramble its hard disk I felt smug for having followed my long-standing advice. I’d taken an Image Backup of the entire system disk with the applications installed, data files were shadowed on a server (FreeBSD of course) and I had last month’s “User files” Windows backup to bring the system up-to-date (the odd Windows update notwithstanding). And even better, the system was still in a condition to boot albeit with a few warnings about corrupted DLLs, none of which were important.

Ha!

The first stage in any situation like this is to make an exact copy of the trashed drive in case things go horribly wrong. This involves mounting the disk on a working system and copying the drive as data. If you;re reading this because you are having problems, but don’t have the ability to image a drive, please find someone who can do this for you. The remainder of this diatribe assumes that you either know what you’re about, or at least have a safe copy of the disk you’re about to try and resurrect.

Only when the drive is imaged and safe is it okay to to try to boot the machine and run CHKDSK.  No hardware faults were found in this case, but it fixed numerous errors in the directories and it was pretty obvious that nothing on the disk could be trusted. Windows had obviously gone ape and trashed the disk itself. so it was necessary to restore from a Backup Image to ensure the system was clean. And this is where my fun really started.

You have to reboot the PC into recovery mode (Windows RE). This is achieved by holding down a function key on boot  and selecting the “Recovery” option from possible boot disks (details vary by manufacturer), or if you’re running Windows already you can find it under Advanced Options on System Restore – it will reboot to Windows RE mode for you. Then all you need to is select the image you want to restore, which in my case was on the network, so I entered the server details and login as requested. No dice.

Re image Your Computer

An internal error occurred. The following information
might help to resolve the error:

The network location cannot be reached. For information
about network troubleshooting, see Windows Help (0x0800704CF)

The restore utility must be wrong, and a quick Google search threw up some possible explanations. In my case it was nothing to do with the file permissions; it was on a FreeBSD cluster and I’m very confident I have control over the file permissions on that.

So what next? A Windows Image backup (since Windows 7) creates a .vhd file (Virtual Hard Disk). This is Microsoft’s half-arsed equivalent to being able to mount a file as an device and then using an FS on it. You can mount (Attach) a .vhd file from the “Mange Computer” console, using menu that pops up when you right-click on the “Disk Management” part of the tree on the left, which is not obvious. (Even less obvious: to detach it you need to right-click on the left-hand area representing the drive in the partition map on the right).

So, if Windows RE couldn’t read the image across the network I decided to use Windows itself to copy the files back manually by mounting the .vhd from the backup location. This isn’t that simple; you can’t copy the OS back while it’s running so you need to boot from somewhere else before you finish the job, but its better than a poke in the eye with a sharp stick.

Again, no dice.

“This image was created by a different version of Windows”

What? No way! It was created by this version of Windows; on this PC, no less.

This may have been because, for some bonkers reason, you can’t mount a backup .vhd as read-only, at least the first time its mounted on anything. It doesn’t tell you this, it just says that its an incompatible version. You must un-check the Read-Only box; and if you’re like me, you’ll make a backup of the backup before doing this. But it still didn’t work.

I tried again with the backup .vhd I’d made, largely because it had a much shorter name, and bingo! It mounted and all my files were visible. What’s going on? It wasn’t a permissions issue – of that I’m certain. The only explanation I’ve have is that the path name was too long before, with the Microsoft names being a UUID (GUID). Try shortening the name/path if you can’t mount a .vhd.

Armed with this knowledge that the .vhd really was good, I fiddled the file names and associated links and tried Windows RE image restore again, but with the same 0x800704CF error code as a result. A bit more digging, and it turns out this means that basically the system isn’t talking to the network card, probably because there is no driver. Microsoft’s solution is to install the driver with the disk that came with the card. But this Lenovo PC came with pre-installed Windows and NIC – Microsoft doesn’t supply Windows OEM on a disk any more, never mind a driver CD. One might assume, given that Windows RE happily asked me for network credentials as I supplied it with the network address of the image, that it had the network driver pre-installed. But that would be to sensible.

Rather than messing about looking for a suitable NIC driver and burning it to a CD, I just copied the “WindowsImageBackup” folder to the root of a USB-connected and disk and it restored just fine. Actually, it only worked after I moved the USB drive from its normally USB 3 slot to a USB 2 slot, because presumably Windows RE doesn’t have a driver for USB 3 hardware either. A pattern was emerging.

The image was restored; all my software was back. The only snag is that there were more than 200 Microsoft updates; taking another four hours to install. But at least I knot it’s now a clean install, and as a reward for my hard work I was able to put put of installing the Windows 10 “upgrade” nagware (KB2952664 and KB2976978 if you’re interested – it doesn’t identify itself as such).

So what have I learned from all of this? “Don’t Trust Microsoft”? Well I haven’t trusted a Microsoft backup solution since MS-DOS 2.1, and with good reason. But from now on I’ll always take the trouble to use dd image for imaging drives in future, even if that means taking them out of the PC to do it.

Posted on

Flash Crash (Adobe version)

AGet the dobe Flash (the browser plug-in) is notorious as a security risk, and the current batch of known exploits does nothing to improve it’s reputation. Sorry Adobe.
CVE-2016-1010 is the latest biggie, as it allows remote code execution on all but the very latest plug-in. There’s also CVE-2015-8651, CVE-2015-7645, CVE-2016-0963 and CVE-2016-0993 to worry about.

You should, of course, make sure that you have the latest plugging installed on your browser. Unfortunately the version numbering system varies by platform so I can’t easily tell you which you need.

When looking at multifarious Adobe Flash vulnerabilities in the NIST database I’m always amused to note that it appears to be written in Coldfusion. For the last ten years that’s been Adobe Coldfusion. Oh my!

 

Posted on

FreeBSD sysarch kernel panic vulnerability

A bug has been found and fixed in the FreeBSD kernel that would allow someone with malicious intent to crash a running system. It’d be difficult to achieve unless the attacker had console access. However it’s been patched for all supported systems. See here for all the details (which I won’t repeat).

The problem was found by Core Security, and they have provided an excellent write-up here.

But if you want it in plain English:

The sysarch() system call is used to get/set processor-specific stuff. You’re not supposed to call it directly; you’re supposed to call a processor-specific library if you want to do things like that, but you still can call it if you want to. On processors that support memory segments, such as i386,  there is a Local Descriptor Table (LDT) to manage them if you want to mess with specific stuff like that. However, for security reasons, you can only modify the LDT using the sysarch() call, which checks what you’re trying to do and prevents applications from doing anything crazy.

Unfortunately the AMD64 implementation of the code gets the checking wrong. If you use a signed integer it’s always going to be less than another unsigned value, and when it compares the two parameters to make sure that one is less than the other it passes when it shouldn’t, and the rogue parameter causes it to go funky-deux and overwrite a shed load of stuff.

This is in all in:

/sys/amd64/amd64/sys_machdep.c

in the function:

int amd64_set_ldt(td, uap, descs)

The FreeBSD advisory contains a patch for all “supported” versions; but what if you’re using an older one? Using the information from Core it’s easy enough to patch. But what else is affected?

To save you the trouble, I’ve looked back at earlier versions. The problem code definitely exists in the AMD64 versions for 8.x, but isn’t present in any 7.x, as far as I can tell. The system call simply doesn’t exist. On i386 versions, I can’t see any obvious problem with the code.

How worried should we be? If someone breaks in to a system with shell access, they will be able to crash it. However, I think it’s very unlikely that any service is written in such a way that malicious data could cause the necessary parameters to be sent to sysarch() call. In fact, on checking the ports collection, it’s not exactly used all over the place. You’re highly unlikely to be running any application that even makes the call.

Posted on

Android Stagefright bug gets serious

AndroidLogoSThere’s a bug in all by the most recent versions of the Android operating system that can theoretically allow attackers to take over the device simply by viewing a web page or downloading a media file. It’s actually in the Stagefright library, and was the talk of Black Hat last August. Then it was considered hard to exploit, but security researcher Hanan Be’er at  North-Bit in Israel has now published a paper proving it’s very dangerous.

Stagefright is the name of the media processing library found in all versions of Android you’re likely to find. It opens and reads any media downloaded to the device. With a specially crafted file you can cause it to crash when it does this; you don’t have to even play the file. However, it has been difficult to make use of this fact to “break out” and do anything more nasty.

Since Android 5.0, a system called Address Space Layout Randomisation (ASLR) has been in use. Basically the memory space is shuffled randomly so malicious code doesn’t know where anything else is, making attacks more difficult. This made exploiting Stagefright’s flaws a lot harder. The fact that the problem exists on Android 2.2 to 4.x, which doesn’t do ASLR, has been the subject of much complacency. Google has released fixes for the bug, known as CVE-2015-3864, but by no means have all the Android devices been updated. I guess that the vast majority have not, including the recent ones using Android 5.x. The infrastructure for updating Android simply doesn’t exist. Apple’s devices are very exploitable, but at least they have a mechanism for updating them.

So how does the North-Bit exploit work? It’s actually very straightforward. First you deliver a dodgy video file to the device; putting it on a web site is the obvious, easy method. This will cause Stagefright to crash and restart in a known state. When it does this, some JavaScript running on the same page slurps various parameters on the system, such as the current location of libc, and sends it back to the attacker. A new video file is then created and sent using this information, and it’s game over – possibly after a few tries, but North-Bit says the exploit is reliable.

How worried should we be? I’d say we should be very worried. Unless your device manufacturer and/or mobile network rolls out the patch, I can’t see any mitigation.

Posted on

Apple is too cool for the CIA to touch

Tim Cook 2009 cropped
Tim Cook – time he was sent to jail?
You can’t have missed the furore over Apple’s refusal to help the CIA get the data from a terrorist murderers iPhone. On the one side the CIA says that we need the data to protect the public, a line with the judiciary of the USA agrees with, and Apple should do everything possible to get it for them. On the other side there’s Apple’s PR engine trying (successfully) to spin the story and avoid complying with the court order.

In the mean time the Brazilians haven’t shown such deference to a cultural icon when it comes to Facebook owned WhatsApp refusing to hand over data concerning a major drugs trafficker, even after several court orders. The Brazilian authorities have arrested Diego Dzodan, Facebook’s hancho in Latin America, and thrown him in jail until such time as the company obeys the law.

Perhaps he Americans could try that with Tim Cook – you break the law, you go to jail.

Meanwhile, Apple might seem to be setting itself up as the criminals friend over this. In the land of the free where profit is king, I guess their money is as good as anyone else’s so perhaps we should be too judgemental. But in an outrageous spin, Apple has told the world that if they comply with the court order then all Apple handsets will have a backdoor and no longer be secure. This is disingenuous. The situation is this:

Apple encrypts the data stored on the phone. You have to enter a password to unlock it. If you enter ten wrong passwords it will wipe the data from the phone. The CIA has asked Apple to modify this handset to disable the data wiping feature, so the CIA can then just keep throwing passwords at it until it unlocks. Clearly, this is going to have no physical effect on any other handset anywhere else in the world. So what’s Apple’s problem?

If Apple helped the CIA break in to the handset, Apple can no longer claim that its handsets are invulnerable. Terrorists, fraudsters and anyone up to something will know that the authorities can get at Apple data even more easily than if it was stored on iCloud. Note well: the fact that Apple hasn’t produced the mod needed to do this (publicly), doesn’t mean that its not possible right now; and it may even be happening. But Apple wants to maintain the illusion that it can’t.

Put another way, it’s easy enough to bypass the locks on a front door. You just need a large enough sledge hammer. Doubt this? Look at the footage of a police raid taking place – a few burly coppers with a battering ram and it’s open in seconds. Apple is selling locks and trying to pretend there’s no such thing as a sledgehammer.

So why, might one ask, don’t the US authorities stop messing around and get the court order enforced? Are they really scared of Apple?

What’s really worrying about this situation is that “civil liberties campaigners” and some corporate America is rushing to put out statements in Apple’s defence. In other words, big business reckons it’s above the law made by the people using a democratically elected government.

Posted on

Spam from the Government Secure Internet

gov.uk

Well that’s what it looks like. Criminals apparently from Bangalore have been distributing loads of malware spams from addresses like Nich***.Davi**.5208@vosa.gsi.gov.uk, and they’re getting through spam filters.

The messages continue:

 

 

 

Subject: DVSA RECEIPT

Good afternoon

Please find attached your receipt, sent as requested.

Kind regards

(See attached file)

Fixed Penalty Office
Driver and Vehicle Standards Agency | The Ellipse, Padley Road, Swansea,
SA1 8AN
Phone: 0300 123 9000



Find out more about government services at www.gov.uk/dvsa

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed.  Any views or opinions presented may be those of the
originator and do not necessarily represent those of DVSA.

If you were not the intended recipient, you have received this email and
any attached files in error; in which case any storage, use,
dissemination, forwarding, printing, or copying of this email or its
attachments is strictly prohibited.  If you have received this
communication in error please destroy all copies and notify the sender
[and postmaster@dvsa.gsi.gov.uk ] by return email.

DVSA's computer systems may be monitored and communications carried on
them recorded, to secure the effective operation of the system and for
other lawful purposes.

Nothing in this email amounts to a contractual or other legal commitment
on the part of DVSA unless confirmed by a communication signed on behalf
of the Secretary of State.

It should be noted that although DVSA makes every effort to ensure that
all emails and attachments sent by it are checked for known viruses
before transmission, it does not warrant that they are free from viruses
or other defects and accepts no liability for any losses resulting from
infected email transmission.

Visit www.gov.uk/dvsa  for information about the Driver Vehicle and Standards Agency.
*********************************************************************


The original of this email was scanned for viruses by the Government Secure Intranet virus
scanning service supplied by Vodafone in partnership with Symantec.
(CCTM Certificate Number 2009/09/0052.) This email has been certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for
legal purposes.

 

This all looks pretty genuine – they probably copied it verbatim with the exception of the “good afternoon”.

The payload is a Microsoft Word document with macros, but I’ve yet to figure out exactly what it’s doing. In the parlance of the security “industry” it’d be a zero-day exploit, but that’s not interesting. What did come as a bit of a surprise to me is that GSI doesn’t seem to bother with SPF records, which would have helped detect the fake. Bayesian analysis throws up nothing, and it’s coming from a clean IP address that has yet to be listed. The only things wrong with it are that there’s no reverse lookup, and no SPF on vosa.gsi.gov.uk to flag it as dodgy.

The civil service clearly hasn’t got this security business clear yet.