(ISC)2 Blog

Android Insecurity

Late last year, a nefarious banking app was discovered on the Android phone marketplace.  This, I'm afraid, is just the beginning.

Doing some Android phone development recently, I have gotten some hands-on experience with how an application is deployed to the Android Marketplace.  One big difference between the Google and Apple mobile software stores is that Apple vets and approves each app before it is made available for public download.  With Android, anyone who pays the $25 registration can upload an application to the marketplace.

To upload an application, it first must be signed with your own digital signature.  This signature need not be certified--you can create one yourself and it is just as valid as one issued by Verisign.  Signing your application is the only security requirement that must be met before uploading to the marketplace.  The information your submit to create your Android developer account is also not reviewed or verified. 

If your application is free, then anyone with a compatible Android phone can begin downloading and using it.  If the application needs to connect to the internet, then during the installation the user is notified "This application has access to the following:  Network communication, full Internet access," to which the user clicks OK to proceed with the install.

There are no alerts about the digital signature coming from untrusted or unknown source.  All applications are implicitly trusted.  My Android phone has 800 Mhz processor with 256MB RAM, a worth addition to any botnet. 

The current protections for mobile applications remind me of web sites in the mid to late 90s when e-commerce was just starting to get off the ground and viruses and botnets weren't daily news (and desktop PCs didn't have the same power that we now carry in our pocket.)  People just trusted anything they clicked, and bad guys realized this and quickly developed ways to exploit this blind trust.  Now that cyber crime has become much more savvy and organized, they working feverishly to exploit this new mobile vector. 

I know mobile apps still have that wow factor, but we have to learn from the past and treat all Internet enabled devices as attractive targets for attack today.  These mobile OSes need to have the same protections we apply to desktop PCs.  We should not continue blindly assuming that the focus of attack is the desktop PC and not mobile devices, even though they all have similar hardware specs and are connected to the same Internet.  Otherwise, this is security by obscurity, which does little else but to give us a false sense of security.

The Risks of Bad Communication

I have been thinking about whether there are are any risks unique to remote facilities when it comes to a company's IT security design.  This could be locations in different cities, near-shoring, off-shoring, etc.

From the article Bad Communication Can Create Risk, the author lists four risks mitigated by effective communication:

• Increased employee resignations
• Decreased employee productivity
• Overt employee subversion
• Inability to achieve company goals

From an IT security perspective, I will add:

• Back doors
• Data leakage
  
• Malicious behavior (unintentional or otherwise)

The knowledge of being observed is itself a deterrent to bad behavior.  There is the Observer (or Hawthorne) effect, which "refers to changes that the act of observing will make on the phenomenon being observed."  Distance or separation from the company could reduce efficacy of this control, and may embolden a subversive contractor or employee.

Also, with a lack of proximity to the end users, you have no choice but to make assumptions to fill in the gaps during the requirements gathering phase.  Like in Jurassic Park where the  geneticists filled gaps in the DNA with frog DNA:  we know how that turned out.  If the design proceeds on incomplete information, mistakes will undoubtedly be made.  Architectural and security decisions should not be based on what is "believed" to be the environment and usage behavior of a distant location.  The risk is that you may proceed with a false sense of security because the design and implementation are based on a false set of premises. 

There are also language and translation challenges, as well as time zone differences.  These factors can add layers of confusion and misinformation, and can be additional challenges to effective security (see the four risks above).  Miscommunication could also lead users to unintentionally break security rules because they are not fully understood, and because monitoring is not in full effect, the behavior goes on unnoticed.

Distance and communication challenges should inform the security design.  Assumptions, due to lack of communication or sheer exasperation, should be kept to a minimum.  This may require a few trips to the distant location, as well as establishing a mechanism to virtually visit (e.g. WebEx, video conference) the location on a regular basis.  The first step to good security is to candidly identify the differences between a remote and home location, and to design accordingly.

Avoiding a Project Ambush

There was a story I read recently on the Times Online:  French troops were killed after Italy hushed up ‘bribes’ to Taleban.  What could this tragic event possibly have to do with IT security?  Let me explain.   

