Hackszine.com: Network Security Archives

Archive: Network Security

Page 1 of 2 1 2 >>

January 7, 2009

Using memcached to rate-limit dictionary attacks

Earlier this week, there were a number of high profile Twitter account compromises that were made possible using a common dictionary attack technique. Basically, nothing was in place to keep an attacker from quickly submitting thousands of login attempts against an account, cracking the password in an evening of work.

One tool that can be used to prevent this sort of attack is to rate-limit login attempts, allowing only a few failed attempts per minute, for instance. One problem with this, however, is that it requires tracking login attempts. This is essentially a write operation, and doing this to a database on a high volume site is a major performance bottleneck.

Simon Willison came up with a nice solution to the problem that uses memcached. You can track a counter for requests from an IP and for login attempts against a particular account. Just create the key using a combination of the item you are tracking and the date it is being tracked against:

Let's say we want to limit a user to 10 hits every minute. A naive implementation would be to create a memcached counter for hits from that user's IP address in a specific minute. The counter key might look like this:
ratelimit_72.26.203.98_2009-01-07-21:45

Increment that counter for every hit, and if it exceeds 10 block the request.

According to a comment on Simon's blog, this is essentially the strategy that's been employed by the Twitter team to rate limit API requests.

Rate Limiting With Memcached

December 19, 2008

DNS Dead Drop - send secret messages with DNS

Landon Fuller put together a secret message passing system that exploits a feature of DNS servers. It's based on a hack first conceived by Dan Kaminsky, which allows you to set a single bit of data by caching a wildcard zone on a cache server:

In each DNS query, 7 bits are reserved for a number of flags, one of which is the Recursion Desired (RD) flag. If set to 0, the queried DNS server will not attempt to recurse -- it will only provide answers from its cache.

Combine this with a wildcard zone and it's possible to signal bits (RD on), and read them (RD off). To set a bit to 1 the sender issues a query with the RD bit on. The wildcard zone resolves all requests, including this query. The receiver then issues a query for the same hostname, with the RD bit off. If the bit is 1, the query will return a valid record. If the bit is 0, no record will be returned.

To send the message, the sender and receiver agree on a DNS server and a big list of secret words. A unique hostname is generated for each word in the list, each of which is used to set one bit of data in a remote DNS server. The receiver can come along at a later date and extract the message from the dead drop by querying those same names. It's a pretty inefficient way to transfer data, but who ever said secret spy messages needed to be efficient?

You can download Landon's program from his site. If you want to play with it, I'd recommend either just testing it with a short message or two, or using your own server. As you can imagine, it's a bit of a resource hog, since it requires a full lookup just to communicate a single bit.

The DNS Dead Drop
Attacking Distributed Systems: The DNS Case Study (PDF)

July 29, 2008

DJBDNS, DNS exploits, Bernstein, Schneier, and security by design

If you haven't been living under a rock, you've probably heard of the DNS vulnerability that Dan Kaminsky announced about a half year ago. The plan was that Kaminsky would be working with DNS server vendors to provide a patch, giving ample time for administrators to upgrade before the details of the exploit were released later this year. Unfortunately the exploit was leaked prematurely, causing a general freak-out mode amongst people that administer DNS systems.

When I read the article on Slashdot, the "all name servers should be patched as soon as possible" quote dropped a bit of scare on me too. What about my sad little DNS server? I envisioned spending an evening working through a time consuming process of patching and reconfiguring things that I haven't had to touch in years. Much to my pleasant surprise, djbdns, D. J. Bernstein's DNS server, was not vulnerable. My decision to use djbdns a number of years ago was primarily due to his vocal philosophy of engineering security by design instead of by response.

Bruce Schneier's analysis of things is spot on as usual. It's a solid case study for hygienic software engineering practices and the design of secure systems.

