Day 5: Over 20,000 Social Security Numbers

Day 5: Over 20,000 Social Security Numbers

Between the cracked passwords and the intercepted passwords from the my.ptech.edu web application, Flir had over 22,000 passwords. Now he d need to log into the my.ptech.edu application and harvest the social security numbers, full names and addresses.

Later on, Flir might write a web script to automate logging in to the web application, surfing to the class schedule page, and gathering the social security number. Before he could automate that process, he d need to connect manually a few times and record logs of his sessions. He set his sessions to go through an old free version of @Stake s WebProxy so as to record them easily. This was necessary both to learn how to parse the social security number out of the page, but also to make sure that his script looked and behaved like a common web browser interacting with the application.

Before he started logging in to the web app, Flir remembered that he d better remove the trojaned ssh binary from wstearns account on the mac3 shell server. He logged back into the mac3 shell server with another one of his compromised accounts, daveg and executed the wstearns shell.

 [mac3:~] daveg % ~mrash/Public/Drop\ Box/.shells/zsh-wstearns mac% rm ~wstearns/bin/ssh 

Flir surfed to the my.ptech.edu web app and nervously typed his first pair of stolen credentials, logging in as asheridan. He switched to the class schedule page, recorded full name , address and social security number he found there, and logged back out.

He logged in to the web application over 30 more times, moving somewhat randomly through his list of accounts, removing each name and password from his temporary list as he acquired their personal student data. He had just finished logging into the application as daveg without thinking about the fact that he was also logged into the shell server with the same account. As soon has he finished logging into the application, he realized that he had forgotten to exit the wstearns shell and log out of his daveg login.

He exited the wstearns shell:

 mac% exit You have new mail in /var/mail/daveg [mac3:~] daveg % 

Re-reading You have new mail in /var/mail/daveg, Flir thought, the timing is probably just coincidence .

Just to be sure, he checked DaveG s mail. He didn t want to use a normal mail client, in case that sent message-received receipts or did something else that gave greater indications of his presence. Instead, he used the UNIX tail command to see the last 100 lines of DaveG s mail account. The last message read:

 From: "Automated Admin" <[e-mail]> Message-Id: <[e-mail]> To: [e-mail] Subject: Welcome back! Your login to the MyPtech Student Information Retrieval Access and Modification system was your first in 96 days. This message is sent automatically to any student who hasn't connected in more than 60 days. We hope you find the MyPtech system helpful and easy to use. We are constantly updating the application for your convenience and usefulness. If you need any help with the application's menus or need to report a bug, please feel free to contact the help desk at 555-202-0101, or campus extension 2-0101. Thank you. 

Flir didn t like this message one bit. Help Desk was sure to notice if a few thousand extra students called asking about application logins that they didn t make!

He immediately logged out of his daveg account in both the web application and the shell server, electing to log back in to the shell server with one of his other accounts.

Flir started to think this new development over. At worst, he could just automate his login script to login as all 22,000 users anyway, quickly and before the staff could figure things out. But when he began this process, he had planned specifically to avoid being noticed. He didn t want to find himself racing the administrators to get the data before they shut down the application.

Flir decided to let this problem percolate in his subconscious while he worked on something else. Most of Flir s best problem solutions came to him either while he was working on something else or while he wasn t even consciously engaging his problem-solving skills on anything. He would let the problem of avoiding detection percolate while he built the script that would automatically login to my.ptech.edu and collect student information.

Flir started to look over the web proxy s logs, seeing the authentication step, seeing the cookies that the authenticated web client had to pass with each request to maintain its session and authentication, seeing his requests for the class schedule page. He copied each pattern that he d need to match into an emacs window to begin building the perl script that would automate this. Then it hit him.

He heard a child singing in his head, one of these things is not like the others, one of these things does not belong! He looked at the log and saw this line at the top of one of the pages:

 <!-- /* $Id: get_StudentData.html,v 1.8 2004/02/07 21:20:13 bstrobell Exp $ */ --> 

It was an HTML comment, but it was special. This comment contained a CVS version string, identifying a version number for the file, a date and, most importantly, the account name of the developer who last checked this file into a repository, bstrobell. Flir looked for other version lines in his interactions with the web application, but found none. This seemed to be an artifact that would normally be cleaned out of the page before it was pushed to the running application. Flir wondered if perhaps he had access to the bstrobell account, either through a cracked password or a Set-UID shell.

He checked his cracked password list, but did not have bstrobell s account. Ben Strobell, the name identified in Flir s stored nidump passwd table, had unfortunately chosen a very strong password. Flir could put the cluster to work brute-forcing the password, but things would be much easier if he had a Set-UID shell for bstrobell s account. It d be a lot stealthier too, since using the Set-UID shells didn t actually create log entries.

Flir checked his list of Set-UID shells. Ben s was among them! Flir quickly ran his bstrobell shell and assumed Ben s identity. He looked in Ben s account and found a number of directories. He methodically walked through each one, taking notes on the contents. There was tons of code, including an innovative package manager for a Linux distribution and a replacement DNS server, but Flir was most interested in a directory called siram/, wherein he found the siram/html/get_StudentData.html file.