First, there were allegations that the Italian government had been paying bribes to the Taliban in exchange for save haven. But Italy vehemently denied it.  Then, last year, ten French troops were killed in what they had previously assessed to be a peaceful area of Afghanistan. 

Before France went into this deadly area, they (of course) did a risk assessment.  What factored considerably into France's conclusions was the fact that Italian troops were met by little aggression in the same area.  Unfortunately, France went in to the same area but ended up in a deadly ambush, resulting in the tragic deaths.

Politics aside, I think this example illustrates the importance of conducting a thorough assessment during the requirements phase of any security or software-related effort.  If an observation is made during this phase, you should check to see if there are any dependencies behind it.  This way you can better identify any variables that could negatively impact the software implementation.  Trust but verify, in other words.

Some points to consider:

• Resarch and look for any underpinnings to your conclusions.  Make sure there's no dependencies behind what is observed that are not guaranteed to be there.
• Interview and observe more than once.  How you see things one time may be completely different the following week.  Over a series of visits you should be able to aggregate and form a more reliable assessment.

In the book 97 Things Every Software Architect Should Know, Timothy Hugh has some good advice.

Best practices in software architecture state that you should document the rationale behind each decision that is made, especially when that decision involves a tradeoff.  In more formal approaches, it is common to record along with each decision the context of that decision, including the "factors" that contributed to the final judgement.

As an analyst, you make certain assumptions after conducting interviews.  This is how we fill the gaps, not only out of time and budget constraints, but also because this is just human nature.  Recognizing and mitigating this behavior can help ensure what is perceived is indeed fact, and this can hopefully prevent ambushes, project-related or otherwise.

Ant Security

An interesting computer security project has been underway at Wake Forest University.  They have been developing threat detection software that mimics the behavior of ants.

About a decade ago I read the book Turtles, Termites, and Traffic Jams: Explorations in Massively Parallel Microworlds (Complex Adaptive Systems) which, among other things, went into detail about the pherenome trail left by ants.  The ants would go out on discovery missions, looking for food, leaving in their wake a scent trail.  If a place of interest was discovered, the scout would return back on the same trail, making it stronger, and other ants would begin to follow this same path, each traversal making the trail that much stronger.  The stronger the scent, the more interest it was to the other ants in the colony.  That's why when you see a pile of ants on a piece of food on the ground, there is usually only a single path leading to and from.

Similarly, "as [the digital ants] move about the network, they leave digital trails modeled after the scent trails ants in nature use to guide other ants. Each time a digital ant identifies some evidence, it is programmed to leave behind a stronger scent. Stronger scent trails attract more ants, producing the swarm that marks a potential computer infection."

We have a lot to learn from nature.  There are many problems evolution has already solved for us, "burned in" over thousands of centuries.  It takes creative minds like these students to emulate behaviors found in nature to solve today's technical challenges.

Bundling Security with the OS

Mac OS 10.6 (Snow Leopard) is being released tomorrow, and with it a much-improved version of File Quarantine, security software bundled with OS X.  CNET posted an early review of the OS and states "File Quarantine checks for known malware signatures and displays an alert dialog if it finds a known offender and will be automatically updated via Mac OS X's software update as new malware signatures are found in the wild."  This levels the playing field somewhat between it and the latest versions of Windows because, the article continues, "Leopard has some ASLR but everything is not randomized and Leopard has no DEP."

So I am wondering if the best security software for an OS is that which is bundled with the OS.  Why?  It's akin to complaints made by software vendors since Windows 95, that Microsoft knew all the secret hooks and APIs of their OS but only shared some of them, reserving the best ones for their own software, which gave them an unfair advantage (so the complaint goes.)  Perhaps in a perfect world OS providers would share everything with everyone and so any vendor had the chance to create the best-running software for an OS.  But not everything is Linux and open source (sorry, couldn't resist.)

So, since Apple knows OS X best, who better to develop security software for that platform?  The same goes for Microsoft and Windows. 

But where does this leave security software companies?  Perhaps if Apple and Microsoft partnered closely with these vendors, all would benefit, including the customer.  Otherwise, we hope Microsoft will bundle the best possible security software with Windows (the beta version of Microsoft Security Essentials is getting great reviews) and Apple's OS 10.6 really delivers some improved security tools. Snow Leopard will be interesting from a security perspective, regardless of what OS you are a fan of.

