Of course, Microsoft can afford to write these cheques practically ad infinitum, but if your tools are so lacking in perceived utility that you need to bribe people to use them (even if the graft is partially subsidized by affiliate fees), perhaps this is not really the best you could hope for from your marketing team.

You can’t take on Google by trying to buy, or even out-feature, your way into the blank-text-box Search Engine arena. Except for some regional players, like Russia’s Yandex, they’ve won and will not soon be replaced.

What Ballmer, and lots of other people, are missing is that the Search marketplace as we know it is poised for a change. Much of this change emerges from the fact that Google fundamentally owns the global Search Market, but much of the opportunity extant in this space comes from the fact that the technology behind search, and how people will make use of search engines in the future, will be a whole lot different than what you see when you type in www.google.com today.

…. but, there is light at the end of the tunnel for folks who are on the outside looking in at Google’s substantial (and impossible to dislodge) market share:

For most people, web search is a kludge.

Think about how you use Google today. Think about why you type things into that blank text space beckoning to you on your Firefox browser, or why you surf over to Google.com and enter a few snippets of text into that empty area amidst the sea of clutter-free Google whiteness ten, twenty, or maybe many more times per day.

In some cases, you overheard something being discussed in a coffee shop. Or you saw a billboard ad. Something offline motivated you to head to the blank text box and ask it to do your bidding. That is Google’s fundamental market opportunity and has remained largely unchanged since the first search engines began emerging in 1995.

This is, however, just a fraction of the reasons why many of us head to search engines. Often the reasons are as much motivated by inadequate information at one site as by anything else. An example: You’re reading an article from a wire service like Reuters, which rarely include photos, about a car or a submarine or a mountain. You’d like to see what that looks like, so off to Google you go. Or you’re looking at a new LCD on eBay, but the seller hasn’t listed the number and type of inputs that come with it; so off to Google you go to try and find the specifications.

In short, most often we go to Google to search for things because our browsers aren’t good at building pathways between like objects on the web. These types of Searches are what I call context-driven. You shouldn’t need to do this. You shouldn’t need to interrupt your surfing to drop off to a third-party site in order to add flavour to the web objects which have already garnered your interest.

What if you could press a button and instantly be delivered relevant information that is contextual to that which you are/were looking at? What if sites displaying articles from wire services (notable for their sparseness) were able to draw in information – in realtime – which added relevant photos, videos, or related stories?

Some of this is already happening, albeit rather jerkily. One of the leaders which started doing this some time ago was Sphere, which was recently acquired by AOL. It took them some time to draw the same conclusions as I have, and they had a difficult time monetizing these services. But on a great enough scale the same technologies which make relevant content possible also make relevant advertising possible. And while click-thrus will be fewer in quantity they can be greater in quality and therefore infinitely more valuable, thanks to much more accurate targeting.

Being accurate in driving these sorts of searches is hard. Whereas Google relies on its users to sift through its top 30 or so recommendations to find the most relevant information, contextual search engines need to be able to do that with high accuracy on the first few matches with little to no meatware — sorry, Mahalo. Many of the current buzzwordy trends such as the Semantic Web initiatives, Social Search, the shift from RSS to Atom, and API-accessible semantic processing are key enablers to make this easier, but there’s still a considerable amount of R&D necessary to beat Google’s current level of accuracy in this regard.

As a result, you need a long lead to get there, and few of the companies dabbling in the Vertical Search space have raised enough capital or have investors who have committed to developing these opportunities. But in the long run, this will augment Web Search and replace much of the traffic that is today driven by Google’s simple, primitive, empty text box.

What’s clear is that Microsoft’s desperate attempts to lure users to its essentially equivalent service to Google’s can only cost its shareholders. A new paradigm is necessary and, fortunately, the opportunity is ripe for the picking, right in front of us all.

