Posts tagged "security"

clinicallyawesome

Bogus Log Generator

I wonder what the legal implications might be of a framework that makes it easy to create generators for bogus but convincing log data.

Prosecution: “Your honor, I present to the court computer logs that show that the defendant participated in online activities for which he is charged.”

Defense: “Your honor, I present to the court computer logs that are completely falsified but are completely indistinguishable in form from the logs presented by the prosecution.”

Flying Monkies, GO!

clinicallyawesome

Anonymizer Universal on Anroid

While at Anonymizer I got to use Anonymizer Universal and I thought it was pretty sweet. It doesn’t take long with a packet sniffer on a popular public wireless access point to see that you have little protection if any without some sort of VPN. Anonymizer Universal is a commercial VPN service that protects your traffic on the local network and allows it to exit through Anonymizer. I got it working on my Android phone using a little hand-configuration. This doesn’t require the phone to be rooted/jailbroken; it’s part of the standard functionality. Note that while it works, it’s not a supported platform…

clinicallyawesome

wepwn

Some months ago I wrote a couple scripts to capture the workflow of cracking WEP. Essentially you could use the scripts to scan for targets and then specify the target to attack by ESSID or BSSID.

I came into a situation where I needed to learn python so I consolidated those scripts into a single python script and that is wepwn. It was developed on Backtrack 4 but may work on other Linux distros without modification.

I was reluctant to release it without much testing but it’s not going to get much testing in my environment beyond what I’ve done. I’d appreciate feedback, bug reports, or patches. Enjoy.

clinicallyawesome

AssRace: Possible Advantage For A Rogue DHCP Server

One method for MITM attacks is to set up a rogue DHCP server. In this situation you’re in a race with the real DHCP server and you may not always (if ever) win.

I’ve been sitting on an idea for a couple weeks where under certain circumstances you could have a distinct advantage in the race. Specifically when the DHCP client is on WiFi. Before WiFi clients pull DHCP they usually have to associate with the access point which involves an exchange of packets. The idea was that you could have your rogue DHCP server listen for clients associating then immediately start spamming the client with appropriate DHCP replies. In this scenario you may be able to get your reply in before the client has even finished sending the request. The cool thing here is that if the network is encrypted but you’re wired in and the wireless just bridges to the wired network you don’t necessarily need the encryption key. You can see the association in the clear then start sending your DHCP messages on the wired network destined for the new client on the wireless network. Because that MAC address hasn’t been seen yet the switching infrastructure should just unicast flood the message everywhere so it should get to the target.

This morning I realized I’d probably never get around to actually implementing this idea, which is a shame given the snazzy name. I was looking at the RFCs for DHCP and it looks like the client picks an ID number and if your replies didn’t have that ID number then the attack probably wouldn’t work. Since you’re sending replies before you’ve seen the request you can’t know what the request is. Perhaps if you’re on the wireless network and the DHCP server is on the wired network you have a few microseconds of a head start. Perhaps you could guess the ID number the client will use somehow. Perhaps I’ve misinterpreted the RFC, I didn’t read through it closely. All that aside, maybe this will give someone else some workable ideas.

clinicallyawesome

From Stored XSS to DDoS, almost

The backbone of science is sharing your failed experiments so here goes.

I was a little frightened when directed to RFC 2397. Basically it says that included objects that you would reference by a URL can be provided inline in one or more forms. It looks like this:

<img src=”data:image/png;base64,alkj2K09…..” />

Try it. It’s kind of neat-o. The idea I had was that maybe you could provide a java applet that way. You can already deliver an applet by reference with XSS but an applet is only supposed to be able to make connections back to the site that it was downloaded from. If you try to connect to anything else, like the target site, it generates a pop message that the user has to click through. If I could get the target site to provide the applet it should be able to connect back to the target site without the user being aware.

The fun idea I had was to write a java applet implementation of the slowloris attack. The really awesome thing if this were possible is that if you find a stored XSS vulnerability in the target site you could get the legitimate users of the site to DDoS it indefinitely. Beyond that, you may be able to make SSH or other authenticated connections back for random password guessing; perhaps the results could be reported back to the attacker via DNS requests. The difficulty (if it worked) is that the target site would have to allow a pretty large stored XSS. If the stored XSS vulnerability is against a TEXT database column you’re fine. If it’s against a VARCHAR(128) and you’re trying to deliver a 1.2KB jar file it’s not going to work.

I could get the applet to work flawlessly at attacking my test web server. It would sometimes even do so without the socket connection sandbox permission dialog from popping up. It wouldn’t work properly with the inline jar file though. Eventually I tried Firefox+Sun JRE on windows and it gave me the error message I needed: unknown protocol: data or something similar.

