The first time my email account was hacked, it was the late 70s and I was in grad school at Stanford. Back then, we used a DEC time-sharing system, and I would login to my account at a public terminal in the atrium of a building on campus. One evening it appeared that I had sent myself email. Someone had figured out my password, which wasn't difficult since it was the same as my username. Fortunately, the culprit turned out to be a fellow grad student turned prankster. But I still had that sinking feeling you get when your system has been hacked.
My first reaction was to blame someone else for the hack. But it was my own stupidity, just the same as it was long ago at grad school. Two stupid things, really.
First, you probably know how easy it is to send a message from someone else's email address. Just open the email client's preferences or configuration menu. Change the identity of the outbound mail server. Save the configuration. And, presto, you can now send email using this new domain name. When email protocols were first invented, this was a feature, not a bug. Back in those early days, simplicity ruled and no one knew about malicious or opportunistic spammers who would exploit this feature and send millions of emails daily, hijacking servers without a care in the world.
But we live and work in different times from those innocent days back when Al Gore was inventing the Internet. Many domain administrators and ISPs have tried their best to prevent these email hijackings, and now require their users to access their email from a particular IP address or from inside their own networks. It is a good idea, provided you use it. Unfortunately, these restrictions weren't on my domain at the time of the attack last month. (Sigh: they are now.) So at the time of the attack, anyone could have sent mail pretending to be me.
My second mistake is a more difficult one to explain, and has to do with the way in which I set up my Web Informant mailing list on the eGroups service. eGroups administrators have lots of options in how they set up their lists. The option I chose was that only I could send email to the entire list. Furthermore, I could send my messages without requiring any confirmation before the message was sent out to everyone. This was done to make things easier for me to send out my mailings.
Put the two mistakes together, and you could see how I was hacked. Someone (I still don't know who) hijacked my email account and posted their message to the eGroups server. Since the eGroups server thought they were me, the message went out to the world.
Since the hack I have required the extra step of confirming the message before it is sent to the entire list. Hopefully this means that any Web Informants you get in the future will actually only come from me. And once again, I apologize for these mistakes.
So what did I learn from all this? What's the moral of the story? Just this: If you're running a small business, it's very tempting to sacrifice security for convenience. It's also easy to delude yourself into thinking, hey, it can't happen to me, hackers go after big sites, big business, big brother. But that's not the case, as I know all too well now.
With this in mind, I asked friends and security consultants Fred Avolio (firstname.lastname@example.org) and Kevin Shivers to have a go at my network to see what other security breaches might exist. Fred has been involved in firewalls almost since the term was first used, and is now an independent consultant who lectures about network security around the world and consults to both government and industry, as well as co-authoring one of the seminal books on sendmail. Here's what they found, in their own words.
I am not a hacker -- but with that clearly understood Kevin and I took a swing at David's network one morning. To do this, we ran a simple network scanner against the firewall. There are many free and commercial scanners available, but I chose a commercial one, Network Associate's CyberCop Scanner because of familiarity with the tool. You identify the target, configure a few parameters (IP address, domain name, and the like), and off it goes. Scanners like this test for known vulnerabilities and report on all services that the target network offers, in this case David's firewall.
The scanner found seven problems. Most were low risk, meaning that they provided hackers with information they could use to break in, but on their own these problems did not pose a threat. So what kind of data did they offer? The Telnet, FTP, and HTTP servers running on the firewall all announced their brand and model number in the welcome message that displays when you connect to the server. Seems harmless. But if you know anything about these particular servers, then it's not hard to guess which operating system they are running under. Worse, because the version is revealed, hackers could then research the known vulnerabilities, looking up, say, the security gap a patch was designed to fix.
We also discovered SNMP, Telnet, and HTTP services. Once again, these servers displayed overly informative banners. For example, we couldn't manage the SNMP service, but did reveal information about the network interfaces and other hardware-related information. Telnet also had an overly informative banner, as did the HTTP service, which revealed the software vendor and version. Also, a scan revealed that David was using IP addresses on his office network starting with 10.0.0.0 -- not uncommon, but a potential bit of intelligence for determined hackers.
Now, this type of setup is typical of any small office or a home office. They require few services because there are few users behind the firewall. On the plus side are three things: David did not set up an anonymous ftp account, there was no "obvious" guest accounts for Telnet, and the server was well protected. The downside is all the banners announcing the software brand and version. That's easy to fix if David knows enough about Unix (unfortunately, he doesn't! -- ed.). In addition, SNMP should be available only from the inside (trusted) network (which is not possible, since sometimes your ISP is managing the router).
A bit more digging found three other problems. First, any Telnet service over the public Internet is vulnerable to eavesdropping and session splicing (that's when someone takes over an existing TCP connection). David or his ISP might use Telnet to manage his firewall or router. Say one day his ISP tries to use Telnet to manage his router from the show floor of a conference some day -- well, you get the point.
Finally, while Internal web access is a requirement for David's site, and most private pages were password protected, the server did reveal its name, rank, and serial number, which could make it an easy target. Also, David had a directory called "backups," which contained an address book backup. The address book itself was protected, but the most recent back up was available for copying and reading. And this is one of the key dangers of a private site that touches the public Internet. It is difficult to know if you have covered all the bases.
Thanks Fred and Kevin. All sobering points. That backup directory is now moved away, and I have learned a few lessons. In the meantime, I hope all of you will take some time and do a security scan on your own networks, and protect yourselves before something or someone reaches out and does some damage.
And also this month is a long feature article on recent developments in eCommerce for New Media magazine, called Setting Up Shop on the Web.
+1 (516) 944-3407
entire contents copyright 1999 by David Strom, Inc.
Web Informant is ® registered trademark with the U.S. Patent and Trademark Office.
ISSN #1524-6353 registered with U.S. Library of Congress.