Retail Automation: ABS

by L00dHum

I have been working in a hardware store part-time in order to put myself through college.

During the course of my employment, a new Point of Sale (POS) called ABS was put into place by a company called Retail Automation.  I tried to stay out of the way the week of the installation but, once everything settled down, I began to look around the system and it has made for many hours of fun, which helps pass the time.

The system does not use a client/server architecture for its back-end, it simply uses a shared drive on a workstation.  The data files are in a format called ISAM.  Each table is a set of two files, a DAT file and a KEY file.  The DAT file is simply a collection of fixed-length records concatenated together and the KEY file is the index into the data file.  All of the data is free and clear and, since all of the POS and back office machines need access to read and modify the data, there is no security in place to prevent the theft or modification of the raw data files.  Retail Automation is even nice enough to provide a DOS executable in the SYSDATA directory, called VCFVIEW.EXE, which will happily open any DAT file and sort it into records for your viewing pleasure.

The system developer made a big deal about how his system had access controls to prevent unauthorized access, but I found it trivial to simply pull up my store's list of customers, contracts, special pricing, previous transactions, and a whole host of other information just by viewing the raw data files.  If you want to wreak real havoc, you can break out your favorite hex editor and change prices or modify receipts, since file modification is fully allowed.

I did find one table that was "encrypted," the OPERATOR table which stores the usernames, passwords, and authority levels for ABS.  One especially boring day I decided to pick this table apart and it only took me 20 minutes.  The table was encoded with a shifted alphabet substitution cipher.  If you don't have 20 minutes to figure it out, here it is: all lowercase letters are shifted by one, b = a, c = b, ... a = z - the uppercase alphabet has numbers at the beginning and is shifted by ten, 0 = A, 1 = B, ... A = K ... Z = 9.

With this table you can simply log in as any user that you want without having to use raw files or a hex editor.  The developer, Tom, and his wife, Lisa, appear to leave privileged accounts on the system for themselves without passwords.  There also appear to be superuser accounts named SYSADM and SECADM, where the passwords are set the same as the username.

The system does appear to be decent in that it doesn't permanently store any credit card information, but that doesn't mean that it doesn't send that information back-and-forth to the credit card authorization system in the clear.  It appears that Retail Automation uses the X-Charge system to integrate credit card authorization into ABS.  In our store, they installed the X-Charge authorization server on one of the POS machines.  This authorization server is responsible for receiving credit card authorization requests, sending them to the merchant server over the Internet (encrypted), and then sending the response back to the calling POS.

X-Charge interacts with ABS via a queue directory.  A request file is created with the extension .REQ that contains details of the purchase including the amount of purchase, credit card number, expiration date, and all of the information from the magnetic stripe including name.  X-Charge then reads in this information, sends it to the merchant service, and puts a response file back into the queue directory in a file with the extension .ANS.  Once the transaction is complete, the answer and request files are deleted.

The fact that they are on disk even for a limited amount of time means that the you can skim this data fairly easily by simply monitoring the queue directory.  There even exists a tool called WatchDirectory that will register itself with Windows so that it is notified when files change in the queue directory.  Then WatchDirectory will do whatever you want with these files, from emailing them to copying them to another location for you to peruse at your leisure.  I have not determined whether disk sectors are wiped when the files are deleted but it might be an interesting exercise to scan unallocated space for these data.  The request files all start with the text "XC_SALE" (quotes included), so the files should not be too difficult to spot.

Lastly, the developer thought it prudent to create a backup routine for our store by using a series of thumb drives.  A simple application waits until a predetermined hour and then copies all of the store's data onto the drive.

Since at least one of these drives is kept in a workstation at all times, it is pretty easy to swipe the drive and have a copy of the data for yourself or your next employer.

Through my meager interactions with the developer, coupled with what I have seen by exploring the system, it appears that Retail Automation is extremely cavalier when dealing with other people's proprietary and personal information.  It is almost always the people on the inside that you have to worry about, more than those on the outside.  Hopefully, they get a clue before any of their customers are harmed by their incompetence.

ABS is run mostly by hardware stores and other supply houses, but for a full list of locations you can visit their website at retailautomation.biz.