This is a rare opportunity where the solution lies in good, solid R&D and product realization — not in leveraging semi-monopolistic product integration or in brute force advertising spending. Is Microsoft bold enough to understand, and embrace, the fact that Search is shifting? Do they have the product and engineering people to make this happen?

Still, a couple of years ago I recommended that we deploy a Drupal site for EQO, where I was the VP Marketing. As seems to be common with a lot of Drupal projects, there was much forking of code and a great deal of customization required to make the thing feel like a true web interface. As a result it’s been a challenge for EQO to keep their site up-to-date with the latest versions and to reconverge with the growing Drupal codebase.

Daniel’s most salient point is this:

The belief in the Drupal community is clearly that it’s all about the… community. That is, the power of a disparate community will be harnessed to deliver the features and usability desired by end users. But the fatal flaw in the Drupal community model seems to be that its community consists entirely of developers and not publishers. Or worse still development shops who make money by customizing Drupal.

… whereas WordPress is guided by the steady hand of Matt Mullenweg and supported by a company which just raised $29M to further the cause. Not to mention a vast community of artists, designers, publishers, and software geeks who contribute widgets and extra features via a powerful API and a stable code tree.

I think that there will always be a place for Drupal and for the customization shops that support and enhance the platform (a number of whom are Vancouver-based). But it must be assumed to be true that while WordPress is more of a mass-market, easily-accessible platform, Drupal is its antithesis: a platform created by geeks for use by other geeks, and not something indulged in lightly.

In much the same way that The 250 are very good at promoting themselves within, well, the 250 the Drupal community has done a good job of promoting itself within the the Drupal community. Meanwhile, WordPress has even managed to reach out to and impress My Dad (definitely not one of the 250). While there is much possibility for grift in the Drupal market, selling a lot of stuff to a few people, I’m a guy who tends to bet long on selling a little bit to a lot of people.

Talk to a Drupal user (who is likely also a Drupal developer) and you’ll get a lot of detail about why Drupal is more powerful. Talk to a WordPress user (which is just as likely to be your mom) and you’ll get a lot of detail about how easy it is to use, extend, and modify.

While Gersham and I are playing with his Rails-based blogging engine, Orangutan, I still find myself constantly comparing it to WordPress.

There is some apparent overlap in both offerings, in that they are both essentially smart CallBack services.  But the positioning and nuances of the service offering are in fact quite a bit different.  While on one hand I think MaxRoam represents a more comprehensive solution targeted exclusively at mobile roamers, I think that Lypp is a significantly more frictionless service which you can make use of in myriad ways, not exclusively to avoid long-distance bilking on your mobile phone.

In particular the Lypp API, coupled with the fact that you can easily instantiate calls with multiple parties via SMS and Instant Messaging,  is a game-changer.  The notion of spontaneous conferencing is actually, finally, possible.  And if you coupled Lypp (via its API) with a smart calendar-based scheduling system you’d have yourselves a pretty kick-ass enterprise conferencing solution.

But overall, the Lypp model applies wherever you have a situation where two parties elect to chat via voice while using some other medium.  Viewed from this 30,000 foot precipice, you can see that Lypp has utility in applications as far-flung as online dating, business-to-business calling, and even chat radio shows, call centres, and unified communications.

This means that in some ways Lypp competes with Jangl and Jajah, however it should probably in the end be marketed more as a toolkit like VOXEO.  Come to think of it, all of those companies are run by friends of mine, too.

What I find ironic is that the base concept of CallBack is not new … it’s been around since the early 1980s, when smart telecom entrepreneurs realized it was substantially more expensive to call from, say, Brazil to the USA than it was to call from the USA to Brazil.  These CallBack drones, much like the Prepaid Calling Card industry, were among the first major VoIP platform customers of ours when I was a lowly Product Manager in the Packet Telephony Division at Cisco.

Most of those companies died or were absorbed as their major market differentiator (price) eroded and they were commoditized by Big Telco.

