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

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

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

See also: Videos from past DEFCONs

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

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

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

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

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

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]

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

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

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

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.

A couple of months ago, 100 government and embassy email account passwords were published by Dan Egerstad. What did these email accounts have in common? Individuals from these organizations were presumably using the TOR network to protect their communications, but by sending unencrypted traffic over the TOR network, they were actually exposing this data to a lot of potentially nefarious parties. But wait, the data moving over the TOR network is encrypted, right?

Which brings us back to the exit node. Your data leaves the TOR network in its raw form. So if you are using an unencrypted protocol, your communication can be read (or modified) by the exit node or anything between the exit node and the destination server. So while your immediate ISP can't really tell who you are sending packets to, someone at an exit node can, and chances are good that that someone is more interested in your communications than the average server on your normal routing path.

This someone might be a government entity, a criminal organization, or maybe just some Swedish security researcher dude who is interested in what's going over his five exit nodes and decides to publish the more interesting tidbits for the world to see.

Just to give you something to think about we did look into a few servers out of 1000 we thought looked interesting. We aren't trying to tell you what to think, you will have to do that yourself.

Example of Exit-nodes that can read your traffic:

• Nodes named devilhacker, hackershaven...
• Node hosted by an illegal hacker-group
• Major nodes hosted anonymously dedicated to ToR by the same person/organization in Washington DC. Each handling 5-10TB data every month.
• Node hosted by Space Research Institute/Cosmonauts Training Center controlled by Russian Government
• Nodes hosted on several Government controlled academies in the US, Russia and around Asia.
• Nodes hosted by criminal identity stealers
• Node hosted by Ministry of Education Taiwan (China)
• Node hosted by major stock exchange company and Fortune 500 financial company
• Nodes hosted anonymously on dedicated servers for ToR costing the owner US$100-500 every month
• Node hosted by China Government official
• Nodes in over 50 countries with unknown owners
• Nodes handling over 10TB data every month

We can prove all this but not the intentions of each server. They might be very nice people spending a lot of money doing you a favor but it could just as well be something else. We don't however think it's weird that Universities are hosting nodes, just that you need to be aware of it. Criminals, hackers and Governments are running nodes, why?

The moral of the story is that you shouldn't use TOR for the purposes of secure communications. You should be using TOR to anonymize routing. If you are passing indentifiable information over the wire that you don't want read, such as your email or bank information, you need to use a secure end-to-end encrypted channel, like ssh, https, or ssl-imap. What TOR provides is a mechanism for anonymizing the routing of your communications so that people in your routing path don't know who you're sending a message to.

Moral #2 is that information you send through the TOR network is more than likely under higher scrutiny by many interested parties. Encryption matters here more than anywhere else.

How 100 sensitive accounts were compromized - Link
Anonymity and the Tor Network (Schneier) - Link

This code (it takes a several seconds to load) uses a piece of JavaScript to instantiate a Java socket call back to the origin site. In doing so it bypasses the proxy settings of the browser, allowing you to de-anonymize people using proxies. It works great for Tor or just about any HTTP proxy that I can think of. Cool stuff.

Ouch.

A safer anonymizing solution might be to route all traffic through a transparent proxy, while also blocking all traffic not destined for port 80.

De-anonymizing Tor and Detecting Proxies - Link

Universal Plug and Play support is available on most modern wireless and DSL routers. Among other things, it allows client machines on the local network to remotely configure the router's port forwarding, typically without authenticated access.

Adrian Crenshaw has a nice screencast which shows how to detect UPnP capable devices on your network and how to use the PortForward utility in Windows to remotely configure port forwarding for routers on your LAN.

After looking at this, you'll probably come to the conclusion that, while convenient, unauthenticated UPnP is pretty dangerous. It allows someone who has momentary access to your network to easily reconfigure your router to punch holes through its NAT firewall. This could be somone on your wireless network, or it could be as simple as a malicious program that you accidentally execute on your own machine.

Fortunately, most routers allow you to disable UPnP, and you should probably take advantage of this and turn off UPnP on your devices now.

UPnP Port Forwarding and Security Screencast - Link
UPNPScan - Link
UPNP PortForward (exe, source and documentation) - Link

When you're on an untrusted or unencrypted network, everything from what you browse to the email and IM messages you send can potentially be snooped by a third party. Sure, some sites use https and you can use ssh to connect to a remote server, but what if you want to jack in and enjoy the relative comfort of knowing _all_ of your applications are communicating over a secure channel?

