Hey Radio Shack. It's us, the makers.

Do you remember in the 80s and 90s, when half of your stores' real-estate was dedicated to sliding pegboards of myriad components 3 layers deep, Engineer's (Mini) Notebooks by Forrest M. Mims III, genuinely good electronics experimenter kits, prototyping breadboards (not these) and Tandy/Archer/Heath-branded customer-soldered kits that were genuinely useful?

We want it back. You see, DIY electronics is en vogue again. Guitarists are excited about their stomp boxes. Teenagers are building awesome robots that are more than just cheap plastic toys. The economy is fostering a serious DIY revolution. People are going on MakeCations (staying at home, making things) or doing weekend projects instead of weekend road trips. We are once again learning how to fix our ailing gadgets rather than chucking them into the garbage, and looking for ways to make our own simple and useful electronic gizmos and toys instead of buying them. It's cheaper and a lot more fun. Building and fixing things yourself instills a sense of joy. Who doesn't LOVE a sense of joy!?

Just as the old-school PIC gave way to the easier-to-use BASIC Stamp, the electronics deities have given us the Parallax Propeller and Atmel AVR Microcontrollers, and the easier-to-use pre-packaged versions: SPIN Stamp and Arduino. There are literally thousands of well-documented and useful projects out there for budding electronics engineers and computer scientists, yet we no longer have a good, local source for discrete components to help us finish these projects. That used to be you, Radio Shack, but you've lost your way.

Last night, I was horribly saddened at what your component selection has become: a dozen drawers or so containing only two or three of the most popular values of components, and only a lone 555 timer hanging out with a few different SCRs and op-amps in the IC bin.

We are the makers. We are many. Hear our plea: Lose some of the chintzy, easily-broken children's toys and pare down (or get rid of) your selection of overpriced and useless home theater junk. Other stores do consumer electronics much better than you can with your small, shack-like storefronts. Bring back the big sliding racks full of components, chips, and kits. Bring back the spring-jumpered crystal radios and projects that kids can build with their parents. Bring back the shelf full of electronics project books and experimenter kits. Bring us Arduinos, SPIN Stamps, stepper motors, servos and robotics platforms.

You were once our hyper-local, affordable source for all kinds of DIY electronics hackery. We liked that. We do not like having to beg all of our friends to go in with us on a huge order from the all-encompassing catalog companies.

Also, a bit of a shout out: here in Kansas City, we do have the HMS Beagle store and Electronics Supply. Unfortunately, they lack the ubiquity and convenience of Radio Shack and they still have to special order a lot of things. Mostly, I'm just being a ranty retro-grouch as usual. I'd really like to see "The Shack" return to its roots. The things they currently do, they're doing poorly, and there's a huge niche left behind by their old business model that I feel would probably thrive quite well. I hoarked over $1.49 each last night -- happily, I might add -- for a pair of LM386 Op-Amps. I'm betting Radio Shack made 700% profit on each of them, at minimum.

Tales from the other side of helldesk

Today, I was having trouble with a web application. I don't often find myself on the other end of a helpdesk call, but lo and behold here I was. I submitted a screen shot of the error, and the response was akin to "I'm sorry, we don't support browsers with toolbar addons."

Excuse me? After going around and around with support, I finally convinced him that the Google search box was not part of some malware suite, but actually comes in every modern browser. IE7, IE8, Safari, Chrome, Opera, and even Firefox.

How much you want to bet the guy is still using IE6?

Reverse SSH Tunnel Watchdog

We've covered tunneling before on HiR. I even wrote a little about reverse tunneling in my quick-and-dirty tunneling howto. This time, I'm building a setup to make an always-on reverse tunnel with a cron-powered watchdog script. I've even coded a cron watchdog before, but this way is less hackish, in my opinion.

Here's what's needed to make it work:

• A Linux/BSD/Unix system on the inside of your target network that's capable of SSH-ing out to the Internet (even if via strange ports)
  
• An SSH server you control on the Internet. This can be at home, or elsewhere

The reverse tunnel can handle pretty much any protocol. To a squid proxy, for example. I'll be using SSH to reverse-tunnel SSH, though, to allow SSH access to a server behind a firewall that I do not control. Here's how it'll work:

Cron will run a script on the server on the inside. This script will check to see if the SSH tunnel is working properly. If it's not (or if it hasn't been started yet), it will start the reverse tunnel.