The real lesson is that the patch treadmill doesn't work, and it hasn't for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won't prevent every vulnerability, but it's much more secure -- and cheaper -- than the patch treadmill we're all on now.

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It's not that he discovers all possible attacks before the bad guys do; it's more that he anticipates potential types of attacks, and defends against them even if he doesn't know their details. I see this all the time in good cryptographic designs. It's over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

Kaminsky's vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That's exactly the work-around being rolled out now following Kaminsky's discovery. Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune to Kaminsky's attack.

The djbdns server wasn't pre-installed on the Linux distro I based my poor old server on. DJB's deamontools package, which manages the startup and shutdown of the service, was annoying to deal with when every other application just uses a normal init rc script. The dns server configuration and setup was also unfamiliar to me, having previously only worked with BIND zone files.

There's one other thing that has really been different with djbdns than any other DNS server I've ever administered: I've never had to patch it. I've only had one other software experience like this, with the qmail mail transfer system. Qmail is also designed by Bernstein. Hmm.

If you're upgrading your DNS server anyway, maybe now is the time to start thinking about your alternatives.

Daniel J. Bernstein's djbdns server
Schneier - The DNS Vulnerability
DJB on DNS forgery
Slashdot - Kaminsky's DNS Attack Disclosed, Then Pulled

July 27, 2008

Cyber Security Awareness Week

Dan Guido from the Information Systems and Internet Security Lab at the Polytechnic Institute of NYU wrote in about the Institute's 5th annual Cyber Security Awareness Week. If you're in high-school or a college undergraduate program, this is a great opportunity to test your infosec skills against your peers, and hopefully earn a little prize money in the process.

ISIS Lab is organizing NYU-Poly's 5th annual Cyber Security Awareness Week (CSAW) where students can compete and win prizes in a variety of information security challenges. There will be door prizes, raffles for participating, and bonus prizes for undergrad and high school participants. Qualified finalists will receive a travel scholarship to attend the awards ceremony in New York City.

There are a number of events, including an application security "capture the flag" challenge, a security quiz which covers everything from cryptography to risk management, and a 5-day forensics puzzle. There's even an embedded systems challenge where teams are tasked with trying to find hardware and software bugs in a mock control system.

This looks like a lot of fun. Some of the contest materials become available at the beginning of September, so sign up soon if you're interested in participating.

Cyber Security Awareness Week 2008

June 24, 2008

Videos from past Shmoocons

You may have dug the videos of past DEFCON conferences that we posted back in May, but there's a whole other infosec conference, Shmoocon, which is held in D.C. every February.

ShmooCon is an annual East coast hacker convention hell-bent on offering three days of an interesting atmosphere for demonstrating technology exploitation, inventive software & hardware solutions, and open discussions of critical infosec issues.

It's a while until the next conference comes up, but there have been some great presentations at past conferences, most of which are available online. Peteris Krumins recently assembled links to all of the videos and presentation files that are available at the Shmoocon site (including the 2008 conference), posting them to his blog as a single big index.

A quick search on YouTube also turned up a series of videos by Scott Moulton from Shmoocon 2007 and 2008 on the topic of data recovery for both traditional hard disks and flash drives. It's pretty fascinating stuff, whether you're interested in this from a forensics or security perspective, or if you've ever just wondered what exactly goes into recovering important data from a crashed disk when you send it out to a data recovery shop.

Hacking Videos from Shmoocon
Scott Moulton's videos on data recovery for SSD flash drives and hard disks
Shmoocon Infosec Conference

SafeHistory: protect your privacy from visited link analysis

A couple of days ago I wrote about the visited link javascript hack that lets any website operator query a user's browser history to determine if they've visited any other particular site. One possible use for this is to detect which Web2.0 social applications a user visits so that you can display the appropriate link badges.

It's a creepy scenario, though, that a website operator can effectively bypass the browser's intended security model to invade your privacy by seeing if you've been visiting other sites. Hackszine reader Logical Extremes commented with a solution to this problem:

