Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.
Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.
Already using Google+? Find us on Google+ for the latest security news.
On March 26th, the Inspector General released a report on the effects of BYOD (bring your own device) on the U.S. military.
Among the report's findings:
Mobile devices were not secured to protect stored information.The US Department of Defense (DOD) did not have ability to wipe devices that were lost or stolen.Sensitive data was allowed to be stored on commercial mobile devices acting as removable media.DOD did not train users and did not have them sign user agreements.The Army CIO was unaware of more than 14,000 mobile devices used throughout the Army.
Ouch.
This from an entity that seems to have policies and regulations for everything.
The Army did implement a good policy regarding geotagging a while back, realizing the risk that came with soldiers taking pictures that automatically had location information embedded in metadata.
However, given the lack of management of the devices, how would the military know for sure that the geotagging has been disabled?
And if the United States Army, with all the endless policies, is having a difficult time with BYOD, how is a small or medium-sized business going to cope?
Why does this all matter?
Answer: Data loss. Stolen data is massive business for the bad guys. A phone left in a cab or at an airport can be a goldmine of sensitive information. Consider the case of the US Secret Service contractor who left two tapes of sensitive data on the DC Metro train.
What crook wouldn't have loved to have gotten a hold of two databases full of juicy personal information of agency employees, contractors and possibly informants? It's just another example that even the most "security conscious" people have forgetful moments, or moments of distraction and can easily leave something behind.
Last year, Sophos did an informal study and found that 42% of lost mobile devices aren't protected with any security measures.
Now of that number, 20% had access to business email, which could contain confidential information. Small businesses are even more at risk - just because you are small doesn't make you less of a target.
We have written several articles about handling smartphones in a business before and have provided some sage advice within about how to implement BYOD, but how do you create a BYOD policy?
Where's the best place to start? Sophos CTO Gerhard Eschelbeck outlines the following tips in a recent whitepaper.
7 steps to a BYOD security plan
Identify the risk elements that BYOD introduces. Measure how the risk can impact your business and map the risk elements to regulations, where applicable.Form a committee to embrace BYOD and understand the risks, including business stakeholders, IT stakeholders and information security stakeholders.Decide how to enforce policies for any and all devices connecting to your network including mobile devices (smartphones), tablets (e.g., iPad) and portable computers (laptops, netbooks, ultrabooks).Build a project plan to include these capabilities: Remote device managementApplication controlPolicy compliance and audit reportsData and device encryptionAugmenting cloud storage securityWiping devices when retiredRevoking access to devices when end-user relationship changes from employee to guestRevoking access to devices when employees are terminated by the companyEvaluate solutions. Consider the impact on your existing network and how to enhance existing technologies prior to next step.Implement solutions. Begin with a pilot group from each of the stakeholders' departments. Expand pilot to departments based on your organizational criteria. Open BYOD program to all employees.Periodically reassess solutions. Include vendors and trusted advisors. Look at roadmaps entering your next assessment period. Consider cost-saving group plans if practical.
Regardless of how big or small your 'army', securing your organization's devices and the data on those devices is at the front line of maintaining a strong IT security defense.
Follow @SophosLabs Follow @NakedSecurity
Smartphone map and mobile note images from Shutterstock
Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.
Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.
Already using Google+? Find us on Google+ for the latest security news.
Every few years, someone reads, or remembers, or rediscovers something we often forget: computer memory isn't volatile, after all.
RAM chips don't lose their contents immediately when you turn your computer off, and that can have interesting security ramifications.
Don't get too excited: RAM contents don't persist without power in a reliable and consistent way.
If you accidentally pull the plug out of the wall before you've saved that fantastic new presentation, don't expect to get it back.
But if you can cycle the power quickly enough, and reboot under your own control from some secondary device, such as a USB key, you might be able to see the ghostly remnants of what the previously-running operating system was up to.
You can guess where this is going.
If you clean boot a computer with a hard disk that's running full disk encryption, or FDE, you can't get anything off it.
Not just the data, but also the operating system, swap and hibernation files are scrambled. Nothing can be accessed without the decryption key.
But what if the decryption key, or a large enough chunk of it, is part of the RAM that didn't fade to grey when you cycled the power?
That can happen, thanks to the phenomenon of left-behind data in RAM.
(The name you'll hear is remanence, a word originally used for residual magnetic fields, and now also used to refer to the not-yet-decayed electrical charge in memory chips.)
And if you cut the power abruptly, you prevent the operating system from taking any emergency shutdown measures, such as deliberately purging critical areas of memory to wipe any active encryption keys.
The latest researchers to rediscover remanence in a newsworthy way are from FAU, the Friedrich-Alexander Universität Erlangen-Nürnberg.
They've turned their sights on Android, building a custom distro of Android Linux called FROST, short for Forensic Recovery Of Scrambled Telephones.
So far, they've only tried it on the Samsung Nexus phone from Google.
That's because they need three planets to align before the attack will even begin to work:
The bootloader needs to be unlocked.The device needs an easily-removable battery.Ideally, the device needs to be at or close to 0°C.
The reason for these limitations are the things that go wrong if they aren't in place.
If the RAM is at room temperature, its remanence is greatly reduced, so it "forgets" much more quickly.
If you can't get at the battery, you can't easily cycle the power abruptly.
If the bootloader is locked, the device will automatically get wiped if you try to unlock it.
The wipe-on-unlock feature is a clean and simple security process enforced by Google, at least on recent devices.
? Android devices support a stripped-down mode called FASTBOOT, which gets its name because it boots up your device in a second or two. A magic chord of keys pressed down at power-up is typically used when you want to engage FASTBOOT's services. It has very limited functionality, but the key features are that it allows you to unlock your firmware, and to reflash it. Locked firmware can't be flashed, for security reasons, and unlocking (assuming your device allows it) it will wipe the device so that your freedom to reflash doesn't come at the previous owner's expense.
The first thing you need to do, when you rediscover remanence and want to use it against a specific device, is to find out if your proposed attack is practicable.
That means loading up memory with something you'll easily find and recognise later, and seeing how well your chosen content survives a power outage.
When a posse of Princeton programmers famously brought remanence into the limelight back in 2008, they used images of Mona Lisa.
The FROST crew picked a more modern mascot, Google's Android robot:
The results weren't terribly convincing at room temperature, given that rebooting the phone quickly by jiggling the battery takes an unpredictable time.
Lowering the temperatures offered improved results, as the authors showed graphically:
(They neglected to label the axes, a peccadillo usually restricted to marketing departments, so we'll have to assume that the X-axis shows reboot time in seconds, and the Y-axis shows the percentage of bits lost. The obvious conclusion: take less than a second, and head towards freezing point.)
The authors eventually settled on popping the target phone in a freezer at -15°C for an hour. They laconically point out that they can't promise you that your phone will survive, noting that "damaging the phone is your own risk, but we haven't experienced any problems yet."
? A word of warning. If you live somewhere warm and humid, such as Singapore, Dar es Salaam or Brisbane, your phone will rapidly start to collect moisture when you remove it from the freezer. If you're fiddling with the battery and the buttons of your phone to try to orchestrate this attack, you won't be able to dry it off as you go along. As the FROSTers say, damaging the phone is your own risk.
To find the FDE decryption keys in memory (Android uses AES encryption), the authors used a modified version of a program called aeskeyfind, originally created for the 2008 paper referenced above.
This cleverly-written tool uses a variety of heuristics to churn through memory, looking for contiguous blocks of RAM that look like the output of the AES key schedule.
This is the algorithm that AES uses at the outset to convert a 128-bit key into 176 bytes of key material to use in the AES process itself, or a 256-bit key into 240 bytes.
And now the burning question. Did the FROSTERs succeed?
Sort-of. They've got some visual material that suggests they did, though whether the key information was actually enough to unscramble the encrypted data on the phone is not specified.
The paper is similarly ambiguous, saying somewhat noncommittally that the authors were "able to recover the disk encryption keys (given that no or only a few bits were decayed)."
That's a bit like saying that "we came out ahead financially every time we placed a winning bet." It doesn't tell us much about the practicability of the attack in real life.
Nevertheless, the FROST paper teaches, nay proves, an important lesson:
If you have an Android phone with an unlockable bootloader, LOCK IT AGAIN WHEN YOU'RE DONE REFLASHING.
The authors are unequivocal about this.
When they needed to unlock the bootloader to try to attack an encrypted phone, they ended up with nothing to decrypt.
Oh, and if you pick up your phone to make a call and it seems unusually cold against your ear, look out!
Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.
Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.
Already using Google+? Find us on Google+ for the latest security news.
Hackers have published a collection of what they say is over a million Unique Device Identifiers (UDID), connected with Apple iPhones and iPads.
The data, claims the hackers, is just part of a larger database of 12,367,232 UDIDs, and personal information such as full names, cellphone numbers, addresses and zipcodes belonging to Apple customers. The data was allegedly stolen via a Java vulnerability from a laptop belonging to an FBI cybersecurity agent:
"During the second week of March 2012, a Dell Vostro notebook, used by Supervisor Special Agent Christopher K. Stangl from FBI Regional Cyber Action Team and New York FBI Office Evidence Response Team was breached using the AtomicReferenceArray vulnerability on Java, during the shell session some files were downloaded from his Desktop folder one of them with the name of ”NCFTA_iOS_devices_intel.csv” turned to be a list of 12,367,232 Apple iOS devices including Unique Device Identifiers (UDID), user names, name of device, type of device, Apple Push Notification Service tokens, zipcodes, cellphone numbers, addresses, etc. the personal details fields referring to people appears many times empty leaving the whole list incompleted on many parts. no other file on the same folder makes mention about this list or its purpose."
Quite why the FBI was collecting the UDIDs and personal information of millions of iPhone and iPad users is not yet clear - but it's obvious that the data (and the computer it was apparently stored on) was not adequately secured.
I suppose we should be pleased that the hackers have not, as yet, published the majority of the information they claim to have purloined from the FBI though the hack - including the personal information about members of the public.
As such, my suspicion is that the hackers were more interested in embarrassing the FBI's team than endangering innocent users.
All the same, hacking into computers is a criminal act - and I would anticipate that the FBI and other law enforcement agencies will be keen to hunt down those responsible.
Mitt Romney, journalists wearing tutus, and a shoe on head
If it helps cut down the number of suspects at all, here's a clue to help the FBI with their investigation.
Attached to the end of the hackers' announcement is the following phrase in German:
"Romney aber, sag's ihm, er kann mich im Arsche lecken!"
This translates into English as:
"Romney, however, tell him he can kiss the asses!"
Clearly not a fan of the Republican party then..
And someone else that the hackers aren't huge fans of is Gawker journalist Adrian Chen.
Chen has become something of a bête noire for the likes of 4Chan and Anonymous.
Whoever was responsible for the latest hack says that they will only agree to speak to the press if a photo of Chen, dressed as a ballerina with a shoe on his head, is published on the main page of Gawker.
The whole "shoe on the head" thing is a 4Chan meme - victims are told they have to take a photograph of themselves wearing a shoe on their head for the amusement of hackers.
Whatever tickles your fancy I suppose..
Follow @gcluley
Tags: Adrian Chen, anonymous, antisec, Apple, Christopher Stangl, FBI, hacking, iPad, iPhone, Java, LulzSec, UDID, vulnerability
However, given the lack of management of the devices, how would the military know for sure that the geotagging has been disabled? 
7 steps to a BYOD security plan
RAM chips don't lose their contents immediately when you turn your computer off, and that can have interesting security ramifications.
If the RAM is at room temperature, its remanence is greatly reduced, so it "forgets" much more quickly.
And someone else that the hackers aren't huge fans of is Gawker journalist Adrian Chen.