Passwords Re-examined

Bruce Schneier of course does it better justice than I ever could, but there was a great paper released that looks at passwords through a modern lens:  Do Strong Web Passwords Accomplish Anything?  Today's attack vectors are different--phishing is preferred over brute-force attacks, etc.  Much like how Mr. Schneier likes to remind us that if you put up a strong front door using strong cryptography, attackers will just find a way around the door.  They seek the path of least resistance.  I was very encouraged to read the linked paper,  so I wanted to pass it along who might not have caught it on slashdot.org.  I think the use of passwords needs serious re-examination as far as what is trying to be accomplished, and this paper fuels a much-needed discussion.

Guessing SSNs

Ars Technica has an interesting article titled New algorithm guesses SSNs using date and place of birth.  It describes how the date and location of birth can be gleaned from social networking sites such as Facebook, and then used in a new algorithm to guess the person's SSN "with a startling degree of accuracy."  An inference attack, in other words. 

Per reference.com:  "An Inference attack occurs when a user is able to infer from trivial information more robust information about a database without directly accessing it. The object of Inference attacks is to piece together information at one security level to determine a fact that should be protected at a higher security level."  So consider Facebook or MySpace as one big database; the adversary just needs to put the pieces together, or in this case, use those pieces in an intelligent way to get the golden ring:  the SSN.

Some questions came to mind after reading this:

• Should we be careful about over-sharing?
• Why are we still so reliant on SSN as our unique identifier?
• Why do companies continue to trust without verifying when processing credit card and loan applications?

Companies and Congress have (slowly) been taking steps to limit the use and reliance on SSNs in response to growing public frustration.  It seems not to be worth the time for credit card companies to impose stronger security measures to protect against fraud, so it is consumers that pay the price.  A safe position may be to assume that all of our personal information is already exposed and for sale somewhere in the dark recesses of the Internet, so that we maintain a defensive position by default.  Otherwise, we only react after the damage is done.  We just have to be smarter, and perhaps more vocal, about this issue.

Bandwidth Caps Means Bad Security

Bandwidth caps:  they're coming, and the ISP's really want them.  Why?  They can charge you a flat rate for, say, 5GB a month, such as is already done by Sprint and AT&T for their wireless broadband offerings.  With 5G a month you can do a lot of email, some web browsing, perhaps a Hulu video or two.  But what happens when you go over that 5GB in a month?  You get charged by the megabyte, say 5 cents/MB.  So customers using bandwidth caps need to be parsimonious with their Internet usage.  Gone are the days of being able to download anything that caught their fancy.  No more movies from iTunes, not so many songs from Napster, and no more huge OS updates.  Wait, what?  That's right.  These customers will definitely think twice before downloading any costly OS or security updates.  And we will all pay as a result.

Some examples are Apple's recent Mac OS X 10.5.7 combo update (729MB), a massive Microsoft update that patches 31 vulnerabilities (some critical), and even the 36MB Ubuntu update that I am downloading as I type.  If the user thinks his/her computer is working fine, why would that user waste valuable bandwidth downloading what seems like a totally necessary update?  Who cares if the recent Microsoft update includes a patch to protect against Conficker (that has its million-plus botnet aimed at...well, we're still waiting)?  Instead, the user saves his/her bandwidth for a couple of episodes of The Office.  Meanwhile, the user's unprotected PC becomes another zombie.  And now becomes everyone else's problem.

Internet access cannot be treated as just another utility.  If the electric company decides it needs to upgrade its infrastructure to protect against SCADA attacks, it charges its customers a couple more pennies per kilowatt hour.  It doesn't demand the customer buy some copper wire and pipe and get to work.  Just as most users won't spend their time and money upgrading a utility, most users won't going to spend an extra couple hundred MB improving their own PC's security. 

If the trend is to treat the Internet as just another utility, update downloads should be exempt.  Otherwise, don't cap bandwidth.  Also, OS vendors like Microsoft, Apple, even Ubuntu need to stop taking unlimited broadband for granted!  Why are all updates available only as a download?  Some of it is understandably because of zero-day exploits, but these security patches are relatively small.  Otherwise, give customers the option of getting their updates via a non-download method, such as CD or a recycled USB key (you send it in, they send it back with the update.)  Be creative.