CallBack services are generally easy to replicate on VoIP platforms.  What’s having a disruptive effect now is that with so many open-platform VoIP solutions and generally cheap computational power, it is possible to rapidly develop scalable telecom applications in ways that were formerly only accessible to the likes of Nortel and Cisco.

It’s clear though that among this latest batch of telecom evolutionaries there is some real innovation.  There are, however, lessons to learn:  While the clear temptation of most of these businesses will be to hinge their value
proposition on lower-cost in exchange for slightly lower convenience, this is a losing business.

The challenge is to innovate and let new capabilities and opportunities continue to drive innovation and product design.  This is an area where no Big Telco executive has any real lasting insight.  Elephants are terrible tapdancers.

-Ian.

—– http://humane.sourceforge.net/the/

Jeff Raskin: About The Humane Environment

There is a common misconception that The Humane Environment (THE) is just a hyper-efficient editor. It is not. So THE is not an editor… what is it? <a wider range of users.

But interfaces have not moved with changing times. After a decade of research into cognitive psychology and by paying attention to people’s constant computer complaints (and his own annoyance), Raskin realized that today’s GUIs are fundamentally flawed. The interface-building tools that companies and open-source prouducts provide enforce bad interface design practices. They are wrong. Period. Raskin figured out how to fix the problems. His popular book, /The Humane Interface/ <)”>http://humane.sourceforge.net/the/manual.html>) before you unlearn your present habits and can begin to appreciate it. You are in a worse position for learning it than a novice who has only to acquire new habits and has nothing to unlearn!

But once you have learned THE, you will wish that all your software had at least some of its interface features. This we guarantee; it happens every time.

