Friday, August 27, 2010

DLL Hijacking Redux

Someone once suggested there is nothing new under the sun, and that's certainly true with this week's spate of reports about DLL hijacking attacks in Windows.

This is a well known vulnerability dating back many years. New reports that that specific Microsoft applications fall prey to this vulnerability are not at all surprising (http://tinyurl.com/33btjkh).

Microsoft is quoted by Computerworld (http://tinyurl.com/23ag8kb), saying:

"We're not talking about a vulnerability in a Microsoft product," said Christopher Budd, a senior communications manager with the company's MSRC, or Microsoft Security Response Center. "This is an attack vector that tricks an application into loading an untrusted library."

Assessing this statement requires a brief review of the facts. First, this is a vulnerability driven by the fact that Windows will search in all kinds of places to find a DLL that your application requests to be loaded, if you application is so "unsecure" as to identify that DLL only by file name instead of a fully specified pathname.

Why would applications fail to use a fully specified pathname? One good reason is compatibility: Microsoft DLL's are not consistently in the same location across different versions of Windows! Therefore software striving for compatibility needs to allow Windows to search for the DLL, or search itself. A second reason is simply because Windows allows it and thereby "it's easier".

Windows first looks for the DLL by name in the current process's current ("working") directory. That's where an attacker can easily load their own replacement DLL under the same DLL name (through a wide variety of means, none legitimate but all relatively easy to perpetrate), if (as is usually the case) the current directory is not where the named DLL resides. The next time the application runs, viola, they have their own software now running on the computer. What can it do? Literally, just about anything, including quickly load other more subtle and pernicious bot-ware, key loggers, system scanners, etcetera.

Can applications operate in a manner to avoid the vulnerability? Yes, they can, but doing so is more complicated for the application developer. The key is to always load a specific DLL in a specific directory using a fully specified pathname. This in turn can create its own application compatibility issues, as any given path name to a system DLL is not guaranteed to be the same from Windows version to version! This is the true heart of the design issue, because any attempt to deal with this multiplicity of DLL locations across Windows versions in a single version of an application requires the application perform a "search" for the DLL across different directories...which is exactly what Windows does automatically for you and which opens up the application to a replacement DLL attack!

We here at Arxan are looking at this problem in an orthogonal manner, by identifying opportunities to validate that the proper DLL was loaded, regardless of its originating location. Those are the kinds of application internal security features we are quite good at. Note the elegance of this kind of solution: it doesn't require any application source code changes (because our technology inserts such checks directly into the binary application code), it creates no new dependencies on Windows specifics such as specific DLL locations in this or that version of Windows, and it is a security solution that migrates with the application itself.

To end with another ancient aphorism, if you want a job done, best to do it yourself. If you want your applications secure, don’t trust in the operating system to provide that security: secure your applications yourself!

Friday, August 20, 2010

Smart Phones: The Fifth Wave of Computing!

Two recent analyst reports detail the proliferation of smartphone apps. ABI Research predicts that mobile application downloads from iOS and Android will account for 78% of all application downloads in 2010, with iOS (the iPhone's operating system) taking the lion's share of 52% of all applications. Meanwhile iSuppli predicts Android will be used in 75 million smartphones by 2012, up from 5 million in 2009. Meanwhile, iOS usage will amount to 62 million in 2012, up from 25 million in 2009. Sales of these multi-function hand-held internet connected computers are expected to pass up sales of traditional PC's and laptops well before the middle of this new decade.

Overall, I believe this represents a titanic shift in the computing industry. If we step back far enough we can see perhaps four massive waves in the evolution of computing: first, the custom/boutique computing period of 1940's and 1950's, then the mainframe period of the 1960's through 1970's, then the minicomputer period from the 1970's through the 1990's, and the PC period from the early 1980's to the 2010's. The fifth wave is upon us, and it is the "smartphone" period.

Note how with each wave, old winners faded away, and new winners emerged. Nowhere is this more stark today than the fading glory of Microsoft, huge winner in the PC wave...with virtually no technology or product position in the heart of the smartphone wave.

In this new wave, the iPhone is the front runner, and Android-based smartphones are gaining in what appears to be a two-horse race, as the overall smartphone market is poised for explosive growth. This is great news for the smartphone ecosystem, while at the same perhaps a "deer in the headlight" moment for enterprise security teams.

Today's smartphones continue to expand in functionality, driven by huge numbers of innovative applications and generally better performance as a computing device. The iPhone and Android-based phone is rapidly becoming a serious alternative as a general personal computing device offering unique value in terms of personal mobility.

This is leading to sticky issues for enterprise security teams. What applications are okay to download? Will any applications used for personal purposes create any security issues (i.e. malware) with applications to be used at work? Can third party "business" applications be generally trusted? What are the additional costs to add smartphones to the already broad mix of enterprise IT managed devices? Are the appropriate security policies and underlying practices, mechanisms and resources in place?

While no doubt a daunting task for the enterprise security teams, this is yet another reason why widely used data protection methods aimed at "defending the perimeter," are not enough in today's distributed computing world. Today, companies need to adopt new strategies aimed at integrating security into the software and application themselves. Given today's distributed enterprise computing model, a modern enterprise literally has no set network perimeter to defend. This was true with the laptop and home PC being used routinely as a corporate computing devices. But now with the smart phone filling the same role, the distributed computing nature of the modern enterprise reaches it ultimate manifestation: corporate computing is happening everywhere there are employees, everywhere they go, all the time.

Obviously the security industry must roll up its sleeves and expand the notion of enterprise security. In this process, the old models of "centralized everything" probably won't work. Individuals must broaden their awareness and their personal practices, because these are "personally managed" devices. Application providors must consider the risks and take appropriate actions to protect their applications from cloning and trojan insertion. Lastly, device and the system software providers must continue to enhance and refine the security attributes, features and functions of the devices themselves.

-------------------

Late breaking news: Intel, with a growing new focus on mobile computing, acquires McAfee, and the talk is all about...traditional PC anti-virus you say? No! Not a word! The talk is all about the need for Intel to get a position in mobile/wireless computing security. Just another indication that the fifth wave of computing is upon us.

Tuesday, August 3, 2010

Smart Phone Privacy?

The media is in a minor uproar over (the lack of) phone privacy:

http://www.zdnet.com/blog/google/apps-on-your-phone-putting-your-privacy-at-risk/2332?tag=nl.e550

The essence of the story is that (1) you don't really know or control what all those applications you are loading onto your "smart" phone really do, and (2) they do far more spying on your phone data than you realize.

If you think such hidden spyware in phone apps is uncommon, let me tell you about a presentation at last week's Black Hat conference in Las Vegas. Kevin Mahaffey and John Hering reported in their session "Application Attack: Surviving Explosive Growth in Phone Applications" on an automated methodology called "Genome" in which they have downloaded and analyzed just about all the world's free applications for both the iPhone and Android phones.

Among their many interesting results, they found an abundance of "wallpaper" applications, all from the same author, that sent back to a server in China your phone's sim serial #, your subscriber ID, your phone line # and your voice mail #. Whoops, so much for phone privacy and application security. This news is now getting general media coverage:

http://www.tgdaily.com/security-brief/50862-as-many-as-4-million-people-downloaded-data-stealing-android-app.

These researchers also found that while it appeared that about 30% of smart phone applications "steal" your phone location information, in fact the bulk of that usage is by 3rd party adware software in those applications, which want to vend to you location targeted ads. So it's not necessarily as nefarious as it may seem, though just as with Google mail giving you targeted ads based on the content of your email, all kinds of interesting questions of appropriate bounds of privacy arise.

Before we run, scream and shout about the lack of smart phone privacy, let's acknowledge that there is nothing new here under the sun. The exact same issue presents itself on our PC's. We can and do download all kinds of apps, and they can (and do) gather and lift info.

One critical difference is that on our PC's, we don't have the same privilege management systems that at least give us the chance to know of and approve of the rights the app is requesting. So one could argue Android is superior to PC's in this regard. And on the iPhone, there is at least a minimal amount of vetting, again, an improvement vs. the PC.

A key difference here is that people have more sense of "privacy" related to a phone than to a PC. We've been inured to PC virus issues so we just assume that nothing's really safe or personal on a PC. Phone calls and phone specifics are viewed as private, so all the PC issues coming to roost on smart phones creates a media uproar.

What we need to understand and accept is that the "smart phone" device you have in your pocket (or are reading this blog post with) is not a phone! It's an extraordinarily powerful internet connected computer, with all the security issues such computers come with. All of them.

Downloading an application to a computer is a fundamentally dangerous proposition, just as wheeling in a large wooden horse into their city was a bit risky for the Greeks. The situation is worsened by the fact that the application arena for smart phones is a cottage industry. We are comfortable and reasonably safe when we load a PC application from a known business entity; when we load a wallpaper application written by "jackeey wallpaper", do we have any idea what we are really getting? Clearly not.

There is a business opportunity here, and that is to provide a technology/service that vets phone applications through internal code analysis (just as the Greeks should have first taken a look inside that wooden horse!). A "Good Housekeeping Seal of Approval", perhaps structured as a separate app store front or just as an informational service.

There is a corollary problem of how do I, as a "good guy" or "good company" publishing application software, protect my application from being trojanized and republished? If you've read any of my earlier blogs you'll find plenty of material on how to effectively deal with that.

So the next time you are about to casually download that nifty new game or whizzy app that makes your phone sing and dance...think about how much you really know about the software you will be unleashing on your "private" hand held computer, and the range of possible objectives of the person who wrote and published that software.

And beware Trojan's bearing application gifts.

Electronic Espionage and Application Security

When it comes to cyber attacks, “the stakes are too high to ignore the problem,” according to InfoWorld (http://tinyurl.com/2fk3vt6) in an in-depth report on electronic espionage.

The attacks often bypass typical security tools that companies implement to protect their data assets. Once inside the system, the electronic spies quietly gather data over time without causing disruptions that could alert integrated security tools or draw suspicion from a company's IT security team.

Neil MacDonald, vice president at research firm Gartner, says, "as many as 75 percent of enterprises have been or are being infected with undetected, financially motivated, targeted attacks that evaded their traditional perimeter and host defenses."

The simple fact is that widely used data protection methods aimed at "defending the perimeter," are not enough to protect against more and more sophisticated threats such as electronic espionage. There are far too many methods by which the perimeter can be penetrated, both through direct and indirect attack. Applications in the enterprise, in the cloud, distributed applications and applications in end point devices are the new focused target of attack by organized crime.

This is a good time to re-post what I call my "application commandments."

1.) Applications can and should detect and notify of debugger attachments.
2.) Applications can and should protect critically sensitive code through encryption and dynamic decrypt/execute/re-encrypt operations.
3.) Applications should utilize multiple levels of networks of self-guarding techniques, with a variety of overt and subtle response actions, to ensure that persistent attacks are foiled at some level.
4.) Enterprise applications should have these response actions wired into the security monitoring systems deployed by the enterprise.

These practices need to become commonplace and part of our general software lifecycles. We need to keep up with the organized criminals, and right now our software is falling woefully behind.