This is a common phishing vector. Rather than encouraging broader use, we should be educating and protecting against it. There is a Firefox add-on that explicitly blocks this.

Some hackers over at the Stanford Computer Science Department created SafeHistory, a Firefox plugin that protects against visited link tracking techniques. It works by only allowing the a:visited property to apply to off-site links that were previously visited from the current URL.

This seems to be a reasonable way to keep the functionality of visited links without leaking any additional information. I wonder how long it will be before this is adopted as a browser behavior standard.

Stanford SafeHistory
Protecting Browser State Using Same Origin Policy (PDF)

Previously:
Detect which sites a web user visits

May 28, 2008

Detect which sites a web user visits

Aza Raskin's SocialHistory Javascript library allows you to do something incredibly cool: detect which sites your web users have visited on a per-user basis. The javascript runtime isn't supposed to be privy to the information in a user's browser history, but there's an information backchannel common to all major browsers which allows you to effectively interrogate the browsing history and determine if a particular URL has been visited before.

It works by creating an anchor link to the site in question and applying a CSS style to the link, specifying a different display property for "a:visited". By reading the computed style back from the anchor element, you can then determine the property's value, and consequently if the user had visited the URL or not.

This could probably be used for a number of devious purposes, but Aza's concept for the SocialHistory library is actually really useful. By querying the default URLs that belong to all the major social network sites, you can figure out which sites a particular user visits and custom tailor any social badges that you display. If they use del.icio.us, you show a del.icio.us link. If they visit Digg, you show the Digg button. It's an awesome feature made possible by a pretty freaky security leak.

Now, it's not perfect. It requires that you query the exact URLs that a user may have visited. You can't figure out everywhere they've been, how frequently, or in what order, only whether a particular URL that you know about has been visited before. On the other hand, it's a pretty useful tool considering you aren't even supposed to be able to do this.

How to Detect the Social Sites Your Visitors Use
SocialHistory.js

May 11, 2008

A VAX in your Linux box

Like many, my first introduction to the Internet came by way of a VAX/VMS server operated by the local University where I lived. A friend of a friend scenario landed me an account on the system, and after about a week I was hooked. It wasn't long before I signed up for a night class so that I could parlay an official student record into an account of my own (I was in high school at the time).

I was recently wondering about what's happened with OpenVMS. Is it still around? Will it run on normal PC hardware?

It turns out there are still a number of VMS devotees and hobbyists out there, and OpenVMS can still be found running not only on hobbyist legacy systems, but also in modern server environments where security, fault-tolerance, and uptime command a high premium over hardware cost and operating system popularity. There's even a freely available hobbyist license for OpenVMS, and you can get the installer media shipped your way for $30.

But what do you run it on if you don't have a VAX or Alpha in your basement? An emulator, of course! The SIMH emulator, created by the Computer History Simulation Project, is capable of emulating a DEC VAX and will run on a Linux, Windows or OS X host machine.

The most difficult thing, from what I've read, is that you need to jump through a number of hoops to get the OpenVMS license and media and the license needs to be renewed yearly. Phillip Wherry wrote a very extensive howto in 2004 that walks you through obtaining the media, building and configuring the SIMH emulator in Linux, and installing OpenVMS on your virtual VAX. If you want to run OpenVMS on Windows or OS X, there are pre-compiled SIMH binaries available for both platforms. The installation process should be the same for whichever host system you use.

Keep in mind that Phillip's howto was written in 2004, and I haven't gotten my OpenVMS hobbyist license yet, so I don't know for sure if there are any gotchas in there. The DECUS user group still seems to be alive and the company that ships the OpenVMS media is still taking orders, which is a pretty good sign. If any readers out there are currently running this setup, please give us an update in the comments. I'm excited to see some of my old DCL scripts running again, so I'm keeping my fingers crossed for good news here.