For that, you need a secure proxy. By setting up a SOCKS proxy, you can have your applications route all of their network communications through a secure connection to a network you trust. Gina at Lifehacker put together a quick guide for setting this up, and once configured in OS X's System Preferences, most of the default apps like Safari will just start using your proxy and you're good to go.

A lot of your favorite applications--ie. Firefox and Adium--need to be manually configured to use the proxy, however, as they don't pull this information automatically from the system preferences. This is straightforward to do, but it means that every time you cruise over to the local coffee shop, you need to set up your proxy configuration in multiple places.

Albert Lee came up with a nice solution to this problem. An application profile manager called rooSwitch and some quick Actionscript is all you need to make a couple of command line scripts that will set up or tear down your proxy, as well as switching all of your application preferences.

If you save this script with a .command extension, then you can run it by double-clicking on the icon in the Finder like a regular application. When it runs, it will change the location, switch your profile, and start up the SSH tunnel. Enter your password and off you go!

I should mention that his script also introduced me to a useful mac command line utiliy called scselect. By typing scselect [locationname], you can switch your Mac's location straight from the command line.

Safer Surfing on Untrusted Networks (Mac Edition) - Link
How to configure an SSH SOCKS proxy @Lifehacker - Link
rooSwitch - Link

Packet Garden is a network visualization tool that maps your network traffic into a 3D representation, sprouting little plants on a globe whenever a connection is made.

To do this, Packet Garden takes note of all the servers you visit, their geographical location and the kinds of data you access. Uploads make hills and downloads valleys, their location determined by numbers taken from internet address itself. The size of each hill or valley is based on how much data is sent or received. Plants are also grown for each protocol detected by the software; if you visit a website, an 'HTTP plant' is grown. If you share some files via eMule, a 'Peer to Peer plant' is grown, and so on.

Packet Garden is GNU licenced and written in Python, so you can give it a try on supported Linux, Windows, and Mac machines. It doesn't run on Intel macs, unfortunately. As far as I can tell, Soya3D (the 3D library it uses) is the culprit and has not been compiled under this architecture. Anyone want to take a stab at porting this? I'm not familiar with the package, but it might be as simple as installing all Soya's required libraries and running a python make script.

Packet Garden. Grow a world from network traffic - Link
Soya3D - Link

Normally, the security mechanisms in your browser restrict any communications to the same host that served the web page. So, if you visit badsite.com, the javascript in that page will only be able to communicate with badsite.com. Any code on that site that attempts to pull data from any other address will return an error, because it violates this "same origin" policy.

How DNS Rebinding Works
DNS rebinding allows an attacker to completely bypass the same origin policy. It does this by dynamically switching the target IP address for a host name the attacker controls. One scenario might work like this:

1. You connect to abcde.badsite.com, which resolves to IP 1.2.3.4 with a very short TTL
2. 1.2.3.4 delivers some Javascript code to your browser to execute in 15 seconds
3. The DNS server in control of *.badsite.com immediately points abcde.badsite.com to 10.0.0.1
4. 15 seconds later, the Javascript on your browser connects to abcde.badsite.com, in compliance with the same origin policy, and retrieves a web page from your internal server at 10.0.0.1
5. The DNS server resets abcde.badsite.com to 1.2.3.4 and after some period of time, your browser reconnects and sends 1.2.3.4 its findings

With Flash, It Gets Even Better
So far, with Javascript, a nefarious attacker now has the ability to scan and crawl websites on your internal network and report its findings back to the attacker's server. You could imagine this being triggered via a popup and then repositioned off the screen where it might go unnoticed for some time. This is a pretty big deal, no doubt, but with Flash 9's Socket functionality, it's only the tip of the iceberg.

Flash 9 adds a Socket library to the developer's toolkit. So instead of the limited web crawling payload, a small flash movie can be sent to the client which can do a full network scan of your internal network, send spam through your corporate SMTP server, or even serve as a general purpose VPN bridge right through your firewall.

Wow.

Defending Against DNS Rebinding
There have been a number of suggestions made as far as defending your network against this kind of attack, including disabling the Flash plugin, using a personal firewall to restrict browser access to ports 80 and 443, and making sure all your web sites have no default virtual host, but instead require a valid Host header.

