This week, nationwide beauty products chain Sally Beauty disclosed that, for the second time in a year, it was investigating reports that hackers had broken into its networks and stolen customer credit card data. That investigation is ongoing, but I recently had an opportunity to interview a former Sally Beauty IT technician who provided a first-hand look at how the first breach in 2014 went down.
On March 14, 2014, KrebsOnSecurity broke the news that some 260,000 credit cards stolen from Sally Beauty stores had gone up for sale on Rescator[dot]cc, the same shop that first debuted cards stolen in the Home Depot and Target breaches. The company said thieves made off with just 25,000 customer cards. But the shop selling the cards listed each by the ZIP code of the Sally Beauty store from which the card data had been stolen, exactly like this same shop did with Home Depot and Target. An exhaustive analysis of the ZIP codes represented in the cards for sale on the fraud shop indicated that the hackers had hit virtually all 2,600 Sally Beauty locations nationwide.
The company never disclosed additional details about the breach itself or how it happened. But earlier this week I spoke with Blake Curlovic, until recently an application support analyst at Sally Beauty who was among the first to respond when virtual alarm bells starting going off last year about a possible intrusion. Curlovic said that at the time, Sally Beauty was running exactly one enterprise solution for security — Tripwire (full disclosure: Tripwire is an advertiser on this blog). Tripwire’s core product monitors key operating system and application files for any changes, which then triggers alerts.
Tripwire fired a warning when the intruders planted a new file on point-of-sale systems within Sally Beauty’s vast network of cash registers. The file was a program designed to steal card numbers as they were being swiped through the registers, and the attackers had named their malware after a legitimate program running on all Sally Beauty registers. They also used a utility called Timestomp to change the date and time stamp on their malware to match the legitimate file, but that apparently didn’t fool Tripwire.
According to Curlovic, the intruders gained access through a Citrix remote access portal set up for use by employees who needed access to company systems while on the road.
“The attackers somehow had login credentials of a district manager,” Curlovic said. “This guy was not exactly security savvy. When we got his laptop back in, we saw that it had his username and password taped to the front of it.”
Once inside the Sally Beauty corporate network, the attackers scanned and mapped out the entire thing, located all shared drives and scoured those for Visual Basic (VB) scripts. Network administrators in charge of managing thousands or tens of thousands of systems often will write VB scripts to automate certain tasks across all of those systems, and very often those scripts will contain usernames and passwords that can be quite useful to attackers.
Curlovic said the intruders located a VB script on Sally Beauty’s network that contained the username and password of a network administrator at the company.
“That allowed them to basically copy files to the cash registers,” he said. “They used a simple batch file loop, put in all the [cash] register Internet addresses they found while scanning the network, looped through there and copied [the malware] to all of the point-of-sale devices — roughly 6,000 of them. They were in the network for like a week prior to that planning the attack.”
HIDING IN PLAIN SIGHT
Curlovic said the malware planted on Sally Beauty’s network was identified (by some security vendors) as a variant of FrameworkPOS, a card-stealing program that exfiltrates data from the target’s network by transmitting it as domain name system (DNS) traffic.
DNS is the fundamental Internet technology that translates human-friendly domain names like example.com to numeric Internet addresses that are easier for computers to understand. All networks rely on DNS to help direct users as they surf online, but few organizations actually keep detailed logs or records of the DNS traffic traversing their networks — making it an ideal way to siphon data from a hacked network.
According to a writeup of FrameworkPOS by G Data, a security firm based in Germany, the card-stealing malware allows the attackers to dynamically configure the domain name to which the DNS traffic carrying the stolen card data will reach out. On top of that, the malware obfuscates the card data with a simple cipher so that it won’t be immediately obvious as card data to anyone who happens to be examining the DNS traffic.
But Curlovic said despite its clever data-stealing methods, other parts of the malware were clumsily written. In fact, he said, one component of the malware actually broke the Net Logon service on infected point-of-sale systems, limiting the ability of the Sally Beauty cash registers to communicate with the rest of the company’s internal network. Net Logon is a Microsoft Windows component that verifies network log on requests.
“I don’t know technically what went wrong with their software, but Net Logon wouldn’t start anymore after it was installed,” Curlovic said. “We couldn’t log in remotely with domain credentials and registers couldn’t communicate out through DNS effectively after that. It was pretty huge indicator that something was seriously wrong at that point.”
As for Sally Beauty’s standing claim that only 25,000 customer cards were taken, Curlovic said he’d be surprised if it was limited to the 260,000 originally reported by this blog.
“From what I saw in the information that the Secret Service had, 260,000 was probably on the low end,” he said. “For the period of time the software was out on the registers and running, it should have been closer to around a million, based on the number of credit transactions Sally Beauty had daily. But since the malware really wasn’t working very well, it was only capturing a portion of the cards that went through because of the formatting issue that broke the Net Logon service.
ANTI-AMERICAN MESSAGES
Curlovic said the malware used in the 2014 Sally Beauty breach communicated the stolen card data to several domains that were hosted in Ukraine, and that those domains mostly carried names that seemed to be crafted as verbal jabs at the United States.
One of the images linked to in the guts of malware used in the Home Depot breach.
Curlovic said he can’t recall exactly what the domains were, since he no longer has access to his notes at work, but that one of the domains was something close to “vx.anti-usa-proxy-war[dot]com.” Curlovic said he no longer has access to his notes because he was terminated from Sally Beauty about three weeks ago for reasons his former employer declined to share. He said he found out through a person at the local Denton, Texas unemployment office that someone in the company had accused him of accessing another employee’s computer without authorization. “That’s a pretty strange accusation to make, since the network administrator guys there all have access to everyone’s system on the network.”
In any case, the anti-US domains referenced by the card-stealing malware reinforce a suspicion long held by this author and other researchers: That the Sally Beauty breach was carried out by the same Russian and Ukrainian organized crime gang that stole more than 100 million credit and debit cards from both Home Depot and Target.
As I noted in a Sept. 7, 2014 story, the malware used in the Home Depot breach included several interesting text strings that chastised the United States for its role in foreign conflicts, particularly in Libya and Ukraine.
“Three of the links point to news, editorial articles and cartoons that accuse the United States of fomenting war and unrest in the name of Democracy in Ukraine, Syria, Egypt and Libya. One of the images shows four Molotov cocktails with the flags of those four nations on the bottles, next to a box of matches festooned with the American flag and match ready to strike. Another link leads to an image of the current armed conflict in Ukraine between Ukrainian forces and pro-Russian separatists.”
“This is interesting given what we know about Rescator, the individual principally responsible for running the store that is selling all of these stolen credit and debit cards. In the wake of the Target breach, I traced a long list of clues from Rescator’s various online identities back to a young programmer in Odessa, Ukraine. In his many personas, Rescator identified himself as a member of the Lampeduza cybercrime forum, and indeed this site is where he alerts customers about new batches of stolen cards.”
“As I discovered in my profile of Rescator, he and his crew seemed somewhat taken with the late despotic Libyan leader Muammar Gaddafi, although they prefer the phonetic spelling of his name. The Web site kaddafi[dot]hk was among four main carding shops run by Rescator’s crew (it has since been retired and merged with Rescator[dot]cc). The domain kaddafi[dot]me was set up to serve as an instant message Jabber server for cybercrooks, advertising its lack of logging and record keeping as a reason crooks should trust kaddafi[dot]me to handle their private online communications.”
“When I reached out to Rescator last December to obtain comment about my findings on his apparent role in the Target break-in, I received an instant message reply from the Jabber address “kaddafi@kaddafi[dot]me” (in that conversation, the person chatting with me from that address offered to pay me $10,000 if I did not run that story; I declined). But I also discovered that the kaddafi[dot]me domain was a blog of sorts that hosted some harsh and frankly chilling anti-American propaganda.”
Curlovic said the incident response team cleaning up the 2014 breach at Sally Beauty found another curious clue in the malware that attackers planted on the point-of-sale devices. They discovered that the intruders had created two versions of the card-stealing malware — one designed for use on 32-bit Windows systems and another created for use on 64-bit versions of Windows. The authors of the malware had taken the time to add an icon to the 32-bit version of the program that could be seen if anyone opened the directory where the malware was placed: The icon was little more than a black background with “Res” written in white lettering.
This kind of signing also was seen in the malware used in the Target intrusion, which contained the following text string: ““z:\Projects\Rescator\uploader\Debug\scheck.pdb”.
Blake’s identity utilized during his tenure at Sally was Blake Schmidt. That could be one reason they wouldn’t respond to your request for comment, you presented a name they do not have in their records
Was that non-savvy district manager terminated, and if not, why not? Curlovic may not be the shining hero in this mess, but it certainly seems that he’s become the fall guy to cover up the internal incompetence (if not malfeasance) within Sally’s management.
Credentials are commodity goods on the bad guy markets. Look at large Fred dump attained in October/November 2014 you can find many high stakes retailers username/passwords. A quick search around some hidden service sites will prove the ability to purchase current credentials for nearly any major (and some not so well known) companies around the globe. How corporations can ignore the need for multifaceted or adaptive or layered authentication approaches to ALL internet facing technologies is beyond irresponsible at this point. Not saying it fixes everything, but it sure does increase the simplicity of these initial vectors.
Wait a minute here, this Blake Curlovic who worked at Sally Beauty , then was fired for some unkown reason is now doing a online interview with Krebs. To me this sounds some what suspicions here.
Who’s to say that his not in on this breach trying to move the attention away from himself ?
@donaldtrump – this Blake guy is far from being attached to the attacking side of SALLY BEAUTYs recent second breach – think about it. That’s like saying MacGyver only knew how to get out of every situation bc he was part of the bad guys. Think outside of the box .. These data breaches are rather advanced brother ..
I don’t know the last name “Curlovic” sounds either Russian or Ukrainian to me. I’m only speculating here, but to me it’s very odd how a person can get fired from a company , which was breached twice.
Inside job, maybe something to think about here.
Um…there are MANY families in this country who retain last names from their countries of origin…for generations! How does his last name make him automatically a suspect? What is this, the Salem Witch Hunt?
That type of rationalization is like agreeing that the Japenese internment camps during WWII were somehow justified simply because people were of the same race as an axis country.
A slippery slope that anyone with a shred of morality and an ounce of intelligence should avoid. Then again, this is Donald Trump we are dealing with…
😉
Curlovic is more Serbian or Croatian surname.
>> I traced a long list of clues from
>> Rescator’s various online identities back
>> to a young programmer in [the] Ukraine.
Maybe you did, or maybe you traced it back to various zombie computers in the Ukraine run by someone who speaks the language but is not Ukrainian at all. My bet is that this is someone who left “Ukrainian” clues around to throw off those who want to know who he is — or who THEY are. The more clever they are the more likely it is that it is an organization behind it, and my vote goes to a hostile foreign government. What better way to practice attacks on the US or other countries than to make it look like one of many Internet crooks.
Why are POS terminals granted unfettered access to the broad internet? There is a small and finite set of addresses that they need to hit to clear transactions and talk back to home office. As they are without any form of physical security it would seem that locking them down communications wise would be a good idea and doing so only requires some simple layer 3 and 4 firewall filters. I can see how this would be a challenge in a franchise operation because the teenaged kid of the owners best friend who sets the local network up would probably not know how to do that right but Sally Beauty is not a franchise. A solution could be shipped in a box:
1. Here are your POS terminals and a magic preconfigured VPN terminator
2. Plug your POS terminals into a hub/switch
3. Plug the hub/switch into the terminator
4. Plug the terminator into your Comcast (or whatever) iNet link
5. Don’t plug anything else into any of these things.
6. Go have a beer to celebrate your IT prowess.
Now the gurus (or not) at corp headquarters can monitor and limit anything a POS terminal does because all it can do is talk over the VPN back to home office and it has no real iNet access.
Total cost for the hub and a cheap VPN terminator is about 500$. Across 2600 stores == 1.3M$ not counting the bulk discounts you’ll get. Lets say 2M$ when we factor in the hassel of configuration, testing, etc. That seems to be a lot cheaper than paying back the banks for your incompetence and incurring the reputational damage.
As for the DNS angle, super simple layer 4/7 filtering at the corp DNS end of things: “all UDP packets destined for port 53 are only allowed to get name resolution for FQDNs on a white list.” Done.
I’m far from an expert but none of this seems too hard and the 2M$ doesn’t seem like a lot for a company like Sally Beauty that does 2.6B$ annually and who has already been bruised.
As a side note: There doesn’t seem to be much of an incentive for businesses to proactively address cyber attacks. IT departments are always underfunded because they are just overhead and do not make any money. Top security expertise, and even just average expertise, is very expensive. Perhaps the way to encourage companies to rethink this is to strike fear in them with fines and possible criminal charges to the CIO for negligence.
Personally, I’m getting really bored with changing my CC numbers every 4 months.
Its actually easier than that. MPLS from the store to corp means no internet access. VPN tunnel over MPLS using the router at the store = added bonus security just in case. Simple ACL to block ANY requests from a POS to the internet. Configure the POS DNS servers to internal DNS servers. Block ALL outbound DNS except from the internal DNS servers.
To me, the bigger question is how in the hell did they pivot from the internal citrix connection over to the store / POS network so easily? This is just a plain failure to configure the network properly. In my environment, you can own our active directory, and it wont get you jack for getting to the POS environment. If they were securing access to the stores / POS’s just with domain credentials, they are a failure.
This is NOT difficult.
…and why are the POS systems on the same network as the corporate network
Anyone who is not segmenting their network and segregating corporate traffic from CDE traffic is just itching to end up on a krebs article. I am also curious as to the job function of the user who needed the citrix access in the first place.
Then, this is curious:
“The attackers somehow had login credentials of a district manager,” Curlovic said. “This guy was not exactly security savvy. When we got his laptop back in, we saw that it had his username and password taped to the front of it.”
Why in the hell would a district manager’s ACL be elevated enough to allow work on the same network as card data? Curlovic writes, very arrogantly it sounds, that the user isn’t “tech savvy” because the username and password taped to it. Great job, Mr. Gates, but why did a DM have access to those parts of the network?
Sounds like their IT department isn’t very “tech savvy” either, or maybe it’s just me. Either way, enjoy your fines.
The board, CEO, and CFO will gladly sacrifice the CIO for their dividends and bonuses. It’s the CEO and CFO that must sign on the dotted line to certify.
I do enjoy reading this blog, there are always lessons to be learned and these lessons can be put to work in practice. The reporting is excellent and I think that the continued follow-up stories are what most so-called journalists should be modeling their work after.
However, I am stunned by the volume of moronic comments that this site seems to attract. That whole mess about using hubs/switches and terminators to protect POS devices that sit bare on the internet?! Is that a joke? Also, the folks putting their tinfoil hats on about how the person who provided inside information as being the attacker. No, I’m sure it had nothing to do with the fact that the guy got canned, is upset and decided to do something useful with the information like share it so that (perhaps) the same thing won’t happen again and that it’s possible that Sally is covering up the scope of the breach.
I used to think that the bottom of the barrel regarding comments could be found on Youtube videos. Sadly, it appears that I was wrong.
It could be worse; check out the comments on ZDnet articles sometime.
All true, but if you want entertainment along with your security specific news this is a great read.
We all need a good laugh some days.
Well i’m no expert, but I don’t see whats so moronic about filtering outgoing connections through hardware firewalls, or using terminators at endpoints for encryption.
Do you think outgoing doesn’t need to be filtered at all? Are you stuck in that 90’s mentality?
Pretty crazy how they got into the network from some employee maintenance server (w/e that means) which had no security and was connected to the rest of the network. And is it true all companies have this practice? wow….
Hmmm.. Why was my suggestion a joke? Like I said, I’m far from an expert but I want to learn.
Yes, the ingress vector that they found was the root. Not much you can do about people taping their passwords to their laptop cover. Segregating a network as a previous poster suggested is a damn fine idea.
I’d like to know more about what occurred when Tripwire Enterprise detected the change. Did the staff just promote the change, did they ignore the TE status change, or did they take action on it?
This article is a great example of why multifactor auth should be used for all remote access.
This is also a great example of how “shared/stored” admin access should be unique per application/purpose and monitored. Alarm bells should have been going off whenever this admin account was used from any other source other than where the script normally ran from, or if it was used to access anywhere other than where the script was configured to have it connect. Tripwise Log Center can monitor and alert for this sort of behavior.
These are great questions Jason. I am also very interested to read about any insight about how the internal tools reacted. Sounds like they were misconfigured or something was missed.
Hello Jason,
To answer your question (and hopefully some others), the ram scraper was pushed out to the POS terminals Friday night/Saturday morning, which meant Tripwire did not report the majority of changes until it’s next scan cycle Sunday morning around 4am. The file change logs were reviewed by the Tripwire admin Monday morning (2/24/14) during normal business hours, and it was 2 or 3 in the afternoon that I was alerted to the potential problem. At this point, everything was funtioning on the POS terminals as Netlogon was still allowing login with cached credentials.
Myself and the people in charge of various IT departments spent the next 6 hours in the CIO’s office investigating the source of the data breach and taking precautionary measures.
1) The external IP’s/hosts that the malware was communicating with were null routed.
2) All external ftp communications were disabled.
3) AD passwords were changed.
I investigated the file Tripwire had flagged by loading it in a sandbox and stepping through it with an assembly debugger. Initially the malware didn’t appear to be DOING anything except for IPV6 DNS requests to the pre-configured host. This, plus the fact that the Netlogon service was broken led us to believe the malware was not working as intended and not exfiltrating data. TCP/UDP traffic was firewalled to and from external hosts from the POS terminals for everything but SSL connections to the credit card processors. DNS requests to external hosts, however, were not blocked. Had we known the malware was actually communicating via DNS requests at this point, DNS would have been blocked as well.
If you did not read it, the technical details of how the malware was able to exfiltrate data via DNS requests is here: https://blog.gdatasoftware.com/blog/article/new-frameworkpos-variant-exfiltrates-data-via-dns-requests.html
That night, I went home and wrote a Batch/VBScript to remove the malware and clean up the machines. I didn’t deploy these cleanup scripts at this point, as I hadn’t been authorized to do so.
On 2/25/14 Verizon forensic investigators were onsite and working with myself and others to further analyze the threat. It was determined over the next 3-4 days that the intruders had been on the network since 2/14/14 mapping the network and staging the attack.
They were able to gain access to the network via an external Citrix server used for employee maintenance. Since the intruders had the valid credentials of a District Manager, they were able to login, break out of the session to a task manager, and from there launch a command prompt. This Citrix server was not locked down properly, and not segmented from the rest of the network.
I’m guessing the credentials may have been obtained from malware, which is how they knew about the Citrix portal. Almost all companies have an external site for Employee Self Service, or webmail these days, so it’s not hard to obtain the url. Just search “Employee Self Service” on Google, the first result is Home Depot’s ess site.
After gaining access to the rest of the network, the intruders were able to obtain domain admin credentials, it was game over from there. There was evidence the intruders gained entry into the network after the domain admin passwords had been changed (2/24/14) due to cached credentials.
I was given the thumbs up to deploy the fix I put together to remove the malware on 2/27/14. This particular ram scraper came with a handy uninstall parameter, which did remove all traces of the malware, but did not fix the corrupted Netlogon service (more specifically, one of it’s dependencies, LanManWorkstation).
Unfortunately for customers card data had been exfiltrated for 6-7 days at this point. The reason a fix was not deployed on day-0 (technically day 3 I suppose) was due to the fact we HAD to have an external company come in and do analysis, take machine images, etc. for the sake of PCI compliance.
Compared to the amount of time the Target and Home Depot attacks had gone unnoticed, Sally’s was able to react very quickly due to some very intelligent people in their IT department. Had we not had Tripwire, or had the attackers been savvy enough to disable it, it may have been months before it was determined there was an issue with anything but the Netlogon service(s).
I would have loved to share this information and answer questions sooner, but did not for fear of losing my job. My personal opinion is that full disclosure of attacks like these from the companies that were victimized is the best approach. It helps educate other companies about the methods used by these attackers, so they can best protect their customers data. In hindsight, this attack, and others like it were stupidly simple, but could have been prevented had these companies known ahead of time how these intruders gain access, and what to look for.
If you were wondering, the reason I did lose my job is due to a vindictive ex-girlfriend who made it a point to get me fired “so she didn’t have to see my pathetic face.”, but that’s a story for another venue 🙂
If there are other questions that I did not address, please let me know.
Blake Curlovic
Thanks Blake – this is highly illuminating information and you should be commended for sharing it. We can all learn from this kind of post-breach analysis.
I just hope that Sally Beauty shares this sentiment!
Well way to ruin all the annoying conspiracy theorists in the comments section with your facts, timelines, and intelligent answer….sheesh
Why no two factor auth for critical systems?
Hi Blake. Thanks for the info. It was quite comprehensive.
The only part I didn’t understand was the PCI DSS requirement for a 3rd party to do a forensic scan prior to deploying a fix to stem the flow of card data. I’ve been out of PCI DSS for a while, but I don’t remember any such requirement for compliance, and frankly it’s a dumb idea to require that kind of action when cards are actively being compromised.
First order of business in any incident response is to stop the attack (with the caveat that you don’t take action that makes the situation worse, of course) unless there are compelling operational reasons not to. Like, for example, if it is non-critical data being exfiltrated. If that’s the case, you can make a decision in the moment that investigating the source of the attack is more important than stopping it, at least until the risk profile of the attack changes. But the PCI has always in the past been particularly protective of the confidential card data, and in my experience would want any organization to immediately take action to protect it.
Just curious if you could shed a bit of light on that particular decision.
Thanks for the info. Good stuff, especially the method for extraction of data. We are battling constantly the mad clickers that are handing their usernames and passwords to an email phishing attempt, so it looks like 2 factor for all internet facing apps is coming fast for us including Citrix. (Sorry about losing your job.)
Greg
Shady Shores, Tx
@Blake-thank you for detailing so much info to help others on the ground.
Great follow up. Thanks for sharing.
I wish the open source tripwire wasn’t deprecated. It feels as the world gets more hacked, Open source communities believe less and less in security for some mysterious reason.
As an IT guy myself, I have some questions that could make it more clear about what *really* happened:
1- As other people asked here: what TripWire did when they detected changes and the alarm bells? Because on the post, looks like they did nothing.
2- The ‘logon service’ was broken on the POS terminals, after the TripWire alarm, and they didn’t shutdown the network after the business hours to make a deeper analysis on it immediately?
3- The credentials written in some paper (or even computer file), doesn’t mean that hackers can read it. How actually the hackers got the credentials? And more, how they knew the address (IP or portal) to login with that credentials? How they knew Sally Beauty were using Citrix solution?
I see too much effort to blame eastern european hackers, but looks like you guys are missing the main point: maybe there are americans insiders on this companies.
Does Sally not have confidentiality agreements with its employees surviving termination?
I did not violate any non-disclosure agreement by disclosing this information, if that were a concern for me, I wouldn’t have shared any of this.
Morally, I don’t understand why a company would NOT want to disclose this information to the public. Especially when shareholders are involved. The company, the banks, the customers are the victims in these situations. Sure it may look bad that it happened to YOUR organization, but then again, it could happen to anybody. There is absolutely NOTHING to gain by hiding the truth as this only leads to a false sense of security and complacency. The best thing you can do for your organization is understand how attacks like this occur and do your best to prevent them.
Hmm…ethical AND single-niiice! I’m in IT also-you should totally call me-I would NEVER get you fired if we broke up!!* 😉
On a more serious note, though-thanks for the input. It helps a lot to know exactly how it went down.
*Nobody at May 8, 2015 9:49am: that moronic enough for ya? ;p
So reading between the lines. They had Tripwire which alerted to the changed files but clearly no one responded to the alert or if they did they did it poorly allowing the malware to propagate. Also have to wonder if your source has now violated any confidentiality agreements with his former employer.
Well according to Blakes post, they were on the network for 10 days before tripwire alerted them to anything. Interesting. Which happened on a sunday.
Their failure apparently was apparenlty connecting the employee service server to the rest of the network, and not filtering outgoing dns requests.
Which i find extremely Strange they weren’t limiting all outgoing requests from the get go. Why would it take a breach to get them to do that?? Especially since this POS malware has been known to communicate via dns for about a year now! Ya its nice to share information, but if its ignored its pretty useless. pretty suspect alright…
The kaddafi[dot]me jabber domain is vaguely associated with a Ukraine-routed registrant proxy service, whoisprotectservice.net
whoisprotectservice.net is running on the Haldex Ltd communications network, which has one listed network route for Ukraine.
The larger regional network running the registrant proxy service for kaddafi[dot]me, whoisprotectservice.net, has flagged-routes for Netherland and Ukraine:
http://bgp.he.net/dns/WhoisProtectService.net#_ipinfo
http://bgp.he.net/AS39572#_prefixes
Great write up Brian (as always), lots of interesting points made that will warrant further reading.
Fyg, the link to Tripwire’s website in the 3rd paragraph (within the word ‘Tripwire’) points to: http://krebsonsecurity.com/2015/05/deconstructing-the-2014-sally-beauty-breach/http://www.tripwire.com which 404’s.
This article of Brian’s and the additional information provided by Blake Curlovic here in the comments section continue to illustrate the horrendous lack of best practices being followed by many industries, but especially retail in particular. Unfortunately for those in banking, retail is still a sector where their customer’s private information is often at risk in bulk.
I find it interesting that PCI DSS compliance seemed to be an overriding concern during their initial breach investigation as opposed to immediately stemming the flow of data ex-filtration. To me this highlights how the main focus for most corporations seems to still be financial liability as opposed to actual security and education first and foremost. However, this is more detailed information than is typically released publicly about any security breach, so it also serves as a great opportunity to learn from Sally Beauty’s mistakes.
There are dozens of excellent security and risk management products and programs currently on the market that could have prevented this from happening. In fact, as some other posters have already pointed out, following some basic internal best practice procedures would have helped quite a bit to limit or thwart access to these POS systems altogether, without the need for a 3rd party product.
Please keep up the great work you’re doing Brian and kudos again to Blake Curlovic for sharing his valuable information with the rest of corporate America.
Please don’t be so insular and believe that it is only Corporate America that reads this blog. Brian has a very large following outside of the USA.
Happy mother’s day.
Of course, my apologies. Cheers.
Is snort useful in these cases?
@patti Depending on what you already have implemented in your network environment, there is likely to be an existing IDS/IPS technology available to you. However, if not, then Snort is certainly as good a starting point as any and would certainly be better than nothing at all. In addition to following best practices, the best defense is going to be a layered one so it’s critical to have a very clear and thorough understanding of your entire infrastructure’s data risk profile.
There are so many layers to this, but the big thing here is that the same company got hit not once but twice with a similar problem. I agree with ACCooler above who questioned why the company wasn’t limiting all outgoing requests. Seems like that’s Security 101.
–KB
Karen J. Bannan, commenting on behalf of IDG and FireEye.
Blake, you are indeed a pioneer. This is the first time I’ve ever seen anyone who was involved with one of these incidents first-hand comment on what actually happened. I put together a whole fiction story to analyze how these attacks happen because I couldn’t find anyone who would discuss what really happened in any of the other breaches we’ve read about here. Check out http://www.bullseyebreach.com. Yup, that’s a shameless plug.
You are dead-bang right on when you suggest we all benefit from open disclosure. I have a hunch you won’t have any trouble finding another job.
As for isolating POS systems – here’s how I would do it. I use open source tools to build firewalls and I would plunk one of those in every retail location. Put all the POS terminals behind it and set up a whitelist right in the ruleset. Log, notify, and drop any attempted traffic from the POS terminals outside the whitelist.
The revelation that the malware used disguised DNS traffic to exfiltrate credit card numbers is a bombshell. And it’s a great example about why sharing among the good guys is important. I never would have thought about that angle and now that I’m aware of it, I’ll push everyone I know to force branch sites to use a local caching DNS server – or if that’s not practical, only use internal DNS server (s). This sets up another layer of defense, forcing bad guys to find and compromise an internal DNS server.
– Greg
It sounds like this scenario would have been avoided if the company adhered to the PCI-DSS. It’s hard to be compliant all the time, we all get that. It calls for segmentation, testing that segmentation, justifying every single port and protocol inbound and outbound, and a number of other things including a complete paradigm shift and even calls for IT to think and work differently. All in all, the time of infection to the time of clean-up was way ahead of the industry average, so that says good things about the IT department.
I am not discrediting anything BK or Blake are stating, but one thing that stood out to me like a sore thumb, is the fact TripWire was set on a scan schedule. That, for me defeats the purpose of a product like TW. I administered TW for about a year with a company several years ago, and I had it configured to alert on almost EVERYTHING at least base off of TW built in policies and at near real time. While the amount of alerts/emails that are generated by doing is LARGE, when it comes to security, I think it is needed. Sounds like reaction time was faster than most org, but could it have been ever faster had the alerting been near real time?
DG
Blake and others – you might like this blog post:
http://www.infrasupport.com/how-can-organizations-avoid-sensational-data-breach-headlines/
– Greg
Testing
Go to Sally’s Website and click on My Account. All you need to access your Sally account online is Username and Password. How secure is that? The Hacker didn’t need to steal an employee’s accessing credentials, he could have just as easily picked anyone’s account. Once inside the Hacker could instruct their attack software to enter the internal POS system and steal card data as it was swiped.
Close the Authentication Front Door properly!
re: Mike – It’s not necessarily that simple. Logging into the website does not imply the ability to get inside the internal network and POS systems. I suppose if I were attacking ***stored*** credit card numbers, the website would be as good a place to start as any, although those numbers better be encrypted.
But attacking POS systems to steal credit card numbers as they’re being processed is a different challenge and the website may not even be relevant.
I can’t resist this plug – check out a new book titled, “Bullseye Breach,” for a realistic scenario for a POS system breakin. The book website is http://www.bullseyebreach.com.
– Greg Scott