After you’ve used THE, you may well be motivated to add new commands, critique what we’ve done, port it to other platforms (it is on the Mac right now, but a lot is written in platform-independent Python <.”>http://humane.sourceforge.net/humane_interface/index.html>. For experience, try the software. You can visit the projects SourceForge page here <.”>http://sourceforge.net/cvs/?group_idW603>.

(signed) Aza Raskin Bug List <“>http://humane.sourceforge.net/the/spec.html> Before going on to the design of the visually-oriented zooming portion of The Humane Environment (THE), it seems wise to specify the low-level interactions that take place within the document-centric portion. Also, this portion allows interaction by the visually impaired. We specify first that software necessary to demonstrate LEAP and some of the selection and command interface techniques and other benefits described in “The Humane Interface” [Raskin, 2000]. THE is intended to run on at least Windows, Linux, and Mac platforms. This specification describes the first portions to be implemented and gives some indications for future directions. Joining the THE Team <“>http://humane.sourceforge.net/the/manual.html> The user manual, written for developers of the Humane Environment

Mission Statement <“>http://humane.sourceforge.net/the/spec.html> Using CVS and Sourceforge.net <4098 https://ianbell.com/2002/10/28/the-golden-age-of-hacking/ Mon, 28 Oct 2002 15:05:37 +0000 https://ianbell.com/2002/10/28/the-golden-age-of-hacking/ I would imagine the real golden age was when you needed to be more than just a script kiddie to hack into a network. Back in the day, hacking was one part social engineering, one part software engineering, and one part magic.

—– http://www.pcworld.com/news/article/0,aid,106352,00.asp Are We Living in the Golden Age of Hacking?

Recent months have seen an increase in security holes and in new tools used to exploit them, expert warns.

Gretel Johnston, IDG News Service Friday, October 25, 2002

Over the last eight months major new hacker tools have been released or revealed, ending a lull in activity among hackers that followed the September 11 terrorist attacks and the enactment of legislation that enhanced law enforcement’s ability to prosecute people who break code and wreak havoc on networks by exploiting software vulnerabilities, hacking consultant Ed Skoudis said Thursday.

LibRadiate, Paketto Keiretsu, Setiri, and The Defiler’s Toolkit are just some of the newest tools that have cropped up since March and that are keeping security specialists awake at night, according to Skoudis, who gave a threat update briefing at a SANS Institute conference. SANS is a security education and research organization in Bethesda, Maryland.

Skoudis, the vice president of ethical hacking and incident response at consultancy Predictive Systems, in New York, said the June-through-September period saw massive exposures of security vulnerabilities in OpenSSH, Internet Explorer, and Apache Web server software.

“This summer has been a huge summer for hackers. There were huge issues discovered all summer long, and things really opened up between March and now,” Skoudis said. “The Golden Age of Hacking rolls on.” Insecure Networks

One of the latest developments involves the security of wireless LANs and the ease with which people are able to detect them. For one week in early September, amateur wireless LAN sniffers used freeware called NetStumbler to detect hundreds of insecure business and home wireless LANs in North America and Europe in an exercise called a “war drive.”

Skoudis said attackers have “flocked to this area” and are finding that many wireless LANs are set up without basic security. After they detect the wireless LAN, they can use a tool that’s been available since May called LibRadiate, an API that allows developers easily to capture, create, and transmit arbitrary packets on a wireless LAN using the IEEE 802.11b standard. The tool runs on Linux (kernel 2.4) with wireless cards that have the Intersil Prism 2 chipset, Skoudis said.

LibRadiate makes it possible for hackers, using “fairly simple C code,” to capture TCP/IP packets or inject them into a network. Among the wireless attack tools expected to become available for use with LibRadiate, according to Skoudis, are Wired Equivalent Privacy crackers, which exploit flaws in the WEP protocol, allowing a hacker to determine encryption keys even when WEP is in use; and malformed packet generators, which inject strange and noncompliant packets into a network in an attempt to crash systems that cannot handle unusual packet structures.

“With tools like LibRadiate, the computer underground is starting to develop far more sophisticated attack tools than what we have seen in the past,” Skoudis said. TCP/IP Tricks

Another tool released, two weeks ago, is called Paketto Keiretsu, which Skoudis referred to as a suite of tools for doing TCP/IP tricks. One of its most fundamental capabilities involves rapid port scans, which it does by separating the packet sender from the receiver.

Skoudis also described Setiri, a new Trojan horse back door. The tool bypasses personal firewalls, Network Address Translation devices, proxies, and advanced firewalls by starting up an invisible browser on the victim’s PC.

Then Setiri, running on the victim’s system, uses OLE to communicate with the hidden browser. As long as the victimized PC’s browser can access the Internet, Setiri can reach across the network and get the attacker’s commands. The personal firewall, NAT, proxy, and stateful firewall do not know whether the access is caused by a user surfing the Internet or Setiri getting commands.

Setiri, developed by a small group of South African security consultants and demonstrated in August at Def Con, hasn’t been seen in the wild yet, Skoudis said. Nevertheless, he included it in his presentation because its existence has been acknowledged within the security community and writing the code is something a moderately skilled coder could do.

Skoudis said the system strips out information about the user by going through anonymizer.com, so blocking access to that site is a way of defending against Setiri. Another solution would require changes in IE that limit the actions of an invisible browser, and Skoudis said Microsoft has publicly said it will address the matter. Hacker’s Toolkit

In the new area of “antiforensics,” hackers have had access to a tool called the Defiler’s Toolkit since July. It’s able in a number of ways to foil the Coroner’s Toolkit, a tool that has been used by computer forensic specialists for several years, Skoudis said. For example, it can destroy or hide the traces of a hack that the Coroner’s Toolkit looks for. The Defiler’s Toolkit targets Linux Ext2fs file system, but Skoudis said the concept could be extended to other platforms.

Commenting on the recent distributed denial of service attack on the Internet that happened Monday, Skoudis said major U.S. law enforcement agencies are investigating, but he didn’t know whether they had developed any theories about where the attack originated.

Alan Paller, director of the SANS Institute, said the attack is being characterized by security professionals as a Smurf attack that could have been much worse if all 13 root servers had been affected.

“Had it knocked out all of them, there’s a reasonable expectation that over a certain amount of time … the way that you use the Internet would have ceased to work,” Paller said.

There’s no easy fix for preventing DOS attacks, and the time is fast approaching when ISPs are not going to allow users on the Internet if they pose a threat to the other users by not meeting a minimum standard of security, Paller added.

“DOS attacks are not going to be solved because we get some new hardware in the system,” Paller said. “You are going to have to re-engineer the whole Internet. That’s going to take close to a decade. While we are doing that, we are going to have to start protecting ourselves from [users who] are not going to be careful.”

———–

By Foon – ivegotta [at] tombom.co [dot] uk

http://security.tombom.co.uk/shatter.html

Introduction

This paper presents a new generation of attacks against Microsoft Windows, and possibly other message-based windowing systems. The flaws presented in this paper are, at the time of writing, unfixable. The only reliable solution to these attacks requires functionality that is not present in Windows, as well as efforts on the part of every single Windows software vendor. Microsoft has known about these flaws for some time; when I alerted them to this attack, their response was that they do not class it as a flaw – the email can be found here. This research was sparked by comments made by Microsoft VP Jim Allchin who stated, under oath, that there were flaws in Windows so great that they would threaten national security if the Windows source code were to be disclosed. He mentioned Message Queueing, and immediately regretted it. However, given the quantity of research currently taking place around the world after Mr Allchin’s comments, it is about time the white hat community saw what is actually possible.

This paper is a step-by-step walkthrough of how to exploit one example of this class of flaw. Several other attack methods are discussed, although examples are not given. There are many ways to exploit these flaws, and many variations on each of the stages presented. This is just one example.

Background – the Win32 messaging system

Applications within Windows are entirely controlled through the use of messages. When a key is pressed, a message is sent to the current active window which states that a key was pressed. When Windows decides that an application needs to redraw its client area, it send a message to the application. In fact, when any event takes place that an application needs to know about, it is sent a message. These messages are placed into a queue, and are processed in order by the application.

This is a very reliable mechanism for controlling applications. However, on Win32 the mechanism for controlling these messages is flawed. Any application on a given desktop can send a message to any window on the same desktop, regardless of whether or not that window is owned by the sending application, and regardless of whether the target application wants to receive those messages. There is no mechanism for authenticating the source of a message; a message sent from a malicious application is indistinguishable from a message sent by the Windows kernel. It is this lack of authentication that we will be exploiting, taking into consideration that these messages can be used to manipulate windows and the processes that own them.

Overview

In this example, I will be exploiting Network Associates VirusScan v4.5.1, running on Windows 2000 Professional. Since the VirusScan Console runs on my desktop as LocalSystem and I am logged on as a guest user, the objective is to trick VirusScan into running my code to elevate my privileges. This is accomplished in several easy stages. 1. Locate a suitable window within VirusScan (an edit box is perfect), and obtain a window handle to it. 2. Remove any length restrictions that may be present on that edit box, so that I can type in an arbitrary quantity of data. 3. Paste in some binary executable code. 4. Force VirusScan to execute my code (as LocalSystem)

This is actually very easy to do. Windows conveniently provides all of the functionality that we will be needing. I have written a small application called Shatter which implements this functionality. You’ll also need a hex editor that is capable of copying binary data to the clipboard (I use UltraEdit), and a debugger (I use WinDbg).

PLEASE NOTE: Some virus scanners are alerting people to the presence of a “Win32/Beavuh” virus within the sploit.bin file in the Shatter zipfile. This is not a virus. The scanner is correct in flagging it – the code in this file is designed to open a command shell and bind it to a network socket. This is a bad thing to do in general, so the scanner is correct in generating an alert. This code is designed to be malicious in terms of its functionality, but the scanner is incorrect when labelling it as a virus.

Windows messages consist of three parts, a message identifier and two parameters. The parameters are used differently depending on what message is sent. This makes our life simpler, since we only have to worry about four things; a window handle to receive the message, the message, and two parameters. Let’s find out how easy this is…

Stage 1: Locating a window

We need to locate an edit control of some kind – something that we can type stuff into. Don’t worry if it’s restricted, we can cure that. Fire up the VirusScan console, and hit the first button – “New Task”. Conveniently, at the top of the dialog, there’s an edit box. That will do perfectly. Now, we need a handle to that control so that we can interact with it. Windows is more than happy to give us a handle to any window we like – we just have to ask it. Fire up Shatter, and position it so that you can still see the VirusScan edit control underneath it. Click on “Get cursor window” – Shatter should add an item in the list box beneath like “102f2 – Get cursor window”. This is because we’ve asked Windows to give us a handle to the window directly underneath the cursor. Move the cursor over the VirusScan edit control and hit Space to trigger Shatter again. Shatter should clear the list box, and tell you the handle for the target window – in my case it’s 30270. So, we can now interact programmatically with a window that is running with higher privileges than we are. Let’s paste in some shellcode.

Stage 2: Removing Restrictions

Now that we have a window handle, we can send any messages we like to that control and it will blindly execute them. First things first – let’s make sure we have enough space for our shellcode.

Within Shatter, type your window handle into the “Handle” box. The message to set the maximum text length of an edit box is EM_SETLIMITTEXT. The first parameter is the new maximum text length, and the second parameter is ignored. Type 4 into the WPARAM box, and 0 into the third. Click on EM_SETLIMITTEXT to send the message, and try to type something into the VirusScan edit box. You shouldn’t be able to type more than 4 characters. Change the 4 to FFFFFFFF and send the message again. Now try typing into the VirusScan edit box; you now have over 4Gb (theoretically) of space within that edit control. Should be enough for even the most wasteful shellcode.

Stage 3: Injecting Shellcode

Next up, let’s try pasting something into the box. Yes, OK, you could just right-click and choose Paste, but for the sake of argument let’s work as if we couldn’t do that. Clear the VirusScan edit box, and fire up Notepad. Type some text into Notepad, and copy it. Back in Shatter, we want to send VirusScan a “Paste clipboard contents” message, which is WM_PASTE. Both parameters for this message should be zero, so set the WPARAM and LPARAM to zero, leaving the handle the same. Click WM_PASTE, and watch your text appear in the VirusScan edit box. Click it again, and it should now be there twice. Fun, huh?

OK, that’s enough playing. Clear the VirusScan edit box again, and fire up your hex editor. Load up sploit.bin, included in the Shatter zipfile. This is the shellcode taken from Jill (Hey, Dark Spyrit!) which fires a remote command shell back to you. It’s hard-coded to send a command shell to the loopback adress on port 123, so now’s probably a good time to fire up a Netcat listener before you forget. Fire up a cmd, hit “nc -lp 123” and forget it. Back to our hex edit. Copy the shellcode to the clipboard, making sure you get all of it (including the FOON at the beginning – we’ll need that in a sec). Back to Shatter, and hit the WM_PASTE button again. You should now see a whole load of nasty-looking characters in the VirusScan edit box; that’s our shellcode, nicely pasted in.

Stage 4: Executing the code

This is the only part of the process that requires any skill. Fire up your debugger, and attach it to the avconsol.exe process (Using WinDbg, that’s F6 to attach, and just choose the process). Next, do a search through memory for the FOON string. The WinDbg command is s -a 00000001 10000000 “FOON” but you might use a different debugger. Note down the memory location that the string appears at; it’ll probably appear a couple of times, don’t ask me why. Any of them will do. On my system, the shellcode appears at 0x00148c28, it shouldn’t be far off if you’re using the same version. Now, kill the debugger, log on as a guest user, and prepare to receive localsystem privs. Follow stages 1 through 3 again, noting that everything still works as a guest user. Don’t forget the Netcat listener to receive the shell.

At this point, you might be thinking that attaching a debugger is a privileged operation. It is. However, much the same as when writing a buffer overflow exploit, you can do that part on any system; all you need is the load address which should then work on any system running the same version of the software. In actual fact, you needn’t actually do this at all. Most applications have their own exception handlers (VirusScan certainly does), so if they generate an access violation, they just deal with it and move on rather than crashing. So, there’s nothing to stop you pasting in a few hundred kilobytes of NOPs and then just iterating through memory until you finally hit the right address and your shellode executes. Not particularly elegant, but it’ll work.

The final message that we’re going to make use of is WM_TIMER. This is a slightly odd and very dangerous message, since it can contain (as the second parameter) the address of a timer callback function. If this second parameter is non-zero, execution will jump to the location it specifies. Yes, you read that right; you can send any window a WM_TIMER message with a non-zero second parameter (the first is a timer ID) and execution jumps to that address. As far as I know, the message doesn’t even go into the message queue, so the application doesn’t even have the chance to ignore it. Silly, silly, silly…

So, within Shatter, the handle should be set to the VirusScan edit control containing our shellcode. The first parameter can be anything you like, and the second parameter should be 512 bytes or so above the address we picked out of the debugger earlier (we have 1K of NOP’s in front of the shellcode, so we should land slap bang in the middle of them); on my system that’s 0x148c28 + 0x200 0x148e28. Hit WM_TIMER, and your netcat listener should come alive with a command prompt. A quick WHOAMI will reveal that you have indeed gone from guest to local system. Enjoy.

Alternative techniques

There’s a few other ways of doing what we just managed, utilising the same basic mechanisms but maybe adding a bit more complexity. The EM_GETLINE message tells an edit control to copy its contents to a location specified within the message. How would you like to write arbitrary quantities of data to arbitrary locations in memory? How easy a sploit do you want? We’ve seen how the restrictions can be removed from the length of an edit control; what happens when an application depends on these restrictions? When an application expects 16 bytes of data from a limited-to-16-byte edit box, we can type in a few gigs. Everyone, on three; 1….2….3….Buffer Overflow! Probably stack-based too, since 16 bytes of data is unlikely to come from the heap. Also, when we send WM_TIMER, the parameter we specify as a timer ID gets pushed onto the stack along with a whole load of other crap. It’s not inconceivable that we could find a function which makes use of the 3rd function parameter and none of the others, allowing us to jump directly to a sploit with a single message.

Talking of the heap, that’s another great thing about these exploits. Generally, applications will create dialog boxes on the heap well in advance of any major memory operations taking place; our shellcode address is going to remain pretty static. In my experience it rarely moves more than 20 bytes between instances. Static jump addresses shouldn’t be a problem, but who cares? Send the app an EM_GETLINE message so it writes your shellcode to a location you specify (Hell, overwrite the heap. Who’s gonna care?) and then specify the same address in your WM_TIMER message. A completely NOP-free sploit! What fun!

Fixing the problem

Okay, so this is pretty easy to exploit. How is everyone gonna fix this? I can see two quick and dirty methods which will break a whole lotta functionality, and one very long-winded solution which is never going to be a total solution. Let me explain. 1. Don’t allow people to enumerate windows Nasty. Multiple breakages. Theoretically possible, but I’d hate to see people trying to work around not knowing what windows are on the desktop when they need to. 2. Don’t allow messages to pass between applications with different privileges Means that you couldn’t interact with any window on your desktop that’s not running as you; means that VirusScan at the very least (probably most personal firewalls, too) would need a whole lotta redesigning. 3. Add source info to messages, and depend on applications to decide whether or not to process the messages Would need an extension to the Win32 API, and a whole lotta work for people to use it. Big job, and people would still get it wrong. Look at buffer overflows – they’ve been around for years, and they’re still fairly common.

Basically, there is no simple solution, which is why Microsoft have been keeping this under their hat. Problem is, if I can find this, I can guarantee that other people have as well. They might not tell anyone about it, and the next time they get into your system as a low-priv user, you wouldn’t have a clue how they got LocalSystem out of it. After all, you’re all up to date on patches, aren’t you?

Addendum: Why is this a problem?

When Microsoft saw a copy of this paper, they sent me a response stating clearly that they are aware of these attacks, and they do not class them as vulnerabilities. I believe that this point of view is incorrect. The two reasons that Microsoft stated are that a) They require unrestricted physical access to your computer, or b) they require you to run some kind of malicious code on your machine. I agree completely that in both of these scenarios, 0wning the machine is pretty easy. However, they’ve missed the point. These are techniques that an attacker can use to escalate their privileges. If they can get guest-level access to a machine, these attacks allow you to get localsystem privileges from any user account. Anyone ever heard of a little tool called hk.exe? How about ERunAsX (AKA DebPloit)? How about iishack.dll? All of these tools exploit some flaw that allows you to escalate your privileges AFTER you’ve gained access to the machine. All of these have been recognised as security holes by Microsoft, and patched.