Maybe this could still work with Flash or some funky contortions with JNLP. I, however, am done working on it.

clinicallyawesome

DoSassination Market

From Wikipedia:

An assassination market is a prediction market where any party can place a bet (using anonymous electronic money, and pseudonymous remailers) on the date of death of a given individual, and collect a payoff if they “guess” the date accurately. This would incentivise assassination of individuals because the assassin, knowing when the action would take place, could profit by making an accurate bet on the time of the subject’s death. Because the payoff is for knowing the date rather than performing the action of the assassin, it is substantially more difficult to assign criminal liability for the assassination.

What if a site existed where there would be various pools for betting on when a given site’s Denial of Service attack would end. The rules would state that the betting pool site would attempt to retrieve a given site’s root page in its entirety. If it succeeded it would make 9 more attempts randomly dispersed over the next five-minute period. If all of those subsequent attempts succeeded the site would be considered “up”. If any of them failed, the test would begin again after a random delay of between 5 and 60 minutes.

To win the betting pool, Bob has to add to the pool and he has to guess when the DoS will end. The best way for him to make that guess is to extend the current DoS attack with his own and then end his on the moment of his prediction, hoping that any other ongoing attacks have also ceased. As more people participate in this flash DoS, the betting pool grows, bringing more interest to the “contest” and more people who will try their own DoS to win the pool.

clinicallyawesome

So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users

If you have to deal with security in any kind of professional capacity it is worth your time to read the the 10.5 pages of text in tihs paper.

clinicallyawesome

elitehackercontest.meh

Brilliant idea of the day.

I register the domain, “elitehackingcontest.org” or somesuch nonesense. I make sure the website says that the target sites are “realistically simulated Internet sites”. I then just pick random sites on the internet and point target1.elitehackingcontest.org.

I then advertise the crap out of it and let hilarity ensue.

clinicallyawesome

Properly Deploying a Private CA Cert in Ubuntu

I think the true strength of the certificate PKI is the ability to set up a CA for your organization and mint your own certs. You get the advantage of proper certificate validation without the cost of paying a third party to validate your identity (snicker).

There are copious sets of instructions on how to create your own CA but I had a very difficult time finding proper instructions on deploying the cert to clients. Most of them simply say, “post it on your web server, visit it in your browser, then click Trust.” That’s fine on your computer but what about a larger organization. Are you going to just tell all your users to do this and expect them to get it done? What about multiple browsers? That kind of solution just doesn’t scale.

In my personal environment my clients are Ubuntu Karmic. I’ve seen some kind of hackish solutions where you put the cert in /etc/ssl/certs then add softlinks or run c_rehash if you’ve read some man pages. After searching the Internet and not getting far I finally started digging through /usr/share/doc/ca-certificates and found the README.Debian file. It states that the proper way to install private CA certs is to put them in /usr/local/share/ca-certificates and ensure that the names end in .crt. Once that’s done you run update-ca-certificates and the appropriate linking is done for you. With that complete you may need to start your various clients but it should be working for your command line web tools and graphical browsers.

I said visiting a URL in the browser and having users click through dialog boxes was unrealistic. Frankly, it’s cumbersome, but is copying the file out to each machine and running a command any better? Because I run cfengine, absolutely! My additions look something like this:

control:

    AddInstallable = ( ... NewCACert  )
...
directories:
    /usr/local/share/ca-certificates owner=root group=root mode=0666
...
files:
...
   $(masterfiles)/CA/cacert.pem
      dest=/usr/local/share/ca-certificates/lub-dub_CA.crt
      mode=0444
      owner=root
      group=root
      inform=true
      encrypt=true
      define=NewCACert
      server=$(policyhost)
...
shellcommands:
...
   NewCACert::
      "/usr/sbin/update-ca-certificates"

The only thing missing is the fact that while my desktop systems are Ubuntu my server systems are Debian Lenny. The Karmic version of ca-certificates is 20090814 while the Lenny version is only 20070303. The update-ca-certificates script in the Lenny version doesn’t look in /usr/local/share/ca-certificates so I’ve had to add that myself.

clinicallyawesome

Mitre's 25 Most Dangerous Programming Errors

I look at those things and I fear that people will look at it as “Oh, as long as I do these n items I’m fine.” Those people convince themselves they’re safe when they’re not. If your application has error #26, or #52, or #375, it’s still broken, it’s still insecure. The attackers don’t care if your application has RFI, SQL injection, or has a backdoor account. Anything that lets them in is fine.

In my mind I criticize these kinds of lists but really I think usually the people that make those kinds of lists are earnestly trying to help people and improve the situation. I just think their approach is futile. Then I ask myself if I have a better solution and of course I don’t.