Here's the script, which I put in /usr/local/bin/rtunnel.sh. Obviously, you need to edit the first 4 variables to reflect your environment.

#!/bin/sh
USERHOST=axon@somewhere.labs.h-i-r.net # Login and External system
RPORT=22 # SSH Listener port on your external system
FPORT=1337 # Port that will be opened locally to tunnel SSH
CONN=localhost:22   # SSH Listener on the system behind the firewall

COMMAND="ssh -q -N -R $FPORT:$CONN $USERHOST -p $RPORT"
pgrep -f -x "$COMMAND" > /dev/null 2>&1 || $COMMAND
ssh $USERHOST -p $RPORT netstat -an | egrep \
"tcp.*:$FPORT.*LISTEN">/dev/null 2>&1
if [ $? -ne 0 ] ; then
pkill -f -x "$COMMAND"
$COMMAND
fi

The above essentially runs this as the command line:

ssh -q -N -R 1337:localhost:22 axon@somewhere.labs.h-i-r.net -p 22

Then uses pgrep (ps command with grep functionality) to see if it's up and running, and tries to ssh to the outside system, using netstat to check the status on that end. If either of those fail, the process is killed with pkill (pgrep, with kill functionality) and restarted.

And then I put the entry in root's crontab, to run every 5 minutes:

*/5     *       *       *       *       /usr/local/bin/rtunnel.sh

In my implementation, the firewalled host (An OpenBSD box) is connecting to a Ubuntu desktop system at my home. I can just log into it, then use the tunnel on port 1337, using the -p [port] option.

axon@somewhere:~$ ssh localhost -p 1337
axon@localhost's password:
Last login: Sat Nov 14 00:01:04 2009 from localhost.labs.h-i-r.net
OpenBSD 4.5 (GENERIC) #1749: Sat Feb 28 14:51:18 MST 2009

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

-bash-3.2$

If the connection times out or fails for any other reason, the remote end should re-spawn the connection in the next 5 minutes. If you've waited, and don't get a response, something else might be amiss. DNS rules, a network admin that's blocked you, etc... You can try switching the port SSH runs on

The one problem I've had is that occasionally the session will be alive, the port will be forwarded, but I can't get it to log in. It just hangs then times out. If this happens, I use lsof on my workstation to find and kill off the process that's listening on the TCP port I am using for forwarding.

axon@somewhere:~$ sudo lsof -n | grep TCP.*:1337
sshd   20386   axon    9u   IPv6    2862057  TCP [::1]:1337 (LISTEN)
sshd   20386   axon   10u   IPv4    2862058  TCP 127.0.0.1:1337 (LISTEN)
axon@somewhere:~$ kill 20386

Of course, you can also tunnel stuff over this reverse tunnel. The possibilities are endless!

Schrödinger's Hacker

Apparently, it started here, then spread like wildfire through the security mailing lists and twitterverse. str0ke, of Milw0rm, was no longer among the living.



I had my doubts. One entry on a blogspot blog doesn't usually constitute breaking news, and there was no more authoritative source. Some people who saw my skepticism told me that it'd be pretty screwed up to fake a death of someone like str0ke. All I can say? Madoff. Lori Drew. Fake Facebook deaths. Bonnie Sweeten. There are some f'd up people in the world, and a lot of them do f'd up things over the Internet.

Str0ke is still alive and well. Or is he?



Related:
Rehi, Milw0rm

Smoking (Cloud) Crack

Making waves in the infosec blogosphere today: Cracking a PGP-protected ZIP file using Amazon's EC2 cloud computing infrastructure. There's some interesting data presented, especially when extrapolating the cost involved with breaking the encryption. There are a number of flaws in the write-up, though. I'll take it to task here, then cover some of the important and extremely valid points that the write-up did make.

This was a brute force password attack

If you happen to intercept PGP communication between two people, there's no password in the world that can decrypt it. The password (or passphrase) only unlocks the secret key, which is actually needed to decrypt the communication. If you don't have the secret key, your options for recovering the encrypted content are mathematically tantamount to nil. If you do have someone's secret key file, that person did something very wrong and stupid. The proper thing for that person to do when there's reason to believe their secret key is compromised: revoke the key, and tell everyone that the key has been compromised! I cover some of this in my GPG Key Management & Signing Article. Some Cloud Crack™ was being smoked by someone, as the crackers had access to the secret key, which shouldn't ever happen.

It doesn't always cost millions of dollars for CPU cycles.