If you have a corporate desktop machine, most commonly those machines will be quite tightly locked down. The user on that machine cannot do very much that they have not been explicitly granted permission to do. If that machine is vulnerable to a shatter attack, that user can gain localsystem privileges and do what they like. Even worse is the case of Terminal Services (or Citrix). Imagine a company providing terminal service functionality to their clients, for whatever purpose. That company is NOT going to give their users any real privileges. Shatter attacks will allow those users to completely take over that server; localsystem privileges are higher than the Administrator, and on a shared server that’s a problem. Oh, and it doesn’t require console access either – I’ve successfully executed these attacks against a Terminal Server a hundred miles away.

The simple fact is that Microsoft KNOWS that they cannot fix these flaws. The mechanism used is the Win32 API, which has been fairly static since Windows NT 3.5 was released in July 1993. Microsoft cannot change it. The only way they could stop these attacks is to prevent applications from running on the desktop with privileges higher than those of the user logged on. Microsoft believe that the desktop is a security boundary, and that any window on it should be classed as untrusted. This is true, but only for Windows, and because of these flaws. Either way, Microsoft break their own rules; there’s numerous windows on a standard desktop that run as localsystem. Use my shatter tool to verify this – there’s a whole load of unnamed windows which might be running as Localsystem, and a few invisible windows (like the DDE server) that definitely are. Security boundary my arse.