Running VAX/VMS Under Linux Using SIMH
SIMH VAX Emulator (Linux and Windows)
SIMH binaries for OS X
Encompass - DECUS User Group (Sign up for membership which is required for the license and media
Order Form For OpenVMS Hobbyist CD Media

May 4, 2008

Videos from past DEFCONs

I wasn't able to make it to last years DEFCON hacker/security conference, and DEFCON 16 isn't until later this summer. As you can imagine, I've been a little impatient for a good ol' info-security paranoia fix. Thankfully, it looks like a ton of videos from past conferences have been posted to the DEFCON site. This might be pretty interesting to even the die-hards in the crowd who religiously attend. Having been to a couple of these, it's pretty hard (read: impossible) to get into all the sessions you would like to hit.

The more recent content is encoded as mp4's. Unfortunately, you'll need Real Player to view much of the older content. It's better than nothing, though.

It also looks like there have been a number of sessions from DEFCON 15 encoded and uploaded to Google Video. I've included a link to a list of these below as well.

Defcon Media Archives: 1993 - Present
Links to DefCon 15 Session and Panel Videos on Google Video

April 29, 2008

Stop XSS attacks with SafeHTML

If you allow user-contributed content in your site, you run into the problem of dealing with user supplied HTML in a safe manner. The most secure way of dealing with things, of course, is to strip or escape all HTML from user input fields. Unfortunately, there are many situations where it would be nice to allow a large subset of HTML input, but block out anything potentially dangerous.

SafeHTML is a lightweight PHP user input sanitizer that does just that. Just run any input field through the SafeHTML filter and any javascript, object tags, or layout breaking tags will be stripped from the supplied text. It also does a reasonable job of correcting any gnarly, malformed code, which is also a common problem with user-contributed data.

Using it is easy. Just instantiate the SafeHTML object and call its parse method:

require_once('classes/safehtml.php'); $safehtml =& new SafeHTML();
if ( isset( $_POST["inputfield"] ) ) { $inputfield=$_POST["inputfield"]; $cleaninput = $safehtml->parse($inputfield); }

This will take the posted "inputfield" parameter, strip any baddies, XHTMLify what's left, and the result will be stored in the $cleaninput variable. It's a simple addition to your code, and a lot more straightforward than trying to roll your own.

My only beef with the package is that it's written with a default allow policy, stripping out tags that are in its deleteTags array, but essentially allowing anything else through. If you'd rather only let through tags that you specifically want to allow, I'd recommend adding an allowTags array and adjusting the _openHandler method, adding the following after the deleteTags check:

if ( ! in_array($name, $this->allowTags)) { return true; }

You'll need to fill allowTags with everything you know to be safe and welcome, and you may miss a few that people will end up wanting to legitimately use, but this is easily corrected and the default deny policy is much safer in the long run.

SafeHTML - an anti-XSS HTML parser, written in PHP

April 4, 2008

Add keystroke user verification to Gnome

Nathan Harrington amended the GNOME Desktop Manager to include keystroke dynamics in the user verification process. When the user enters their username, the timings between key press events are measured and compared against a stored pattern. The theory is that there is a significant difference in timings for words typed by different individuals, so the way a username is entered provides a bit of extra "fingerprint" information that can be used to help authenticate a user.

I'm not sure how immediately useful this will be, since this particular example won't affect other login methods, such as an ssh session. Nevertheless, the idea is pretty cool and the code is all there for you to monkey around with.

Identify and verify users based on how they type [via slashdot]

March 4, 2008

Ram dump over Firewire

Unlike USB2, the Firewire spec allows devices to have full DMA access. By impersonating the appropriate device, a PC can essentially obtain full read/write access to another machine's RAM, just by connecting the two machines with a Firewire cable. Adding to the recent discussion about the insecurities of physical access and Princeton's cold-boot RAM dump demonstration, Adam Boileau released a Linux Firewire utility that will give you immediate Administrator to an XP machine:

It's two years later, and I think anyone who was going to get the message about Firewire has already got it, and anyone who was going to be upset about it has got over it. Besides, according to Microsoft's definition, it never was a Security Vulnerability anyway - screensavers and login prompts are - as Bruce says - about the Feeling of Security. Anyway, today's release day for Winlockpwn, the tool I demoed at Ruxcon for bypassing windows auth, or popping an admin shell at the login window.
...

Yes, you can read and write main memory over firewire on windows.
Yes, this means you can completely own any box who's firewire port you can plug into in seconds.
Yes, it requires physical access. People with physical access win in lots of ways. Sure, this is fast and easy, but it's just one of many.
Yes, it's a FEATURE, not a bug. It's the Fire in Firewire. Yes, I know this, Microsoft know this. The OHCI-1394 spec knows this. People with firewire ports generally dont.

Adam's tools include a few Python apps that can copy and impersonate Firewire device signatures, dump RAM on a remote machine, bypass Windows authentication, and extract BIOS passwords. It's not exactly comforting, but I've got a new appreciation for Firewire now. This is the sort of access that used to only be possible by creating hardware that physically connects to the PCI bus. Now all you need is a cable and a laptop.

Firewire, DMA & Windows - direct memory access over Firewire - [via] Link

February 23, 2008

Remote file access through email

Shantanu Goel put a proof-of-concept Outlook macro together that will send you files in response to a specially formatted email. The idea is that you can activate this and leave Outlook running on your computer at work and if you are offsite and need to grab a document it's only an email away.

This project came into being after reading this post at lifehacker (original post and solution here). It listed a method to retrieve mails on your home/office PC by sending a "magic email" to it, but it was only for mac's. Seeing that people wanted it for windows as well, I thought of making something up during lunch time at office.

If you think about it, this is kind of a clever way to get around a corporate firewall. It'd be funny to add some directory listing functionality to it and formalize an email file transfer protocol.

Remote File Access Through E-Mail -Link

January 22, 2008

Van Eck phreaking

In 1985, Wim van Eck published a paper which described how the state of a CRT monitor could be reproduced remotely based on the device's electromagnetic radiation. Van Eck or TEMPEST devices, whatever you prefer to call them, aren't just the secret sauce in your favorite science fiction, though for some reason there hasn't been a lot of amateur or open source activity here. I'm not sure why, but I suspect as software radios become more affordable, people will start experimenting more in this space.

There are two open source Van Eck projects that I know of. The first, pictured above, is Erik Thiele's Tempest for Eliza project. By drawing specific black and white patterns on your monitor, Tempest is able to generate audible signals in the AM range. You can use Tempest to play an mp3 file that you can tune in on your radio.

Tempest for Eliza is a fun demo, but what about being able to read someone's monitor remotely?

There's a second open source project, called EckBox, that claims to do just this. By piping the audio from a radio through an 8-bit analog to digital converter, EckBox claims to be able to read this data from a PC parallel port and reproduce the image of an 800x600 monitor. Looking at the code, it seems almost too simple to be true. Likewise, the project hasn't been updated since June 2004 and there aren't many references or screenshots or words of success floating around the net. Anyone with a parallel port and an ADC want to give this a shot and let us know how it works?

Tempest for Eliza - Link
EckBox - Link

Further Reading
Wim van Eck's Paper (PDF) - Link
Compromising Emanations (Markus G. Kuhn, PDF) - Link

December 30, 2007

Eavesdropping on Bluetooth headsets

Here's a short video in which Joshua Wright demonstrates how a Bluetooth headset can be hijacked, allowing audio to be captured or sent to the device:

Few users realize that Bluetooth headsets can be exploited granting a remote attacker the ability to record and inject audio through the headset while the device is not in an active call. SANS Institute author and senior instructor Joshua Wright demonstrates.

All that is necessary is knowing the device address, which can be easily sniffed, and the secret pin, which defaults to 0000. The headset audio is tapped while not in a call, so any room conversation the headset's mic can pick up can potentially be listened to remotely.

Page 1 of 2 1 2 >>