I am not without reason. Starting a new job and getting used to the way things are done on a new team is time consuming and can require a lot of focus. A wise man once said: "If you don't know what you're doing, do it neatly" It doesn't fit entirely, but the learning curve has been steep, and my first few cases were worked through slowly, carefully and methodically.
This is not to say that my next cases will be worked any less carefully, but I've found you develop a rhythm in an investigation and you have to let the evidence lead you down the path to the answer.
Case in point:
I have already had a number of POS breach cases where PCAnywhere was the point of intrusion. I will focus on 2 for the purpose of this blog. These 2 cases were similar in that they were both running the same type of POS software and it was set up by the same integrator.
PCAnywhere is a 2 part remote administration utility that has been around for a number of years. I don't know exactly when it came out but I remember running into it as a system administrator at least 7 years ago. It has gone through a number of version upgrades over the years and the latest stable version is v 12.5. The 2 parts are the client, which is usually used by the remote administrator to make a connection to a remote PC or server for maintenance. The second part is the listener which (obviously) resides on the client machine that is to be remotely managed. Here's a list of the versions and the port usage (by version) from Symantec:
I have used numerous pieces of PCAnywhere evidence in my cases.
The first is the connection logs. By default they are located in %SystemRoot%\Program Files\PCAnywhere and have a .pl9 extension. These logs are extremely configurable in the software itself. They are easily viewed by using a registered copy of PCAnywhere or by downloading a trial from Symantec. These logs could contain anything from a basic timestamp and a connection attempt ,to full Windows Event Logging and verbose connection details to include connecting IP, user id info, files transferred, etc. For a full list of logging options, see this site. Obviously these logs are very useful to an investigation. Unfortunately, they are rarely verbose and in many cases I have found that logging is not even enabled.
I have a problem with this. ADMINISTRATORS: IF YOU ARE GOING TO OPEN A GAPING HOLE INTO YOUR CLIENT"S ENVIRONMENT, AT LEAST HAVE THE DECENCY TO PUT IN A STRONG PASSWORD AND SWITCH ON THE LOGS! Yer killin' me. You're also costing your clients tens of thousands of dollars.
There are also a number of vulnerabilities related to the older versions of PCAnywhere. Search the CERT website to read further on them all. US-CERT Site. One of these older vulnerabilities allowed you to pass the listener a message that says your login type is "0" Which allows you to log in with full admin credentials using a null username and password. That's Kwality there.
A bit more in depth is a file that I have found extremely useful that you probably don't know about. When you log in using the graphical interface a file called aw.swp is generated. This file is a cachefile that is created to speed up Windows operation. It is used every time you use the remote desktop via PCAnywhere. This leaves a nice trail of birth, modified and access times in the system timeline. I even found evidence of card-holder data being moved in the aw.swp file. My assumption is that the built-in PCAnywhere file transfer button was used to move a file containing captured data. No one at Symantec ever contacted me back on this issue.
Nothing ground-breaking here. It just goes to show that some of the most common applications leave behind some very definitive evidence. Sometimes you just have to dig around a little bit for an explanation of why.
I'm putting the finishing touches on a presentation for this years round of conferences. It's called "I'm your MAC(b) Daddy" and focuses on using super timelines to solve breach cases. I will post it here if I don't get accepted. I also have a post on generating timelines for filesystems that are not supported by fls and mactime.
New updates soon. Thanks for stopping by.
Welcome back, Grayson! I missed you.
ReplyDeleteBelieve me, I know what you mean. You hate to neglect your blog, but sometimes you just can't do it. Every time I comment on someone else's blog, I think, "I should be putting the time into my own blog!" It's a log easier to comment than write, that's for sure. And you can comment in little chunks and I find it hard to blog in such little chunks.
Anyway, this post brought back bad memories about PC Anywhere that I had as an admin, so I can relate. Few turn on logging, which still irritates me.
Looking forward to more...
Good point. The problem is that most people don't view PCAnywhere as a gaping hole in an environment if it is setup with a password and is transmitting via encryption.
ReplyDeleteThanks for the comment Greg. My view on this comes from the worst possible perspective. I get called after someone has leaked cardholder data or other sensitive information. When I see PCAnywhere it is NEVER set up the way you stated. That being said, the PCI standards state to use two-factor authentication for all remote access. and I always recommend that any remote management be "Client initiated" instead of always listening.
ReplyDeleteBTW, to anyone reading this comment, I do not have any desire to argue the fundamentals of the PCI standards with you. They are what they are.
Interesting...but not surprising. Our company uses GoToMyPC and LogMeIn to manage entire domains. I always wonder about the security concerns, but we do change complex passwords on a regular basis. The nice thing about GoToMyPC is they will tell you failed login attempts at your next login by default.
ReplyDeleteI figured you were a little too busy in the IR/F department at Spiderlabs to post on the ol' blog.