But who’s going to set up their own email server?


Many many years ago, back in the days when Microsoft's email address had exclamation points, an internal tool was developed to permit Microsoft employees to view and update their Benefits information from the comfort of their very own offices. Welcome to the paperless office!

One of my friends noticed an odd sentence in the instructions for using the tool: "Before running the program, make sure you are logged onto your email server."

"That's strange," my friend thought. "Why does it matter that you're logged onto your email server? This tool doesn't use email."

Since my friend happened at the time to be a tester for Microsoft's email product, he tried a little experiment. He created a brand new email server on one of his test machines and created an account on it called billg. He then signed onto that email server and then ran the tool.

Welcome, Bill Gates. Here are your current Benefits selections...

"Uh-oh," my friend thought. "This is a pretty bad security hole." The tool apparently performed authentication by asking your email server, "Hey, who are you logged in as?" The answer that came back was assumed to be an accurate representation of the user who is running the tool. The back-end server itself was not secured at all; it relied on the client application to do the security checks.

My friend sent email to the vice president of Human Resources informing him of this problem. "You need to shut down this tool immediately. I have found a security hole that allows anybody to see anybody else's Benefits information."

The response from the vice president of Human Resources was calm and reassuring. "My developers tell me that the tool is secure. Just enjoy the convenience of updating your Benefits information electronically."

Frustrated by this, my friend decided to create another account on his test email server, namely one corresponding to the vice president of Human Resources. He then sent the vice president another email message.

"Please reconsider your previous decision. Your base salary is $xxx and your wife's name is Yyyy. Would you like me to remind you one week before your son's tenth birthday? It's coming up next month."

A reply was quickly received. "We're looking into this."

Shortly thereafter, the tool was taken offline "for maintenance."

Bonus reading: JenK shares her experience with the same incident.