It seems like the real moral of the story here, though, is not to be lured into using a Firewall and unaddressable IPs as your only line of defense. This means keeping machines patched, not using IP address-based authentication, and, in general, presuming that the attacker can obtain access to your internal network.

References:
Your Browser is a TCP/IP Relay - Link
Flash DNS Rebinding DEMO (scan a host on your network) - Link
Protecting Browsers from DNS Rebinding Attacks - Link

First, both machines open a connection to a non-firewalled server. The server takes note of the source port (which may have been altered by the firewall) and sends this information to the other party to give it an idea of what port future connections might be coming from.

Client A then attempts to connect to a range of ports on client B's machine. All these requests will fail at client B's firewall, of course. However, in the process a side effect has occurred. Client A has told its own firewall to allow traffic from all of client B's scanned ports! Now, when client B attempts to connect to client A, assuming its outgoing port was previously scanned (which it likely will be), the request will get through to client A's machine.

If all else fails, both machines can use a central server to proxy their connection, but the UDP hole punching trick will typically allow two NAT firewalled machines to communicate directly, which means less latency and a significantly lighter load on the server.

Resources:
How Skype & Co. get round firewalls - Link
RFC3489 STUN - Simple Traversal of UDP through NAT - Link

The Upside-Down-Ternet works like this:

1. You set up a DHCP server to assign addresses from one IP netblock to known MAC addresses, and another "untrusted" netblock to unknown MACs.
2. The trusted netblock is routed normally, but the untrusted netblock gets all port 80 traffic forwarded to a transparent squid proxy using iptables.
3. The squid proxy filters all HTTP traffic, looking for URLs ending in jpg or gif.
4. If a jpg or gif is encountered, the image is flipped using morgrify and the untrusted user is sent the upside down image instead of the original.

This could be easily modified to default to giving normal access. You could then direct known abusers to the crippled network. Another option would be to provide "degraded" access using a blur or desaturate filter on images. This would allow people to make use of the free service, but would require them to ask permission to be on the trusted list before having full access.

How do you like to deal with wireless interlopers? What's your ideal wireless setup - one that balances security, ease of use for legitimate visitors or passers-by, and quality of service? Give us a shout in the comments!

Our resident Windows hacker, Preston Gralla, has another great article up at Computerworld, this time about maintaining your online privacy in the face of increased snooping from the government, web sites, and private businesses (an expanded update to a hack of the same name that originally appeared in Windows XP Hacks, 2E).

Related:

• Windows XP Hacks, 2E
  
• Call for Hacks: Windows Tips for Everyone

The motive for the attacks was unclear, said Duane Wessels, a researcher at the Cooperative Association for Internet Data Analysis at the San Diego Supercomputing Center. "Maybe to show off or just be disruptive; it doesn't seem to be extortion or anything like that," Wessels said.

The goal of Hackszine is "to reclaim the term 'hacking' for the good guys--innovators who explore and experiment, unearth shortcuts, create useful tools, and come up with fun things to try on their own", and it confirms our faith in this when we see one of our hacker authors working on the side of the good guys.

Related

• RIPE NCC DNS Monitor (pictured) - Link
• Make Projects: Small Form Factor PCs PDF - Link

More often than not, though, the network is configured to allow ICMP packets through unfiltered. If you find one of these lucky hotspots, you can ping google.com or another external server and you'll get a response back. You can use this feature to tunnel TCP traffic through an ICMP echo request to a proxy server that you've set up on an unrestricted network!

Ptunnel is an application that allows you to reliably tunnel TCP connections to a remote host using ICMP echo request and reply packets, commonly known as ping requests and replies.

Setting: You're on the go, and stumble across an open wireless network. The network gives you an IP address, but won't let you send TCP or UDP packets out to the rest of the internet, for instance to check your mail. What to do? By chance, you discover that the network will allow you to ping any computer on the rest of the internet. With ptunnel, you can utilize this feature to check your mail, or do other things that require TCP.

To use Ptunnel, you'll need a server to run the proxy on. Your bandwidth will be a bit limited, but the software includes a simple authentication mechanism so that you can ensure you're the only one using your proxy. The way it works, it's more useful for connecting to your server via ssh than it is browsing the web. That said, it's pretty darn cool and awfully handy, especially if you need to check your mail and don't feel comfortable passing a credit card to a random wireless account server.

Download Ptunnel here and give it a shot - Link.
Nulldigital.net has a good writeup on configuration and usage - Link.

Related:

• WiFi Liberator
• Wireless Hacks, 2E