Insecurity at Pep Boys

by Sakuramboo

After working for Pep Boys for over four years, I have seen a lot of changes from within the company.

First I started out as an installer, doing the BS work on cars (changing batteries, headlights, tires, oil, etc.).  Then I moved to the parts counter, learning the computers used to look up parts and write up work orders.

This was a pretty simple UNIX server accessed by IBM InfoWindow II 3153 dumb terminals throughout the store.  In 2005, all of the systems got updated with new hardware as well as software, replacing the UNIX server with a Linux SUSE Enterprise OS and IBM SurePOS 300 terminals.  These are the accounts of what I have found out in my short time with the new systems.

When starting the dumb terminal up, you are given the ShopX program which is used for ringing up customers.  You need to login with your own numbers (if you are a cashier).  When you minimize the window, you are presented with a blank background and a pointer.  The GUI resembles that of Window Maker.

Right-clicking brings up the menu where you can launch Starlight (parts lookup), Commercial Sales (for APD accounts), inside.pepboys.com (the Pep Boys intranet), an option for letting you set the menu to either parts or service (the difference is that service gets two Starlight programs, whereas parts gets one Starlight and one Commercial Sales program).  This is where I found the first little bug.

When you load either Starlight or Commercial Sales programs, you are presented with a login and password prompt.  By hitting Ctrl-5, you will drop to a Telnet prompt.

From the Telnet prompt, by hitting Shift-1 (!) you will be dumped at the command prompt with read and write access to the Retail user's home directory.

After poking around the terminal's hard drive, I was looking to see just what I could and could not do.  GCC was not installed.  However, the Perl interpreter was installed and could be run from the Retail account.

Now that I had acquired Bash access, I decided to see how far I could take this.  Just what exactly were my limitations on the Pep Boys network?

From the command prompt, I decided to ping the inside.pepboys.com web server to make sure that the server was up and accepting requests.

With zero percent packet loss, that meant that the server allowed for ICMP requests, which allowed me to assume that all the servers would accept them.  So, I should be able to just ping any server and determine if the server was up or not.

Everyone at the store was told that no one is allowed Internet access because the firewall blocks everyone out and in.  So, my first idea was to access the router and enable Internet access.

The first step was to find out the IP address of the main store's router.  A simple traceroute would solve this:

retail@str0192rg112:~> /usr/sbin/traceroute inside.pepboys.com traceroute to inside.pepboys.com (172.21.10.74), 30 hops max, 40 byte packets 1 rtr0192-999.pepboys.com (10.0.192.74) 3.418 ms 3.435 ms 3.441 ms 2 per0192-pepboys.com (10.33.4.10) 93.991 ms 188.497 ms 184.530 ms 3 cercorpvp7.pepboys.com (10.33.17.57) 165.771 ms 161.773 ms 157.775 ms 4 rsmbvlanl42.pepboys.com (172.21.140.19) 153.772 ms 149.777 ms 145.692 ms 5 phlweb2.pepboys.com (172.21.10.74) 141.519 ms 137.523 ms 133.549 ms

There were two factors involved in determining the store's main router.

The first was the IP address.  The IP address of the terminal from which I was doing this was: 10.0.192.212

So, with this, it is safe to assume that this store owns the 10.0.192.* IP range (the store number is 192).

The other factor involved was the hostname of the routers.

rtr0192-999.pepboys.com was likely the main router.  But, how will I access it?  That is where Telnet came into play.

retail@str0192rg112:~> telnet telnet> open rtr0192-999.pepboys.com Username: mod0192 Password: mod0192 Router_0192#

Now you might be thinking to yourself, "How do you know the username and password of the router?"

Well, to answer your question, I must tell the story.

Pep Boys used to have employees clock in and out via a time clock that was hung on the wall outside of the office of the store.  That got replaced by a computer at the register that is wireless-enabled with Cisco LEAP encryption.

Whenever that computer had a problem, it needed to be restarted and the store manager would need to know the username and password to log it in.  The store manager at the time had a problem remembering the login information so he wrote them down on a piece of masking tape and taped it to the keyboard.  Of course, I remembered it.

But, did I know that it was the same login information of the router?  No.  I just guessed and it worked.  So, back to the router...

Upon accessing the router via Telnet, I typed dir to view the files and found a config file.

I felt that it was safe to assume that this config file had the access list needed to open the blocked IP ranges.

After failing to open the config file via Vim, I enabled FTP on the router and attempted to "get" the file to the dumb terminal's hard drive, allowing me to view the file.

Router_0192# configure Router_0192 (config)# ftp-server enable Router_0192 (config)# exit Router_0192# exit retail@str0192rg112:~> ftp ftp> open 10.0.192.1 get /sdmconfig-2811.cfg /home/retail/sdmconfig-2811.cfg

This, however, backfired and locked the entire network.

Every terminal could not access the store's network.  Parts Lookup, Work Order Systems and cash transactions at the registers were all knocked offline.

So we (we being the manager on duty and myself) called MIS (the Pep Boys tech department) who told us that another store just got the same thing.  They told us to do a hard reset of the router.