PC security is no longer about a virus that trashes your hard drive.  It's about botnets made up of millions of unpatched computers that attack banks, infrastructures, governments.  Bandwidth caps will contribute to this unless the thinking of Internet providers and OS vendors change.  Because we are all inter-connected now.

Don't Sue Me, Sue the Auditor

The recent Wired article In Legal First, Data-Breach Suit Targets Auditor discusses how a credit card company is suing the company that performed their security audit.  The problem is that the credit card company was told that it was CISP (Cardholder Information Security Program) compliant, when it really wasn't.  Per visa.com, "CISP is intended to protect Visa cardholder data–wherever it resides–ensuring that members, merchants, and service providers maintain the highest information security standard" (CISP has since been replaced by the PCI (Payment Card Industry) standard.)  The lawsuit was triggered by the theft of 263,000 card numbers from the credit card company.  So if the plaintiff was truly CISP-compliant, does that mean there is no way the theft would have occurred?  Was the credit card company lulled into a false sense of security due to the bogus CISP certification?

There are two sides to this:

• The credit card company relied on the auditing company (perhaps too much) to tell them if they were CISP compliant or not, and to advise them on how to make their systems secure from theft
• The auditing company made an agreement with the customer to adequately review their systems for possible threats (include card number theft), make recommendations, and use the CISP requirements as their yardstick.

So who failed here?  The auditing company may be guilty of false adverting and under-performing the contract.  The credit card company may be guilty of not having adequate in-house security staff to keep their systems secure.  Regardless, precedent will be set if it is determined that indeed the bogus CISP rating by the auditing company contributed to the security incident. 

Is this kind of case good or bad for the security certification industry?  Perhaps good, because:

• Certification issuers will be reminded of the potential cost of rewarding a certification to an ill-qualified candidate
• Companies holding sensitive data must take ownership of their security, and not rely too much on external organizations to handle it for them
• It's a wake-up call for everyone involved

I think the credit card company is ultimately responsible.  But as quoted in the Wired article, "...there needs to be mechanisms developed to hold auditors accountable for the accuracy of their audits.”  True.  Because a reciprocal obligation to demonstrate quality exists between the certificate holder and certificate issuer, for one represents the other.  And we are all accountable professionally--and soon, perhaps legally as well.

The Missing Vials

Last month, it was reported that "three small vials of Venezuelan equine encephalitis virus were determined to have been unaccounted for last year."  While it has been concluded that this was not the result of misconduct, it does raise questions about the risk of mishandling sensitive materials.  An act of theft was not detected; the absence of things inferred theft.  So this demonstrates an administrative type of risk, where alarms are sounded and must be responded to due to proper inventory controls not being used, or used improperly.

An article in Wired magazine sums it up nicely:  "Biological material can be grown, and on the other hand, it can die off. So what happens if the bugs in a few test tubes die off, and the scientist just shrugs and cleans them out without noting the action in his lab books? A few years later, and people wonder, what happened to the material in test tubes 45-48?"  Following an adequate inventory control process could prevent this type of mishap.

A short list of activities that need to be conducted as a result of this panic:

• Interviews and interrogations
• Review of logs and accesses
• Full inventory audit

Then there is the public relations impact.  If something of this scope leaked out for a company, how much would this cost in terms of loss of trust and customers?  The Army being a government entity, this type of incident has the potential impact of increased anxiety and fear for the public, which could significantly affect the nation's productivity (which has its own price tag.)

Some recommendations for things to do regularly and thoroughly:

• Audit inventory
  
• Review and test security controls
  
• Review checkout processes
  

My point is, it doesn't always take an attack to cause a major security incident.  Sensitive material that cannot be accounted for may be assumed to be in someone else's hands, and if this is the case, the safe default position to take may be to assume that the missing material is in the hands of a threat agent.  The reaction may be appropriate (since these is an actual biological virus we are talking about) but might have been avoided altogether if inventory, controls and processes were reviewed regularly and thoroughly.  They say the insider threat is the biggest threat, and in this case it may have been just an internal administrative faux pas that caused a very public security incident.