The siram/ directory contained an html/ subdirectory with what appeared to be every web page in the my.ptech.edu web application. Flir checked his captured text from the get_StudentData.html file against the contents of the file in this directory and found that they matched. More importantly than this HTML mirror, though, the siram/ directory also contained a code/ subdirectory that seemed to contain complete code for the application. It had been modified only 6 hours before, probably during Ben s last CVS checkout.

One more find in Ben s home directory excited Flir, a directory called scripts/. As Flir read through each script, again taking notes on what each did, he realized that he could push application code directly to the my.ptech.edu application server using Ben s publish-siram.sh script.

Flir had been most surprised when, as he read the script, he learned that it used non-password-protected ssh public/private keypairs to check in application updates.

 # !/bin/sh # # Description: # This script scp's a CVS sandbox of the SIRAM (my.ptech.edu) application  # up to the server.  #  # Changelog: #  #  2/21/03 - Over the objections of bstrobell, this script uses a non- # passphrase-protected ssh key (id_rsa_siram) to authenticate to the  # server. Frieda requested this after Ben's sick day left her unable to  # push changes to the server.  bstrobell 

Flir couldn t believe his good fortune . For the convenience of the same administrator who had chosen to use a self-signed certificate on my.ptech.edu, there was no passphrase on the ssh key used to push application code changes to the server. If Flir could read the key file, he could run the script. He found that key file in the same directory as the script, with ownerships set to leave it accessible to the siram group .

This mistake was going to give Flir an entirely different way to get at the students data. It was going to do this because the Student Information Services group was taking the completely wrong approach. They were allowing Ben to store his CVS checkout of the application source code on an NFS-shared volume, relying on a non-encrypted network file system to preserve both the integrity and confidentiality of the code. They were allowing check-ins directly from CVS to a production system, instead of forcing it through a development mirror first. They were either not using a gatekeeper developer to approve and post all application changes or they were using a student for that role, allowing someone with a vested interest in the contents of the database to administer the application. Their mistakes were Flir s gain, though.

At a Nearby Helpdesk

Meanwhile, at the Pacific Tech helpdesk, Cathy took a call from Dave G.

I just got this e-mail from the automatic admin that said that I logged in to the my.ptech application today, but I haven t logged into that thing in 3 months, the caller said.

Cathy didn t know about the application sending out any messages and didn t see any information about it in the help desk knowledge base application. She didn t see any notes about it whatsoever. She could call the application administrators, but, like at many help desks, she had explicit and repetitive instructions about keeping calls brief, which made research on questions outside of the knowledge base mostly impossible .

I m sorry, but we don t have any records in our knowledge base about that error message. I m sure it was just a diagnostic function. Thank you for your call, she said. She felt guilty blowing the user off, but it was the only way she and the other help desk workers could keep from getting fired .

But that application controls my schedule and , he said before realizing that the line had cut off. Oh well, he thought, I ll just log in every few days and make sure that my class schedule hasn t changed. It s probably fine.

Modifying the Application

Flir read over the application code. The code was tight, fast, well-documented, and maintainable . Flir didn t even find any SQL injection vulnerabilities. He had read the two major papers by Chris Ansley, Advanced SQL Injection and More Advanced SQL Injection, and understood the techniques well, but Ben s code did a huge amount of input validation. This was unfortunately quite rare in web applications. Clearly Pacific Tech had made at least one or two good security- related decisions.

Finding a vulnerability in the code would have been the most stealthy and reliable way to abuse the application, but Flir didn t strictly need this technique. He could just modify the application code and publish it to the server right before the web app came online for the day. Flir didn t need to make any complex changes. He simply added a few lines to the session-tracking code so that it would respond differently if the session ID cookie was set to 404280206xc492734fa653ee9077466754994704fL. This was safe, since this ID wasn t completely hexadecimal, but all those generated by the application would be.

When the application received that session ID, it would run the following SQL query instead of the one it normally generated:

 SELECT SSN, FIRST_NAME, LAST_NAME, STREET, CITY, STATE, ZIP, PHONE, EMERCONTACT_NAME, EMERCONTACT_PHONE, EMER_CONTACT_STREET, EMER_CONTACT_CITY, EMER_CONTACT_STATE, EMER_CONTACT_ZIP from USERS 

The wonderful thing about databases, from an attacker s perspective, was that a web application generally only used one account to access them. That account could generally read the entire database, not just the parts that applied to a particular entry/student.

This line asked the database to non-selectively output the social security number, full name, address, phone number and emergency contact information for every student in the system. Normally a query like this would include a where <condition> clause before the from USERS “ this created the selectivity that Flir wanted to avoid here.

Flir kept the code on his laptop, ready to insert into Ben s home directory in the morning. He was excited, but wanted to wait until the morning when he could quickly insert the code before the application started. Hopefully, the administrators would either not yet be in at work or would be groggily consuming their first hundred milligrams of caffeine .

Flir logged out of his systems and returned to the dorm to get to bed early.