Ages ago, my friend Bob had distributed.net agents running on 90% of the lab computers at the college he attended. These were all fairly new computers, too. Have physical access to 100 computers? You can probably spawn 100 instances of EDPR. For free. As in free beer. Okay, free beer plus the cost of the EDPR entitlements.

Plain old CPU cycles are so '90s. These days, we have the ability to harness compute power of FPGAs, and thanks to things like the CUDA architecture, Graphics Processing Units (GPUs) as well. These technologies take traditional CPU cycle density and cost paradigms and turn them inside out. It doesn't come cheap, but it's surprisingly affordable, more efficient, and denser than building racks of x86 machines. The author spoke of a corporate espionage scenario, with budgets of around $1M to compromise a competitor's data. $1M would go a very long way with FPGA or CUDA technology.

Finally, there's the black-hat side. Botnet zombies are cheap. Spammers, scammers, and malware tycoons know this. If you have some skills, free time and lack a moral compass, you can roll your own botnet or hijack someone else's botnet zombies for free. Again, as in free beer. Don't think it happens? Don't kid yourself.

Brute Forcing is real

While brute force doesn't work against PGP in a perfect world, it does work almost anywhere a password is involved, and the numbers don't lie. An attack like this against an encrypted TrueCrypt volume, for example, would be bone-chilling if it succeeded. Normal "protected" zip files, documents, and accounts are vulnerable, and there are multiple tools to brute force almost any kind of password.

Longer is better, for the most part

Long, simple passphrases win out over short, complex passwords when it comes to brute force. Still, if you use something that's easy to guess, like the first sentence of the book currently marked as your favorite on some social networking site, you might be in trouble. The ways you choose, guard, and use your passwords are parts of a very complex problem that not even the best in the industry can agree on a solution for. Good luck with that.

If all else fails, there's always rubber-hose cryptanalysis. Remember, you can't hide secrets from the future with math.

The Pavlovian yes box

In the technology field we like to "train" people how to do things. But many people do not understand the difference between training and education. To educate someone means that they have an understanding of how to perform a task and to understand why it works. To train someone on a subject only gives them part of that equation. A person who has been trained on a subject only knows a process to accomplish a task but does not know how or why that process works.

For years, Internet technology has trained people to use the Internet in a certain way. We train people to break up the search queries into key words instead of whole sentences. We train people to "Google" it rather than to fully research a topic using traditional library media or trusted resources. And finally we train people to click on "YES" when any question is presented to them when they click on a link.

So when Microsoft released Internet Explorer 8, help-desk's around the world were deluged with angry calls about websites which suddenly stopped working. The problem was that Microsoft, rather than passively continuing its part in training users to press "YES" to continue, now requires a "NO" to continue.

My hope is that people actually are forced to read what they are agreeing to. And when they do finally read it, they start asking very important questions like what they are agreeing to exactly. The most common issue is with websites is when they mix secured and unsecured content. To most people so long as only their private information is being sent on the encrypted channel, they are satisfied. However the problem really lies with authentication, most authentication uses a session ID variable which is given to the user with every transaction. Unless special measures are taken this session ID can leak out of the secured session and become available to someone who is eavesdropping. That person can then usurp the connection and pretend to be the user.

This is not all the users' fault of course; the developers take the blame too. It isn't until recently that people have started to do exactly what they are supposed to do and complain and make sure that all of their secured website links are SSL aware. Popular web applications like Wordpress are pretty dumb when it comes to this issue; there are of course plug-ins which patch this issue, as well as some all or nothing solutions which force everything to be SSL but nothing very elegant. The real issue with web apps is when dealing with plug-ins and 3rd party software which are not forced to follow any convention when creating content or linking.

Other web security related articles at H-i-R:

• Securing PHP Web Applications
• Introduction to SNORT IDS
  

Windows 7: Is its success really a surprise?

I've been messing with Windows 7 since the beta, and my wife has the Ultimate edition installed on her laptop (having replaced Vista, for the most part).

Most people agree: Windows 7 is good. But really, when faced with the following choices, how could Windows 7 NOT succeed?

• Windows XP, a decade-old platform that's been patched to hell
• Vista, a chubby three-year-old toddler replete with nagging, resource-hogging character flaws
• Windows 7, the shiny hotness built after pay-to-participate beta testers shook out Vista's worst features and bugs over the course of 3 years

(this post is loosely based on an IM conversation with another friend of mine in the financial IT sector)