The Perfect Phone

There's been a lot of hype lately about the iPhone. It looks snazzy. It has Wifi, EDGE, Bluetooth, and all the other bells and whistles a high-end phone is expected to have these days. But it's not the phone for me. Before the iPhone were several Nokia offerings that are almost up to my standards. The Treo and the Blackberry look like the same story: almost what I want but not quite.

What I want in a phone are these features:

• Wifi -- preferably with a chipset that allows me to run kismet. Better yet would be one that allows me to run Lorcon and/or livetap.
  
• Large amounts of flash storage. I'd prefer this to be internal but I don't care what the medium is. I'll buy extra storage media without complaining too much. With as cheap as USB flash devices are getting these days, it should be a gigabyte at minimum.
  
• charge over usb
  
• a camera would be cool but not strictly necessary. I used to think that I would prefer a phone with no camera because some places won't allow cameras. I've recently come to realize that most places that don't allow cameras also don't allow phones.
  
• Bluetooth for the sole purpose of connecting to a laptop and using the phone as a bridge.
  
• a browser that handles javascript and flash decently. I know this isn't as big a problem as it used to be, but the five-lines-of-text-at-a-time that my old Samsung presented as "Internet" just doesn't cut it.
  
• a big enough screen to display many lines of text.
  
• Unix-like operating system. This is necessary to be able to have a useful shell.
  
• a good way to input text. This is necessary to be able to interact with that shell.
  
• Bash or the equivalent. I can do everything on the commandline faster and more efficiently.
  
• an ssh client. What's the point of being connected 24/7 if i can't be connected to the machines that do my bidding? This also gets me to irc and other various programs that have become tethered to my brain over the last several years.
  
• nmap -- this also means I need raw packets.
  
• a ruby interpreter.
  
• other third party applications (some of which will undoubtedly be written by me).
  

And I want it all without having to go through the pain and discomfort of JailBreak and other forms of warranty-voiding DMCA-violating kludges.

Basically, I want my Thinkpad in a 4.5 x 2.5 x 0.5 inch, 5 ounce package that can make calls.

The FIC Neo1973 looks very promising on the software front. The entire phone is open; it's based on Linux and everything from the circuit boards to the kernel to the frontend is user modifiable. That has strong appeal. Unfortunately, it has no Wifi which makes it nearly useless to me. The second generation, which does have wifi, is advertised as being available early 2008 but since it was advertised as being available on October 1 earlier this year, I'm not holding my breath.

The iPhone has nice hardware and a nice interface. But for it to be useful requires breaking laws. I boycott products that have that property in the hopes that manufacturers will start making things open enough to be useful for more than their own highly-defined and highly-limited idea of useful.

The Nokia N800 looks like everything I want -- Linux-based; wifi; third party development is encouraged; hell, Immunity built a pentesting tool out of them -- but it's not a phone. Maybe I'll just get one of these and keep my crappy free-with-service-agreement 6103. I would be much more interested in the Nokia E90 if it ran Linux. I just can't justify a thousand dollars for a phone without being sure beforehand that I'll like it.

Ephemeral: adj. lasting for only a short period.

Mosref (MOsquito Remote Execution Framework) is what Metasploit's Meterpreter really wants to be. It is (on paper) a platform-agnostic virtual machine and Lisp interpreter with strong encryption on top of multiple communication channels. In reality, I could never get it to compile; nor could many other people based on the conversation in the mosref mailing list. And even if I could have, I would have had to learn the Mosquito dialect of Lisp for it to be any kind of useful.

After Wes Brown's and Scott Dunlop's talk about it at Defcon 14, I really wanted to see Mosquito succeed. Unfortunately, it never had any updates after that talk (the last developer cvs transaction according to source forge was the initial commit). The mailing list contained almost no discussion of development. This afternoon I visited ephemeralsecurity.com only to discover that the domain is now parked by an advertiser and whois lists the owner as "Domain Discreet". I was disappointed to learn this but not surprised.

Oh, well. If you want a platform-independent in-memory rootkit, you'll just have to write it yourself.

Turnabout

My home firewall runs an ssh server. Every few days, I go through my logs and find that someone has been attempting to guess account names and passwords on that server. For a while, I just allowed it to continue because I found it interesting to see what usernames were being guessed. After a few months of getting guess attempts every couple of seconds with almost no interruptions from dozens of ip addresses, I decided I didn't want to take the risk of somebody actually getting in and set up iptables rules to blackhole any ip address that sent more than ten SYN packets to ssh in less than two minutes. A friend pointed me to denyhosts, a tool to watch your logs for failed ssh attempts and put the offending host into your /etc/hosts.deny for a certain period of time. This is effectively the same as the iptables rules. Both of these methods are very effective but not as interesting as seeing all the usernames tried. So I downloaded the source for openssh-4.4p1 and made a few modifications. My new sshd:

• Logs all connections
• Logs usernames and passwords
• Never opens a shell no matter what

If you'd like to set this up yourself, you can download the complete source, or if you already have the source for openssh-4.4p1, and don't want to download the whole thing just for a few modifications you can get just the diff. Then run the following commands:

tar xzvf openssh-logger.tar.gz
cd openssh-logger
./configure --prefix /usr/honey/ \
  --with-privsep-path=/usr/honey/chroot \
  --with-pid-dir=/usr/honey/var/run
make

The purpose of putting it in a strange directory is that we don't want to hose your real ssh server. If that went well, run:

su
make install
touch /usr/honey/chroot/sshattacks.log
chown sshd:sshd /usr/honey/chroot/sshattacks.log

Remember: if you run a real ssh server, you'll want to change the port it listens on in your /etc/ssh/sshd_config. You can add section to your ~/.ssh/config like this:

Host <hostname>
  Port <real server's port>

so your client will connect to the correct server. Now everything should be set up and you should start seeing brute force attacks in /usr/honey/chroot/sshattacks.log in no more than a couple of days.

Output will look something like this:

host: 10.0.0.100 port: 45677
user: root pass: root
user: root pass: t00r
user: root pass: r00t

Happy hunting!

Nastier tricks with ssh

In my daily blog reading a week or so ago, I stumbled on Jon Hart's blog. In it, he notes the facts that root can read any file whatsoever on a *nix system and that ssh agent forwarding is accomplished using unix sockets. The corollary to this is that root (or someone with access to your account) can steal your password-protected ssh keys after you decrypt them.

Having used key-based authentication on a regular basis myself, this got me to thinking about other possibilities for an unrestricted user. As it turns out, if a user can read someone else's private key file, one can authenticate with it. Long story short, I've modified Jon's code to also search out non-password-protected keyfiles and attempt to abuse them.

On ssh and timeouts

It turns out that ssh by default doesn't like to stay connected forever. If you setup a port forward as described below and don't connect to it right away one end or the other will timeout (not sure which, but it doesn't really matter). To circumvent this issue, I've taken to setting up the forward, connecting to the remote box, then connecting through the port forward in a screen session, and detaching screen (or not, depending on my mood). Now ssh won't be able to tell that there's no interaction and will stay connected indefinitely.

Incidentally, if you love the power of the command line and haven't heard of screen, you should install it at the earliest opportunity. Thank me later.