Is this just a Win32 problem?

Probably, yes. The biggest mainstream competitor to Windows in terms of windowing systems is X windows. X is based on a similar underlying technique, that of queueing messages that are passed between windows. X, however, has two major differences. Firstly, a window in X is just a window – it’s a blank page on which the application can do what it likes. Unlike Win32 where each control is a window in its own right, a control in X is just a picture. When you click that control, you’re actually clicking the window surrounding it, and the application is responsible for figuring out whether or not there’s actually a control underneath your mouse and responding accordingly. Secondly, and more importantly, X messages are just notifications, not control messages. You can’t tell an X window to do something just by sending it a message. You can’t tell it to paste text. You can’t tell it to change the input limits on a control. You certainly can’t tell it to jump to a location in memory and start executing it. The best you can do is send it the mouse clicks or keyboard strokes that correspond to a paste command – you certainly can’t tell a control to paste in the contents of the clipboard. As such, it’s still theoretically possible for some of these attacks to work against X but in practice it’s highly unlikely. You could flood an application with fake messages and see how it responds; you could send it corrupt messages and see how it responds. Chances are, it would cope just fine, since it’ll choose what to do with the messages and process the flood one at a time.

Anyway kids, have fun, play nicely, be good. And remember – if it ain’t broke, hit it again.

———–