Yesterday’s story about the point-of-sale malware used in the Target attack has prompted a flood of analysis and reporting from antivirus and security vendors about related malware. Buried within those reports are some interesting details that speak to possible actors involved and to the timing and discovery of this breach.
As is the case with many data breaches, the attackers in this attack used a virtual toolbox of crimeware to get the job done. As I noted in a Tweet shortly after filing my story Wednesday, at least one of those malware samples includes the text string “Rescator.” Loyal readers of this blog will probably find this name familiar. That’s because Rescator was the subject of a blog post that I published on Dec. 24, 2013, titled “Who is Selling Cards from Target?“.
In that post, I examined a network of underground cybercrime shops that were selling almost exclusively credit and debit card accounts stolen from Target stores. I showed how those underground stores all traced back to a miscreant who uses the nickname Rescator, and how clues about Rescator’s real-life identity suggested he might be a particular young man in Odessa, Ukraine.
This afternoon, McAfee published a blog post confirming many of the findings in my story yesterday, including that two malware uploaders used in connection with the Target attack contained the Rescator string:
“z:\Projects\Rescator\uploader\Debug\scheck.pdb”.
![A private message on cpro[dot]su between Rescator and a member interested in his card shop. Notice the ad for Rescator's email flood service at the bottom.](https://krebsonsecurity.com/wp-content/uploads/2013/12/rescator-pm-cpro.png)
A private message on cpro[dot]su between Rescator and a member interested in his card shop. Notice the ad for Rescator’s email flood service at the bottom.
“First, the malware that infected Target’s checkout counters (PoS) extracted credit numbers and sensitive personal details. Then, after staying undetected for 6 days, the malware started transmitting the stolen data to an external FTP server, using another infected machine within the Target network.”
Seculert continues: “Further analysis of the attack has revealed the following: On December 2, the malware began transmitting payloads of stolen data to a FTP server of what appears to be a hijacked website. These transmissions occurred several times a day over a 2 week period. Also on December 2, the cyber criminals behind the attack used a virtual private server (VPS) located in Russia to download the stolen data from the FTP. They continued to download the data over 2 weeks for a total of 11 GBs of stolen sensitive customer information. While none of this data remains on the FTP server today, analysis of publicly available access logs indicates that Target was the only retailer affected. So far there is no indication of any relationship to the Neiman Marcus attack.”
Target has taken quite a few lumps from critics who say the company waited too long to disclose the breach, and new details about when it may have known something was wrong are likely to fan those flames. As I wrote yesterday, the point-of-sale malware used in Target referenced a domain within Target’s infrastructure called “ttcopscli3acs”. Several sources, including Seculert’s Aviv Raff and Dmitri Alperovitch at CrowdStrike, searched for other files with that unique string within the corpus of malware uploaded to Virustotal.com, a service that employs more than 40 commercial antivirus tools to produce reports about suspicious files submitted by users.
That search turned up numerous related files — including the aforementioned malware uploaders with Rescator’s nickname inside — all dated Dec. 11, 2013. Since this malware is widely thought to have been custom-made specifically for the Target intrusion, it stands to reason that someone within Target (or a security contractor working at the company’s behest) first detected the malware used in the breach on that date, and then submitted it to Virustotal.
Yesterday’s story cited sources saying the malware used in the Target breach was carefully crafted to avoid detection by all antivirus tools on the market. These two virustotal scan results from Jan. 16 (today) show that even to this day not a single antivirus product on the market detects these two malicious files used in the Target attack. Granted, the antivirus tools used at virustotal.com do not include behavioral detection (testing mostly for known threat signatures). I point it out mainly because nobody else has so far.
Incidentally, in malware-writer parlance, the practice of obfuscating malware so that it is no longer detected by commercial antivirus tools is known as making the malware “Fully Un-Detectable,” or “FUD” as most denizens of cybercrime forums call it. This is a somewhat amusing acronym to describe the state of a thing that is often used by security industry marketing people to generate a great deal of real-world FUD, a.k.a. Fear Uncertainty and Doubt.
The NYP just posted the following about the Russian kid:
http://nypost.com/2014/01/18/teens-malware-eyed-in-target-data-breach/
When it comes to that newspaper, the letters in Post stand for piece-of-shit tabloid.
Heh!Heh! There are also already rumors on cable news about the mob being involved. It does seem an organization is in the works, but there again, that could throw investigators off. What if the crook used a wise combination of planting code at one location, then some undetectable worm/virus activity could do most of the dirty work. I’m sure it would take quite the coordination to receive and sell the data though. That is where good organization would be required, and splitting the booty up so it could be more efficiently exploited, as naturally there are time constraints on the value of the data(booty). Investigators may have to follow the money trail back to the originators. That would be a complicated mess – but Brian has exposed such operations before.
I know from one bank executive in my area, that even one single organization had 5000 affected card users, in a very short time window, just in my area. This doesn’t count the other local banking institutions. This breach has affected many people I personally know. This has to be the worst heist in history, because I’ve never had so many clients hosed like this before.
That news is also on marketwatch.com :
http://blogs.marketwatch.com/behindthestorefront/2014/01/17/a-17-year-old-is-reportedly-author-behind-malware-that-led-to-targets-data-breach/
They named the wrong guy.
These things happen because everybody believes that naming names is a race. I repeatedly comment on these sorts of things to you precisely because you were the one who has set this precedent of prematurely ‘naming people’ and basically accusing them in the public sphere before they have even seen legal charges more than anybody else, and they are all trying to be like you and follow your actions. It is about protecting peoples’ privacy, and about correctness, but it is also about setting an example.
Fascinating reporting and comments! this from an ex-Fortune 100 CIO…..whereabouts of current Target CIO?! something about “the buck stops…..” comes to mind.
question..do we know how much these perps really made? My understanding is that given prices for cards the persps only made a few hundred thousand off this? Press is now reporting $18bn losses. How could that be outside of including reputation losses to Target?
For example, I would think it would have been hard to make more than $100 million in purchases on these cards without Visa/Amex and banks wising up. How many criminals out there can create cc’s, use them convincingly, and not trigger anti theft measures (cards rejected for out of town use, etc.).
So I’d love to see thoughts about the breakdown of potential losses to Target/banks.
My understanding is subsequent credit card fraud hits the issuing bank, but debit card fraud stings the merchant who accepted it. Given the Target’s delay in disclosure makes me wonder if they considered the leaked credit vs. debit ratio, as debit card fraud would likely fall on their competitors and they could block any leaked debit cards from being processed in house.
Does Target know who’s on first? I didn’t shop at a Target store during the timeline initially published for the POS theft.
But on 1/15/14, I received an email apparently from Target. It was sent to an address I don’t use now but which I may have used many months ago for an online purchase. It said” Target is offering one year of free credit monitoring to all Target guests who shopped in U.S. stores, through Experian’s® ProtectMyID® product … To receive your unique activation code for this service, please go to creditmonitoring.target.com and register before April 23, 2014.”
All Target purchasers? This means that all Target systems were breached? Or just that Target systems can’t separate in-store purchasers from on-line purchasers?
Dalia:
Have you EVER returned anything at Target? I did not shop at Target during that period and the ONLY way I could think of how they got my e mail is that I did a return a few years ago. And I recall them demanding an extraordinary amount of personal data to do so.
Yes, I’ve also done returns, but not during the stated POS timeline. I think they’re doing scattershot CYA.
Dalhia,
Conversely, I have never purchased from target.com. I shopped at my local Target store using a Chase Bank CC (double whammy) twice during the “official” breach period as per Target. I have not received any communications from Target regarding such, nor from Chase. As a matter of fact, when I called my local Chase branch to find out if I should have my account number changed, I was told it is not necessary and that they are advising customers to check their accounts at least once a month and to notify them if any suspicious charges show up. Now, that’s really protecting the customers, NOT!
My card contains an RFID chip, otherwise known as “Blink.” I have never been a big fan of RFID chips because certain purchases do not require a signature and can be read through a wallet unless cloaked in tinfoil akin to the US embassy in Russia during the Cold War, which leads to fraudulent use if the card is lost or data lifted. Having worked my way through college as a retail manager, I learned to write in BOLD letters above my signature, “**CHECK PHOTO ID!**” (for what it’s worth these days). I do use Blink transactions because they allow me to let my purchases ride for an entire statement period interest-free if I have an on-going balance as long as I pay off those purchases by the due date. One of my beefs has always been that Target’s outdated card readers do not have a Blink function, just a magnetic strip reader. Swipe away.
Who are the wizards who came up with this plan? Copies of all letters sent out to Target customers are on Target’s website, making it easier for criminals to spoof official communications. In order to sign up for the free credit protection from Experian, customers have to go to a link on Target’s website and provide an email address to which a code will be sent. To make matters worse, the service offered doesn’t monitor info from all three major credit bureaus, just Experian. After a year, you’re on your own. What a joke!
I know of one person whose CC used at Target was used to open a duplicate PayPal account in another name using his address and CC info right after Christmas. He contacted PP when he noticed several odd charges posted to his CC account for relatively small amounts.
Purchasers of extended warranties on appliances purchased at Target would have given out their contact info to be stored in their database for at least several years.
I still receive bi-monthly coupons via text messages from Target, which I signed up for via some gobbledygook process at target.com eons ago. So far, no text message touching on the subject. So, they have my cell number on file for that purpose, but no weird calls or texts coming in, yet. Do I need to worry about mal-texting or hijacking of my phone account or voicemail, too?
Another thing to consider. which I have not seen addressed to date, is medical and health insurance fraud as a result of the breach if one interacted with Target Rx in any way. Health insurance policy info and personal data (name, address, phone no., DOB, employer, Rx history, etc.) is stored for future use. Hopefully, HIPA requires them to store data on a separate system apart from the regular store?? In addition, state driver’s license data is collected at the pharmacy counter anytime someone purchases Sudafed as per the Feds. (Thanks a lump, drug addicts.)
Put that in your pipe and smoke it!
You made two mistakes. First, banking at Chase. Secondly, using anything but cash at Target (or anywhere else.)
Right. I’m not responding to the email that says it’s from Target. Who knows if it and its web link are authentic and sound.
The clumsiness of Target’s outreach makes me wonder if their efforts to fix security are equally quixotic.
I wonder where Volksana has gone off to? He seemed to disappear after Liberty got popped. I would be interested to hear a “native” opinion on the matter, as all threads in this case seem to point one direction, East.
I never left. I commented a lot in the earlier threads but this whole subject is hard to keep up with and I got tired of repeating myself. Insinuating that the malware users were from my part of the world is probably biased at this point in time. As far as I know they have only been trying to name who is responsible for the software that was used and who is selling the data. I have seen no ‘hard’ information about who actually did these crimes or where they are from. And I am a technical person only who does a lot of systems integration work — those are not my “social circles”. For technical information a few other people who have commented in all of these Target threads have proven themselves very well versed in the technical matters as well.
What is really ironic about this mess is http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=4000009407
Target should have used linux for secure applications. There is no way a program in one process could scrape the RAM in another process.
“There is no way a program in one process could scrape the RAM in another process.”
This is dangerously incorrect, but to explain why would be highly technical and take many paragraphs. If you are a very technical person I would be glad to provide you with some starting links to read.
Which is not to say that some form of embedded linux is not more appropriate for POS applications — it almost certainly is, especially hardened with the appropriate kernel patches. But there is no perfect solution and there is always a weak place in any network. If an attacker really wants to get in your system they just would switch to a different vulnerable point in your organisation (often the employees) or find a different ‘goal’ (for example loyalty databases, which often are hosted on backend servers having nothing to do with the POS machines).
I’m still not actually sure if it was reading memory through some sort of module with escalation (documented or otherwise), or if it was simply reading from the USB bus. I keep thinking those card readers are probably just USB “keyboard” devices, but I don’t know how they work.
In theory a process @ ring3 can’t read memory from another process. That’s only in theory, though. There are plenty of documented and undocumented ways to get at RAM you don’t own. OS/2 actually used 3 rings (kernel, drivers, apps), which is why you can’t get it to run in VMWare. This was a _slightly_ better design in terms of escalation, but I think it’s an Intel only thing so nobody does it. I talk about OS/2 because it was actually an interesting architecture and borrowed a lot from Unix and fixed a few things. As I recall, its permissions sucked, though.
Err. You don’t need root to run a debugger on any sane OS. You at most need a debugging privilege which is not generally restricted.
Now, while you can get debugging privileges, they generally only work on other processes owned by the same user.
This whole exercise is pointless. I’m assuming that the software was distributed by a central update service (Brian hasn’t indicated if the malware was deployed, or if it relied on individually exploiting each terminal).
Assuming that the malware was distributed by a central service, the same could trivially happen on Unix or any other platform. If you’re doing an update, the update process generally has effective root permission to write to the file system and set the effective owner for the processes.
If the malware actually relied on attacking the individual terminals, it probably exploited a buggy process that had more permissions than the average process on the terminal. It’s trivial to have the same sort of misconfiguration on other platforms.
While you could design a modern system the way that modern cell phones work (each process has its own user and its own sandbox), that’s a fairly modern design and was only deployed because of a modern threat model where there was an expectation of untrusted content on devices. ATMs and PoS terminals assume that the only threat is physical.
It’s really hard to design a system where you don’t trust your creator. Especially if you expect to deploy updates from the same.
I’m not saying Target is blameless (I fault at least the monitoring system of their network for not recognizing the data disclosure). But I disagree with the back seat driving and hindsight of some people here. It isn’t so simple to design things correctly and expect them to survive for decades against future unimagined threats.
With all due respect @Jeff, that assessment is ridiculous. x86 is x86. You can get to any address once you’re at ring0, and there’s a way to get there in Windoze and Linux both.
Not at all ridiculous. I realize that once you have gotten into the kernel, you can do anything you want to. The problem is getting into the kernel. With every release, Linux goes through a corpus of software that tests the security of the system. Some of this software goes back to 1969. With Windoze, you can’t do that. It’s really, really hard to break into the kernel of a linux system. If you are really concerned, you can soup up the security of the machine by installing SELinux. Windoze has no equivalent.
There is an argument that there are fewer viruses for Linux than for windows because there are more windows machines than linux machines. I think that is a bogus argument. I would expect that hackers would go after linux machines more precisely because the sysadmins are lulled into a false sense of complacency. Most sysadmins do not audit the software they install on their machines, even though they have the source code to do it with. It ought to be relatively easy for a Bad Guy to slip in some malicious software into the source code. I’ve heard of servers getting compromised, but I’ve never heard of malware getting distributed as source code or through a distribution.
Not sure where you got “1969” or why it’s relevant. Anyway, you’re confusing Linux with Unix. Neither the kernel nor most of the userland tools have any roots in Unix. FreeBSD possibly does, but almost nobody uses it.
Hackers do indeed go after LAMP machines with malware. I know sysadmins that go after it every day. It’s an annoying job. Lots of PHP crap is frightfully poorly written. I really see no substantive argument here. As for auditing, who the heck doesn’t just do an apt-get? You think you’re going to see a trojan in 500 KLOCs?
Linux is no better than Windows. It’s just that it’s usually the LAMP machines not the users just running Ubuntu at home. They’re possibly better for botnets and proxies because they’ve got bigger upstreams.
I have no idea what you’re saying. Escalation is possible in both Windows and Linux. There are actually more tools for Windows including a multitude of AV suites and malware removal kits. Generally you have to pick 1 for realtime protection, but feel free to run the various on-demand scanners and rescue disks. There’s also PeerBlock to block suspicious connections and Zemana to preemtively block keylogging.
None of that stuff exists for Linux, which may or may not have better permissions out of the box than Windows 8 at this point.
All general-purpose O/S software written for mainstream processors (x86, m68K, etc.) is highly complex, very flexible, and implemented, installed, supported, and maintained by falible humans. Assume it has holes.
OpenBSD has an enviable track-record here – I think only one reported vulnerability “in the wild” in the past decade. However, it gets this by being extremely conservative about adopting new code, interfaces, techniques, etc. – which means it may not support the latest hardware or software packages you want to use.
“which means it may not support the latest hardware or software packages you want to use.”
But it does not NEED to and in fact you do not WANT it to. Many retail stores still use RS232 instead of USB — and in fact I would say that is a FAR better choice. No USB ports means no chance of infection via USB ports (or live booting possibilities), for instance. Why do you need the latest hardware OR software on a system that fundamentally needs to FUNCTION not make a user entertained?
Answer to that is simple — cost.
POS terminal can be an embedded device which has proper security measures such as anti-tamper circuit which erases memory used to store encryption keys. They can be connected to the ECR (electronic cash register) and in that case your card info never leaves the POS itself except encrypted to the payment processor host.
Or it can be a POS made by say NCR which is basically an x86 PC in a custom case with touch screen, cash drawer, card reader, receipt printer and barcode reader. Which 99.99% of time runs Windows XP, sometimes without service pack because some obscure device driver might stop working otherwise.
Development on embedded system is harder, SDK cost is ~4,000 USD while everyone can write code for Windows and the cost can range from free to the price of an MSDN subscription. Add to that mandatory training and certification for embedded POS developers which costs around 1,000-1,500 USD per developer not counting travel and hotel expenses or the price of development terminals and already you are looking at two different worlds.
For embedded system there is also the cost of ISO, ADVT and TIP certification for payment applications and the necessity to have both POS and ECR instead of just one device like you have with x86 PC based POS.
Finally there is data collection — merchants want to have your CC data in their database “so they can serve you better”, and many of them need the data for their backend processing which is again cheaper than the one done by the banks and payment processors.
When you consider all that it becomes apparent why PCs running Windows are chosen.
If those POS terminals were embedded, the thieves would not have been be able to download anything onto them. Latest generations require digitally signed applications and once preloaded with a sponsor certificate prior to field deployment there are only two signatures the terminal will accept — that of a vendor and that of a developer. Any unauthorized download will wipe the device memory clean.
Contrary to popular belief, safe card processing is possible, just not in the USA which has the worst credit card security in the world, right next to Malaysia and Vietnam if not worse, but its the same country where bankers get a free “Get out of jail” card so I am not surprised that fraud is rampant when there is no criminal liability for negligence.
I’m not sure that’s the whole picture. The USA is always a little slow on infrastructure updates, but I’m not sure it’s the typical reason here.
The “problem” is that consumer protection laws in the US protect the consumer unambiguously. Chip and pin, in the EU basically indemnifies the bank and merchant if the pin is entered and the chip speaks the right magic. That’s worth $$. Suddenly banks want to subsidize the equipment and merchants want to buy it. The US credit card infrastructure is possibly deliberately lax on security because the banks figured out that making the payment process easier and faster yields more $$ than the occasional exploit. The RFID cards aren’t a sophisticated chip (the output is constant), and they don’t even require a signature on smaller amounts. Whoa!
Why is this? In the USA chip and pin will not indemnify both the bank or the merchant like it does in most other countries. So you’re 100% correct, but it’s actually well-meaning consumer protection law slowing its implementation. If someone somehow exploits chip and pin, you’re SOL by the way. In the US if someone swipes your card even if you’re kind of dumb about it, you’ll get your money back.
It’s iffy which one’s better, right?
Yes, only one or two, but that’s in the default install, and only remote holes. Who said it didn’t start from a Target “team member” deliberately or via social engineering? There are many escalations in various *nixes once you’re logged in via any user. The reason people probably panic less over those is because *nix is still mostly a server OS. I have no doubt OpenBSD is more secure even when your fingers are at the keys, but …..
There’s another practical reason few use Linux or even OpenBSD for a POS. Slam Microsoft as much as you want (I do), but they’ve supported XP since 2001. Try to find any *nix distribution that is is supported and patched so long. They might have to recompile their apps in coordination with the new version of *nix OS. That’s not fun. Vista/7/8 will still mostly run XP apps and vice versa without recompiling.
The only thing that might have protected Target here using commodity parts was multiple layers and/or obscurity. Even with Windows, Target could have done things at the network level to mitigate it, write code to hash various elements of the file system and sound an alarm if something looks funny, etc. They didn’t notice someone added an account. Simply diffing the user list would have picked that up, right?
Whatever the system is, it only is as good as the people, using it! Take Mac, Linux, Windows, Android, due to the fact, how all of them are developed these days, they all have issues. If you think, Linux is safe, look into the CVE list and learn.
As long as the main attitude is saving money on your staff, outsourcing whatever you can, we will have many issues like that!
Do not worry, I know these CVE lists very well. Why would you think I’d suggest an off the shelf distribution? Maybe you need to learn more about embedded linux. The kernels are very tiny, and often are older and far more stable. You do realise people can easily build custom kernels containing only what they need in them? And if you do not like embedded linux, there is always Minix, NetBSD, OpenBSD, QNX, and a ton of other very customisable operating systems (some of them used for backend processing and in the financial industry in other guises already). Why would you need a state of the art kernel? Most hardware is pretty generic for POS terminals, as are most drivers that would be necessary. Only compile those specific ones in.
Where as if you use Windows you cannot even patch a problem unless it is provided to you (this does not happen over night) if you see it is causing problems. Nor can you even do much of a temporary fix. In fact, you are pretty much totally at the mercy of a closed operating system.
I think this proves again how a large company can on the surface look modern and up to date and in reality have technology that is far removed in reality. The true lack of security and the delay in detecting, notifying customers and determining the true scope of the compromise of personal information is embarrassing. Yet the CNBC interview with Target’s CEO was nothing more then a PR speech similar to what our President does when things go bad. It seems more important anymore to play damage control then to actually prevent the damage to begin with. Much of Europe uses chip security in credit cards, and as we have seen with Starbacks storing personal info in encrypted text. Nobody is learning from other companies mistakes. Is security so costly that companies simply feel its not cost effective? Is it why so many ATM’s still use XP? Until we see a mega wave of security breeches. I think many companies will still have their heads in the sand. They will choose to risk it, rather then prevent it. Obviously the Target CEO feels a years worth of credit monitoring and a SORRY is enough for consumers. We will see.
A trusted source close to the situation has told me the attack did *not* come through target.com…
In the case of Target, are debit cards at the same risk as credit cards? Should those be changed to prevent theft of “real” money vs. “credit” money? Would it be safer to use checks or is the information sent electronically about the checking account at the same risk as credit/debit cards?
Linux is no better than Windows.
Depends on the Linux and what is applied to it, how stripped down it is, etc. If it were a very tiny kernel with ONLY the necessary modules and functionality needed to run the POS machine, hardened with selinux and grsec and role-based auditing, with no dev or module loading abilities or applications on the machine, along with an immutable and regularly rebooted operating system that was closed-source… and maybe add in asynchronous communications to deal with data transmission and receipt, you’d have a hard time finding a much better solution. At that point the only place it could be modified is at the distributor or anybody with the source code only. I dare you to find the ability for anybody to do this with Windows — you cannot and you never will.
But almost nobody will do this. I’ve actually noticed a number of POS and ATMs still use OS/2, which is one of the greatest security-by-obscurity arguments I’ve ever seen (but let’s not go there). It’s fading, but still there. A lot of ATMs still run OS/2.
I think Target would have also caught it if they simply kept md5s of all the files (and recognized new files) on the file system and periodically audited machines for new processes. They could spot-check machines using rescue disks they prepare and have employees run on a few machines and sign off like the bathroom checks — perhaps also with a code the application returns, and alert higher-ups if the rescue disk — perhaps that runs Linux or WindowsPE says something’s up.
There are simple solutions, you know? I believe this malware added a user. That would get picked up, I’d think.
Don’t forget there are also many commercial off the shelf tools for Windows security that do work, and Target could have contracted to a few security companies for a custom solution based on off-the-shelf tools. In Unix you’re typically more on your own, but that’s my opinion.
Of course it will not be done — there is no business out there that makes it and will support it (regardless of the fact that Windows obscures the chance to do anything ‘real’ at the lower levels of the operating system — which is why AVs will always be ineffective and thus profitable, but that is a different comment. :)). Of course, if such a business were to exist and somehow it were breached somewhere, then the vendor would bear the blame.
Why do people not blame running embedded Windows at least partially for these breaches? It is hard to blame the store if there aren’t truly great alternatives out there — then it comes to policy and procedure, but in a retail environment so many people are touching so many things and there are so many systems integrators involved that… Yes. This environment cannot be secured as it is. That is part of the ‘problem’.
I agree OS/2 is a great security via obscurity OS; in general security via obscurity DOES have value in financial situations. It frustrates me when people think ‘security via obscurity’ means ONLY via obscurity, but again — a different comment.
With regard to MD5, MD5 has been proven to be a weak hashing algorithm. Change that to SHA256 sums and keep those sums on a completely separate environment along with something like DeepFreeze on the machines and you may have a chance.
Process auditing, also, could be enforceable and useful (unless you get a truly good intruder but as I’ve been saying with somebody in emails — these retail sniffers are rarely ‘custom’ sniffers. It is ‘malware as a service’ that has made obscurity such an important thing, too). At the very least it could buy you time, especially if you were keeping process logs. Few people would know how to change process logging that was constantly being pushed to a different LAN segment, one-way-only, write-only. To change THOSE ingress/egress rules themselves should raise their own flags.
If anybody wanted to offer me or anybody else investment money for a system involving some of these ‘features’, I’d be surprised. Like most good security, even if it is accessible, without a big name attached it is futile. And of course the ‘who takes the blame if it doesn’t work’ factor comes into play. If you don’t claim to be secure you are far more likely to be ignored mostly for the ‘blame’. If you claim to have any security, it probably will be called ‘your fault’ even if things would have been far worse. And this is its own problem.
Does anyone know who Target’s PCI auditor was?
Also, any new info on the root source of the breach?
Thx,
Jeff
Krebs,
It would be nice if you could bring some sanity to the whole debate regarding ethical vs unethical hackers. Seems a tad silly for there to be comparisons of DDOSing a website vs. property damage. I’m sure insurance companies would love to insure someone’s property when it repairs itself!
Same with the comparisons of hacking vs. terrorism or hacking vs. murder. I understand that there are many people terrified of hackers nowadays, but the rhetoric has reached such extreme levels that good talent is being scared away from entering the field and being a security researcher, cyber warrior, pen tester, or any of the other valuable positions out there.
I’m sick and tired of these giant companies storing my credit card info online. I do NOT want it stored! If I want to make a purchase, I am perfectly happy to type in my credit card number. I do not need the so-called “convenience” of all of these giant companies and giant banks keeping that info online. But they are determined to keep that info online, and the IDIOTS are too freeking DUMB to even keep it confidential. And another thing: Was CLOUD software/data responsible for the Target data breech? I don’t trust the cloud at all. Its just a scam for giant companies like Google, Amazon and Microsoft to make more money by stealing jobs from IT guys.
Announcement today that Target is cutting 475 jobs at its HQ. Wonder if any of those jobs are related to the massive breach.
I’m sure this will work out well. The already understaffed IT department will be outsourced overseas.
Hi Brian,
If the the internal servers at target, that were hacked, had an AV running on them that had sandboxing functionality would it have been able to detect and prevent the malware from running?
I am thinking of MS System Center EndPoint Protection (aka ForeFront) where there is multiple layers of security built-in, in particular sandboxing, blacklisting, and behavior heuristics.
Thanks,
Probably not.
Anti virus software has two main components:
1. Signature based. This is sort of how your body deals with the Flu: it already saw a given strain last month, so when it sees it again this month, it fights it off. Have you noticed that you keep getting the Flu? That’s because you’re getting a new mutation.
Unlike the Flu (which is pretty effective at mutating), malware authors help along their malware by running it against copies of existing anti virus software and only releasing it when they know it won’t be detected.
2. Heuristic. This could perhaps detect the problem, maybe. Unfortunately, the way to defeat 1 still applies, and my impression is that most don’t run heuristics (it slows things down)
Brian et alia, Slightly off topic but related:
What would the outcome be if I called Target or Neiman Marcus, asked to speak w/ a DB programmer, and request that s/he delete all of my personal data stored in their DBs? …”I don’t know how.” … “I’m not allowed to do that.” … What if several million of us did? Why shouldn’t we have that right?
Should there be a national “opt-out” and “delete” available for consumers’ personal data that gets collected during a transaction or application (similiar to the phone numbers opt out)? Interesting idea, but I imagine that the lobbyists for those who sell aggregated consumer data would quash it. Still, I think consumers/customers should have this option.
Anybody know if there any efforts to do this? Cheers.
“We don’t allow customers to talk to those people.”
“We don’t allow our database engineers to have direct row level access.”
The latter should be the internal truth. You don’t want to deal with a company where raw row level writes are allowed.
It’s likely that a simple row operation would corrupt the database – there are probably a bunch of other tables with foreign key references.
Good points, all. But … if there is code that directs a DB to store information in various relational tables, then code can be written to delete this same data w/o any corruption …. unless Target has an “expand only” DB, which is stupid. Also, a raw row write (to dele) would not be necessary if a software engineer writes the correct code that sits outside of the raw DB tables. I agree that an “IT” or “MIS” person cannot and should not make these changes. But someone with a CS master’s or Ph.D….. no problemo. If it goes in, it can come out.
Re: the whole debate about POS operating systems and integrity and so on.
I think it should be obvious but because it apparently is not to a lot of people and businesses:
Devices integrated into any financial processing system should meet a VERY high standard of integrity. And part of that standard would mean NEVER running a general-purpose OS, even this “Windows Embedded” OS which is apparently just a slightly cut-down version of XP.
voksalna has a valid point about how Linux etc. can more easily be cut-down to a bare-bones system that only contains components necessary to task – this is hard to do with Windows.
However this is not the main issue. No matter what OS is being used in a POS terminal, it should be SEVERELY locked-down. And by that I mean:
1) NO writable local storage
2) NO ability to run non-authorized/non-signed executable code whatsoever
3) The entire OS should be “blueprinted” and a complete system/OS hash should be VERIFIED WITH HARDWARE ROM EVERY TIME THE TERMINAL BOOTS.
But instead, we have incompetent people designing systems in this way because it is *easier*.
It’s also rather amazing to me that the miscreants could ship 11GB of stolen data from one of their boxes off to points unknown without anyone in I.T. staff noticing.
Put yourself in the shoes of an IT person at one of these retailers (in particular, a discount retailer).
You’re making 60k a year working as a network guy for a director who was promoted up from a “business analysis” position. You have six different projects that want your time and you were up all night because its just you and one other guy “on-call”.
When do you have time to set up monitoring to make sure that data leaving the company is going to the right place?
Until the *business* side of the company sees some incentive to make this work correctly, this won’t change.
Speaking as a long-time software/systems designer/architect, with regards to this statement of yours:
“When do you have time to set up monitoring to make sure that data leaving the company is going to the right place?
Until the *business* side of the company sees some incentive to make this work correctly, this won’t change.”
…This is precisely because it is a systems/software design and architecture issue. If it were designed properly the easiest base/barebones installation would make this natural and integrated out of the box, intuitive to regular IT users. One reason I say this is because so many people interpret this as a ‘talent’ issue — and it IS hard to find the proper talent, but in the case of a large retail chain, I’d think it’s far less excusable, especially in a time when online learning has never been easier and accordingly doesn’t have to be expensive at all.
The fact that this is a niche that is not properly filled yet does not mean this is not a good solution. It means precisely that this is a niche that is not properly filled yet — and that does not have to be the case. Probably the best business case for someone who would be wanting to start a business like this is to approach it as a startup with the specific goal of becoming acquired by a larger, longer-in-business corporation that could make the buyer comfortable with the possibility that the company making the solution will not disappear overnight.
Can it be argued that among reasons people do reach so often for a Windows solution is because (a) they perceive it is easier to staff these positions, even though if the system was designed properly an employee with an IT background and documentation could be trained in 2-3 business days; (b) they fear if they go to something more secure and appropriate but non-Windows-based they may lose support and be totally helpless?
I made other comments regarding things other than just ‘make it linux’ throughout various posts — I think Philip Koenig may not have seen all of them, but I’m not sure you read any of them.
PS: Monitoring should be part of the system — not an ‘add-on’ or ‘afterthought’.
Apparently Target is a living company and dynamically changes its PoS displays and their content. The same way that a department store changes its physical window displays.
If a department store came to you and said that people were stealing from their window displays and you responded: “I can fix that: Just encase the display in concrete.” what do you expect their response to be?
They’ll laugh at you and then add you to the “never consult” list.
A department store needs to update their window display at least seasonally, and typically they’ll update weekly.
I’m under the impression that Target treats their PoS the same way. Such an update requirement is why you can’t concrete the window displays and it’s the same reason that you can’t prevent writes to the PoS.
Life would be much simpler if they didn’t have that requirement, but…
I was speaking with a POS terminal expert last week. He said this must have begun as a database attack on the server that distributes software updates to the POS terminals. His feeling was that those who authored the POS malware may not at all be related to those who hacked the Target databases and installed the malware for distribution. I thought was a rather interesting take on the situation.
So much misinformation.
Most Tier One retailers use a commercial POS system from IBM, NCR, or the like. These are Linux systems. Only small retailers and banks use Windows for POS/teller devices. POS devices with numeric displays obviously don’t surf the web. Using IBM as an example (used by Walmart, Kroger, and a host of others) The POS Terminal (Cash Register) uses bootp to install SUSE OS (with JAVA PI) from “Store Server” (also Linux). Pin pad (card swipe device) is always Linux, OS in flash that gets secure updates from cash register. The Store Server has an OS image and receives updates from Corporate headquarters IT Operations. Cash registers are on a private IP network that is routed only to the Store Server. Cracking the corporate IT Ops would affect much of the company: I rem a corporate push that disabled sales tax calculation for several States. It was reported that several hundred Target stores were compromised at once, indicating Corporate data center involvement. The authority for a POS update would rest with CIO direct reports. Windows POS also don’t surf; also would receive software updates en mass from Store Servers (WDS?) which would receive the updates from corporate IT Operations.
I wonder if Target corporate uses Oracle software and if the original access was Java exploit.
Only issue we’ve had re malware on XP was Java hack (Financial software required JVM). Of malware incidents: 20% of the malware tickets come from our (3% of total systems) Win8. Other 75% from the 25% that are Win7 machines.
Target’s POS terminals are definitely based on MS Windows.
Target uses store level imaging servers using Microsoft System Center Configuration Manager 2007. These servers get their updates from corporate before imaging the store registers. Target has used IBM machines as registers in the past and now they use NCR hardware. Both have run Windows Embedded, not Linux. The registers do have a local hard drive so that they can continue to operate if the Ethernet connection is disconnected or damaged. The registers are periodically imaged by booting up over the network to Windows PE after which the imaging process begins from the store level imaging server.
I’d suggest you do your research before before spreading so much misinformation. The hardware vendor does not mean the retailer is using the vendors preferred OS or suite of POS software.
http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=4000009407
Thx LT. So does the Target architecture use SQL server replication from corporate to the individual stores to distribute the POS software? I know CM 2012 would allow that but not sure about CM 2007. That case study is rather old, I suppose Target could be running CM 2012 now.
I couldn’t tell you. That article was current the last time I had knowledge of Targets workings. You could poke around thebreakroom.org and see if anyone’s mentioned any tech upgrades.