Once we did that, the network came back online.

However; I did not want to attempt this again to find out for sure if the file transfer was the reason behind the network crash.

So I decided to check out the other settings from within the router.

I viewed the access list for the router but nothing turned up.  So that meant that MIS was lying to everyone (which isn't too uncommon for them).

So now I decided to try and find an open proxy somewhere on the network to access the outside Internet.  My initial thought was that there might be a server on the subnet of the intranet that might be used as a proxy.

So I wrote a crude IP scanner to scan for open IP addresses:

#!/usr/bin/perl $subnet = 000; while ($subnet <= 255) { system("ping -q -c 1 -w 1 172.21.$subnet.11"); $subnet = $subnet + 1; }

The terminal window allowed me to view the entire output in the window.

But later on I had that script dump the output to a text file for later reading.

After finding any open IP address, I needed a port scanner to see if any known proxy ports were open.

Nmap was out of the question.  Users do not have access to mount external data storage devices (thumb drives), so I had to write something with the tools I had available.

This prompted me to write a crude port scanner in Perl:

port-scan.pl:

#!/usr/bin/perl use IO::Socket; my $port = 1; $file = "/home/retail/perl/ports.txt"; while ($port <= 10000) { $sock = IO:Socket::INET->new(PeerAddr => '172.21.101.11', PeerPort => $port, Proto => 'tcp', Timeout => '1'); open (LIST, ">>$file"); if ($sock) { close ($sock); print "$port -open\n"; print LIST "$port -open\n"; $port = $port + 1; } else { print "$port -closed\n"; $port = $port + 1; } } close (LIST);

port-scan-update.pl:

#!/usr/bin/perl # # (c) Sakuramboo (2600 mag-vol 23-num 3) # # Modified and enhanced by deprecated (james@phpnasium.net) # use warnings; use IO::Socket; $port = 1; $ip = "192.168.0.2"; my $txt; for ($port = 0; $port <= 1000; $port++){ $sock = IO::Socket::INET->new(PeerAddr => $ip,PeerPort => $port,Proto => 'tcp',Timeout => '1'); if ($sock){ if ($port == 80){ print $sock "GET / HTTP/1.1\r\n"; print $sock "Host: www.example.com\r\n"; print $sock "Connection: Close\r\n\r\n"; while(<$sock>) { if ($_ =~ /Apache/) { $_ =~ s/Server\://; print "PORT 80 (opened) -- Response:$_"; } # close($sock); } } elsif ($port == 22) { while(<$sock>) { print "PORT 22 (opened) -- Response: $_"; close($sock); } } else { read($sock,$txt,1024); print $txt; # # while(<$sock>) { print "PORT $port (opened) -- Response: $_\n"; # close($sock); # } close($sock); } close ($sock); } else { # print "$port closed\n"; } }

After letting my port scanner do its thing, I found that the aforementioned IP address had port 80 open.

So I decided to try this out and see if maybe it was a proxy (I know that proxies normally don't run on port 80), but another problem arose.  I had no way of inputting the proxy address into Mozilla.

Almost everything in the tool bar was blocked out.  So I needed to enable everything that was missing.  Getting to the orimand prompt...

retail@str0192rg112:~> cd /.mozilla/default/ogngseuh.slt/chrome retail@str0192rg112:~/.mozilla/default/ogngseuh.slt/chrome> ls chrome.fdr userChrome-example.css userChrome.css userContent-example.css

I loaded userChrome.css in Vim and deleted all the lines that blocked everything out.

Now I had the ability to load, edit, and change all the preferences in Mozilla.

Under "Edit -> Preferences -> Advanced -> Proxies".

I inputted the IP address of the IP with port 80 and 81 open.

On port 81, it brought me to the Store Support Center (SSC) Intranet for Pep Boys.

After poking around there for a while, I clicked on the link for MIS and saw a link named "VPN Clients" and another link named "VPN Client Downloads."

I downloaded the VPN client for Linux and installed it in the retail home directory.  Another feature that the MIS page had was a guide for all new MIS employees.

Detailed information on how to do their job was posted for everyone to view (which wasn't really informative).  It mostly consisted of Code of Conduct for the employees to follow.

Another IP address that turned up having port 80 open brought me to the corporate headquarters' intranet.  There was not that much useful information other than what was on the lunch menu for that day.  Tomato soup was the Soup of the Day.

When I got closer to quitting at Pep Boys, I found out that both the Part Lookup and Service terminals were going to be replaced with a new web-based interface.  By the time of this printing, it would be safe to assume that only a small minority of stores have had their software upgraded, since Pep Boys tends to upgrade only their high traffic flow stores first, in turn, using them as beta testers for any new software.

The short amount of time I had with the new hardware taught me a lot about how Pep Boys has their network set up.

However, because I only had a short amount of time, I was unable to finish my task of gaining Internet access from the terminals.  Shortly after finding these bugs in their network, I graduated college and moved out of state, prompting me to quit there and proceed with work in my field.

Thanks to dhbwho, DualDFlipFlop, LUG, and everyone at J!NX.

Code: port-scan.pl

Code: port-scan-update.pl