Comments (42)
  1. TM says:

    Somehow that's just what I expect from Microsoft. ;)

  2. Joshua Ganes says:

    Sometimes the only way to get someone to fix a problem is to take the time to demonstrate exactly how the problem can affect them personally. Unfortunately, in this case, it requires taking a few ethically questionable steps.

  3. Dan Bugglin says:

    Wow, risky.  You need to be careful around those people, if you are even tangentally involved in an event that cracks their perception of their perfect bug-free systems, they'll accuse you of "hacking" in a heartbeat, and so it could have easily gone badly for our hero…

    Why yes, I did have something like that happen to me.  I got in trouble in high school when I launched IE with the homepage configured by someone else to use a network resource I wasn't supposed to have access to.  But of course the security permissions weren't set up, and somehow this was all my fault.

  4. J. Peterson says:

    Sad how things like that don't get fixed until those in charge are victims.  Like the invasive TSA scanners.  On a recent trip to Washington DC, I noticed Dulles airport (which presumably is used by most federal legislators) is one of the few that does not yet have full body scanners.

  5. jcs says:

    J. Peterson: No, DCA is the airport most likely to be used by legislators, and that airport routinely gets the latest security scanning technology before the other airports do.

  6. James Schend says:

    @jcs: Not that it really matters because federal legislators mostly fly private, and the ones who don't can bypass the security line. Sorry for being off-topic.

  7. On a related note, the university I work for got an (outsourced) setup for staff and students to buy or reserve tickets for internal events, with electronic payment if the event had a price. When I ordered the new 'staff discount card' for local retailers, alarm bells sounded when I saw the message "Thank you for your purchase. For security reasons, you have now been logged out. You can view your receipt for this purchase by clicking here: example.com/receipt. Wait … if I'm logged out, how can that URL still work without logging in again? Sure enough, there was no authentication – and example.com/receipt gave me their previous customer's payment details. Being helpful, I explained this to the relevant department, who later assured me that their supplier now understood the value of security and would be fixing this ASAP. (A much better reception than I had expected – and better still, the problem actually got fixed soon afterwards!)

  8. James says:

    The JenK version reminds me of how I got manager access to the university mainframe. A batch job with JCL embedded in the executable in plain text. Send a job that asked for a tape to be mounted and which printed "Archive restore job, please run" on the operator's terminal and it would be escalated to system manager privileges.

    One day the person responsible for the security of the system asked me to run a job with slightly elevated priority, perhaps because the operators might be too friendly and let it run, so it could get them gently criticised. The next day I showed him the output of an approved run, but with syntax errors, that asked for the manager's password. It was the only time I saw him run…

    The loophole remained for as long as I was there. The mainframe was retired a year or so after that.

    If it's in your executable someone, somewhere, is going to read it and use it, if they can.

  9. Alex says:

    Big media company, let's just say, if you buy music, you know them. Of course, we developers only had user level access to the machines (production, integration and test). However, we could of course order new jobs to be scheduled for importing or exporting or reporting jobs etc. These jobs would have a wrapper shell script named after the jobs internal name and would then start the actual program we developed. However, that shell script was also under our control and was run as root. The first thing all of them did was to "su" to our reporting/importing/exporting system user and run the actual program. Somehow nobody ever thought about making a job script that put a suid root shell somewhere where anybody could execute it until I came along and pointed it out.

  10. Matt says:

    Similar issue occurred with the timesheet system at work.  The URL request was based on an employee number that was received from the login server, but could be changed after login and was never re-authenticated.  I notified the head of IT a couple times and was basically told that it wasn't an issue.  Then I showed our human resources rep and she reported it to a different person who followed up with me, but they did not understand what I was talking about.  My next step was to write an email with step by step instructions on how to retrieve and modify timesheet information for over 300 employees and had the potential to affect other regions if their timesheet systems were configured the same way.  The email included links to the timesheets for myself, the head of IT, the regional manager of all 300 employees and the human resources rep.  The head of IT tried to get me fired for it, but luckily the regional manager was significantly impressed and my immediate supervisor new that my intent was not malicious.  I was told to leave it alone and that they now knew of the problem.  Over a year later now and the same problem that was so severe that the head of IT felt I should be fired for demonstrating it, has still not been fixed.

  11. SimonRev says:

    One company that I worked for as an intern had a time clock system that clocked you in and out based on the local time on the PC you were using (they were also using Win98 on their client machines).

    I finally convinced the accounting department that there was a hole, and they contacted the software vendor.  The vendor delivered a patch to fix the problem.  The fix?  When the time clock app would start it would sync the client time with the server time.  Of course if you changed your clock after you started the time clock app…  They never fixed that one, AFIK.

  12. Mike Dunn says:

    A while back, everyone at my company got an email that said basically, "Open a browser to the litware-foo server, read the information there, and acknowledge that you read it by typing in your AD credentials and clicking Accept."  No one had heard of litware-foo before, and the email had no social grace or even a signature, so folks were immediately suspicious.

    At the time, my office was near one of the high-ranking devs, and within a few minutes, there were several senior people in his office trying to figure out what was up.  They were doing things like telnetting to the machine to try and figure out what software was on it, and whether it was supposed to be running on the internal network.  It was quite interesting listening to them descend on the problem and propose things they could try to learn more about that machine.

    It turned out to be legit, so the next day, we got another, better-worded email explaining what litware-foo was all about.

  13. Krunch says:

    The link to the JenK comment doesn't work (well, it goes to the right page but not to the comment).

    [Known problem with server software. -raymond]
  14. Erzengel says:

    Reminds me of a story on TheDailyWtf:

    thedailywtf.com/…/Oklahoma-Leaks-Tens-of-Thousands-of-Social-Security-Numbers,-Other-Sensitive-Data.aspx

    It was reported to the Oklahoma government devs that their site could be "hacked" to show social security numbers of anyone held by the Department of Corrections (because they passed the sql query as a GET parameter). The devs then "fixed" it by changing the case sensitivity of the ssn variable. So the person doing the reporting then showed how to use the hack to get the personal info of the employees of the DoC. This is what made the devs actually fix the problem.

  15. Dan says:

    I worked for a telemarketing agency during high school and I had a friend with me who was far more brilliant than I was. During the course of our summer employment, he broke their security multiple times without malicious intent. He tried to be helpful and point out the security flaws and the first 2 or 3 times they tried to fix it.

    The final time, before they had us canned, was the simple discovery that the security software and permissions was all network based and that by unplugging the network cable on boot up completely negated the security. Plugging it back in afterward gave us access to everything. Payroll, pay rates, tax information, calling lists, schedules, and the pirated movies the IT department kept on their servers.

  16. Adam Rosenfield says:

    > [Known problem with server software. -raymond]

    It's been a known problem now for 6 months.  What does it take to get the blogs server folks to fix this rather considerable bug?

    [The blog server folks don't develop the software that runs the site; they just administer it. The software vendor resolved it 'by design'. The blog server folks then filed a design change request. That's where it's at. -Raymond]
  17. Christian says:

    That's true. I've seen this zillions of times in real life.

  18. Allan says:

    Ask Randal Schwartz about this methodology of spurring management into action.  It almost ruined him.

  19. Leo Davidson says:

    @Adam Rosenfield: We just need to find a way that the broken comment-links problem can be used to get the payroll details of the people who write the blogging platform. Then they'll finally fix it.

    (Not to mention having to post everything twice. Argh.)

  20. AnyUnixUser says:

    Haha, this blog just described Unix security.  If you are root on a unix box that is part of a NIS or LDAP domain, you can su as any user in NIS or LDAP without entering a password.  From there, you are that user and can do anything you want as that user.  Why?  Because all Unix security checking is done from the client side, not the server side.

  21. Alex Grigoriev says:

    [The blog server folks don't develop the software that runs the site; they just administer it. The software vendor resolved it 'by design'. The blog server folks then filed a design change request. That's where it's at. -Raymond]

    That reminds me of interactions with certain large software vendor.

  22. Dave F says:

    We once had an IT manager push down a consultant down our throats despite unanimous resistance. This was supposed to be a security consultant who was going to review all our web and outside services. So in the interview, which was labeled as formality, we asked him a simple question: why is it that he uses the ame admin password XXXXXX for all his clients? Since they are all in ASP, do he also use the same password for other web services as well? Needless to say, he was speechless and the room fell silent. Never saw that consultant ever again in our offices. The IT manager was fired shortly thereafter. All we did was looked up ASP source pages (these were the days when it was easy to look at the ASP source).

  23. Scott says:

    I demonstrated a SQL injection problem by issuing a 'detach database' command. Thankfully, I only targetted the staging database for our website, instead of the ERP system.

    Sadly, the "fix" was string substitution, not actual parameterization. Better than nothing, I guess.

  24. Will J says:

    @James Schend – I'm not sure that's true.  I've been in Reagan National plenty of times with legislators.  I'd bet most fly commercial most of the time.

  25. @AnyUnixUser says:

    Yep, you're right, unix security doesn't work. There is not a single example of a large, secure *nix network anywhere.

    (for the largely US audience… en.wikipedia.org/…/Irony)

  26. Andy Pennell says:

    The internal Training site on MS Corpnet used to use URLs with the Employee ID in it (the URL being generated from some other page that looked the user up in AD). As the ID was easily available from Headtrax, it was trivial to make up a URL then look up anyone's training record (or to sign them up for more training). In retrospect I should have signed up the team that wrote that too for more Security training.

  27. Wyatt says:

    I'm surprised the guy finding the hole didn't get fired.

  28. Joshua says:

    *Ouch*

    Reminds me of $ telnet -l-froot (doesn't work anymore).

  29. @Marts_McFly says:

    Awesome stories :)

    A few of these tales remind me when i was a teen. I figured out that when a teacher logs into the NT domain, a networked drive would be mapped for them… called 'Reports'. Once entering this mystical 'Reports' drive, you find yourself with a FileMaker database. Upon opening this database, you find that it has no authentication, and you have write access to every students report from every year.

    So was quite convenient to log into that a week before the reports got printed and sent to your house. Mum would always be so pleased with my grades :)

    (You have to love the good old days of PWL files sitting in the root of C:, waiting to be taken home on a floppy and cracked with Cain)

  30. Rob "Shamed Developer of Microsoft Choice" says:

    I'm the guy who wrote that program – actually an employee of an outside contractor – it was dubbed "Microsoft Choice" and it was written in VB and if I remember correctly the back end was SQL Server on OS/2! (dating myself circa 1993).

    It was a very seductive idea at the time, because it avoided issuing passwords to individual users manually.  I was a doe-eyed 22yr old kid from Chicago – living out of a Residence Inn in Bellevue.  That said – two ITG (Internal Technical Group?) employees approved of the scheme (MAPI call to the Microsoft Mail server) and thought the idea was "brilliant".  

    We were a little naive — and never suspected – that people would setup their own mail servers to spoof the authentication.  I'm a much more grizzled and cynical coder and have long since learned to never underestimate the "hacking power" of bored software engineers.

    Not a "proud moment" and if I remember correctly it did elicit a scornful comment from Bill along the lines of "it's hard to believe there isn't someone in ITG who knows a little something about security".  I think we just issued random passwords and the software went back online in a few days.

    I can drop a few names & other details if anyone wants to verify my account. –> roboneal at yahoo dot com

    [Given that at the time, many people were using telnet-based mail, we had no choice but to set up a fake mail server in order to access our Benefits data. -Raymond]
  31. Gabe says:

    AnyUnixUser: That reminds me of a time back in the mid-90s when a friend of mine was an intern at a large Unix hardware/software vendor (that recently ceased to exist). Like all good Unix networks, their email was hosted on a server that shared mailboxes via NFS. Being NFS, it relied on the client to authenticate. Of course my friend had root on his workstation (as I'm sure all engineers at the company did), so he could set his UID to be whatever he wanted it to be without authentication.

    Needless to say, he had access to everybody's email at the company, though I doubt he ever looked at anybody else's. We both thought it was funny that the company's email security basically worked on the honor system.

  32. HomeGroup says:

    Now only if the huge security and privacy risk that is HomeGroup would get fixed. I am talking about this design flaw: http://www.sevenforums.com/…/29821-everyone-c-users-security-tab-right.html

    [Everybody seems to have forgotten that the effective access is the intersection of share access and file access. Since file access defaults to "only you and administrators" there is no exposure of user data unless the user chooses to share it. -Raymond]
  33. Paul says:

    @Rob: Is this the point where everyone starts to spout "TRWTF is VB"?

    (I don't support that argument, but someone'll say it)

  34. Rob "Shamed Developer of Microsoft Choice" says:

    Just remember, it's 1993 and I'm developing that app for +Microsoft+ — what alternatives for rapid GUI development did we have to VB? :)

  35. Ludovic says:

    I worked for a company where you could see every invoice, every reason, every purchase made by anyone for all time.  I notified the CFO, who never responded, then the CIO, then the system went down.  When it came back up, one of the links was gone, but a second single-click still showed everything.  They still have not fixed it.  Apparently, it just does not matter that people know the company paid 'emergency expenses' for an executive in the amount of $50,000.

  36. Gechurch says:

    @HomeGroup

    Don't be so sensationalist.

    Firstly, the post you linked to (and the one linked from that) are just that – newsgroup posts. Two random people on newsgroups don't make for a confirmed problem. A problem with their setup, like a virus, could have caused the issue. Second, it was clearly a bug, not a design flaw. Third, the posts are over a year old and seem to be talking about a release candidate. The bug (if it was ever confirmed to be one) is likely to have been long since fixed.

    Let's avoid taking random newsgroup problems, misinterpreting them and claiming them to be massive, gaping problems that clearly show how stupid and insecure Microsoft is. If you can't resist doing so, try Slashdot instead. They love that sort of thing.

  37. Windows guy says:

    @AnyUnixUser, that hasn't been true in over a decade. Modern Unix systems use Kerberos and LDAP for end-to-end authenticated and secured. You may have learn of them: Active Directory is implemented using them. NFSv4 uses these permissions to do real checks.

    Complaining about NFSv3 permissions is like complaining that Windows 95 doesn't support access control.

  38. asdfasdasdfasdf says:

    I've reported a vulnerability that allows anyone to gain Administrator access to any system that has a certain MSIT internal tool installed, and this tool is installed by default — but the attitude is the same. Nobody can be bothered to fix the obvious hole.

  39. Cheong says:

    @Rob: That's actually quite understandable. Afterall, information about network related security was not as common in 1993 as it is nowadays, and security review on non-security related product was not common back then. For the most time, if your application required to login with username and password, your application is considered to be secure.

  40. fastoy says:

    When I worked at Federal Express in the 1980s, we had an IVR system that would reset your password. It required your employee number and one piece of personal information, e.g. your birthday, home zip code, last performance review, etc. It was a very small set of questions and there was no logic to detect repeated attempts. Since the human resources system was hierarchical, the higher up you could breach the more access you had.

    I thought that this system was seriously flawed and explained my concerns to the security manager. He dismissed my concerns and so I offered to demonstrate my theory. He agreed to this and watched.

    The CEO Fred Smith was the founder hence his employee number was 1. I called Federal Express' public relations and asked them for his birthdate. Surprisingly they declined to reveal it. The local public library was not so careful.

    I called the IVR and responded "1" to the question of employee number. The next question was for home zip code. I hung up and dialed back repeatedly until it asked me for Fred's birthday. I entered his birthday and it responded with a new password.

    Needless to say the security manager left in a big hurry. Soon the system was disabled for all officers and they were given a direct hot line to reset their passwords.

  41. AppDev #7 says:

    I have been part of internal HR Benefits systems for many years and I don't recall this ever happening.  The first ESS tool was tied to your windows log in and now it uses ADFS.  I think your facts are not correct.  Of course I might not know everything… :)

  42. AppDev Number 7 says:

    I have been part of internal HR Benefits systems for many years and I don't recall this ever happening.  The first ESS tool was tied to your windows log in and now it uses ADFS.  I think your facts are not correct.  Of course I might not know everything… :)

Comments are closed.