I wonder how long each of the programming errors on that list have been spoken about on the Internet as a hazard. I’m sure each one has been discussed ad nauseum on lists like this for a few years at least. Still, we have programmers who don’t care, programmers who don’t bother reading the list, programmers not aware of the list, and “programmers” who wouldn’t understand the list if it were right in front of them. There is an endless supply of new, bad, and apathetic programmers to replace any corrected by such lists.

Do lists like this make things any better?

clinicallyawesome

Microwave + RFID = Plasma

It would appear that RFID chips in a microwave make plasma, and plasma melts glass microwave turntables. While I understand the latter, I was not expecting the former. The impressive thing was it kicked off at about 2.5 seconds. I wonder if it would have been “safely” destroyed in a glass jar submerged in water, this being a bank card.

Hopefully I’ve never made claims that I’m notably smarter than anyone else.

clinicallyawesome

PCI

The security of a transaction-processing network varies inversely with the value the operators place in PCI.

clinicallyawesome

0(mfg)day

The term 0day has lost any significance in meaning. The original meaning was that a public vulnerability disclosure was made and the same day someone produces a working exploit.

Now 0day can mean a lot of things. It usually means something to the effect of “an exploit for which there is no patch available” but depending on who you ask it might mean “an exploit that’s leet because I wrote it”.

I’d like to throw some terms out here that are much more sensible than 0day. The scary thing about 0day is that there’s isn’t a fix for it. Perhaps in one situation it’s because no one knows about the vulnerability. Maybe the exploit was discovered being used in the wild. In any case, the fear is not that some shadowy person or organization has an exploit that they aren’t sharing; the scary thing is that there’s no fix. It is an unpatched vulnerability. If last Wednesday there was an announcement on bugtraq of a vulnerability in Flash, and today you got hacked (because it’s not Adobe’s Patch October yet) you didn’t necessarily get hacked by 0day. You got hacked by an unpatched vulnerability. Maybe the exploit was created the day of the announcement, maybe it was created days later. It doesn’t matter. You got breached because there was no fix and you didn’t disable Flash.

The term unpatched vulnerability is being used here and there on the Internet already. A term that isn’t being used but really should be is proprietary exploit. At the time of this writing a google search for “proprietary exploit” (quotes included) returns 449 results. When people talk about 0day exploits because they want to sound cool, what they’re often thinking of are proprietary exploits. These are exploits that aren’t being shared. Maybe the vulnerability isn’t patched, maybe it’s not even publicly known. That’s really the essence of the threat with proprietary exploits: maybe people are breaching your systems using attacks your scanners can’t detect because no one even knows there’s a vulnerability. That’s why people use the term wanting to sound cool, “I’ve got 0day so you can’t keep me out.” Perhaps after some high-profile compromise (Google/Aurora) people will capture samples of the exploit code and figure out what the vulnerability is.

Anyway, the purpose of this is not to inspire fear for threats you can’t fully defend against. I’m just sick of the term 0day and the way it’s used by people who don’t know what they’re talking about. If you understand the difference, will you pick terms with less ambiguity and media baggage?

clinicallyawesome

Spoofing For Charity… or Not

The media is reporting a lot about SMS charities. You send a text message to a certain number and your cell phone company bills you $10 or whatever. The company keeps a percentage or flat fee and passes the rest on to a charity. It’s a very convenient way for charities to get money. Of course it’s huge for Haiti charities.

What if you set up your own SMS “charity”. Then you get yourself a PBX system that can send text messages with whatever caller/sender number you want. You then send out texts to thousands of cell numbers with the caller/sender as your charity number. The messages you send are those that are likely to illicit a response, even if just a “WTF?”. Perhaps they say, “Where are you?” or “Who is this?” or “I just found out she’s bi” or “Mom’s dead” (thanks Aaron). People reply to ask you who you are or what you’re talking about and boom you just made $10.

Maybe if you’re nice(ish) you spoof the number of a real charity. Of course, a lot of those people would want it taken off their bill which means it would have to be taken back from the charity. This would really be the opposite of nice(ish).

clinicallyawesome

Locks… not so much

I started practicing lockpicking with a basic set of lock picks. So far I’ve really just been raking and I’ve found that the C rake works best for me. I’ll eventually work up to per-pin picking but for now I happy just having success raking and getting a feel for things.

I’ve been practicing on a cheap padlock I got at a grocery store. A few minutes ago I took a try at my second lock - the deadbolt on my front door. First try took about 30 seconds to figure out the space I could move the rake in. Once I started raking it took about 10 seconds. Thinking I might have gotten lucky I locked it again and it took about 5 seconds to find the working space again and then another 10 seconds to rake it open.