Share this story

Update: About 24 hours after this report was published, BMC issued a statement that said in part: "BMC has confirmed that the password mentioned in the press is not a BMC-generated password. At this point, there is nothing to suggest that BMC BladeLogic or BMC Performance Assurance has a security flaw or was compromised as part of this attack."

Widely used management software running on Target's internal network may have given an important leg-up to attackers who compromised 40 million payment cards belonging to people who recently shopped at the retail giant, according to an article published Wednesday by KrebsonSecurity.

As journalist Brian Krebs reported two weeks ago, malware that infected Target's point-of-sale terminals used the account name "Best1_user" and the password "BackupU$r" to log in to a control server inside the Target network. The malware used the privileged insider access to temporarily stash payment card data siphoned out of the terminals used in checkout lines so it could then periodically be downloaded to a different service for permanent storage. In Wednesday's post, Krebs filled in some intriguing new details that suggest a poorly secured feature inside a widely used server management program may have played a role. Krebs explained:

That “Best1_user” account name seems an odd one for the attackers to have picked at random, but there is a better explanation: That username is the same one that gets installed with an IT management software suite called Performance Assurance for Microsoft Servers. This product, according to its maker — Houston, Texas based BMC Software — includes administrator-level user account called “Best1_user.”

This knowledge base article (PDF) published by BMC explains the Best1_user account is used by the software to do routine tasks. That article states that while the Best1_user account is essentially a “system” or “administrator” level account on the host machine, customers shouldn’t concern themselves with this account because “it is not a member of any group (not even the ‘users’ group) and therefore can’t be used to login to the system.”

“The only privilege that the account is granted is the ability to run as a batch job,” the document states, indicating that it could be used to run programs if invoked from a command prompt.

Krebs went on to quote a part of the BMC article that said:

Perform Technical Support does not have the password to this account and this password has not been released by Perform Development. Knowing the password to the account should not be important as you cannot log into the machine using this account. The password is known internally and used internally by the Perform agent to assume the identity of the “Best1_user” account.

Krebs asked BMC if "BackupU$r" is the password that controls access to the "Best1_user" account. Company representatives have yet to provide an answer.

Krebs also cited a report that Dell SecureWorks privately distributed to clients earlier this week. "The Best1_user account appears to be associated with the Performance Assurance component of BMC's Software's Patrol product," Dell SecureWorks researchers wrote. "According to BMC's documentation, this account is normally restricted, but the attackers may have usurped control to facilitate lateral movement within the network."

Krebs also repeated what Ars noted two weeks ago—that there's a compelling case to be made that, just like the co-conspirators of now-convicted Albert Gonzalez, the people who hacked Target may have first penetrated the network by mounting a SQL injection attack on Target's website. Wednesday's report from Krebs has many more details, including a recent dump of more than 2 million compromised payment cards, all of them used at Target between November 27 and December 15.

Wow, a software vendor installs a system-level account with full privileges and only secures it with the password 'BackupU$r'? Talk about pathetic security. Any decent hacker would be able to get their hands on the encrypted passwords on a server, then it would take all of perhaps 5 minutes with a password cracking program to figure out such a simple password.

So if I understand this correctly, this doesn't necessarily have to do with installing the malware on the PoS terminals, but instead the malware on the terminals could use the best1 username and password to run batch files on a control server presumably allowing it to copy the data from the terminals to the servers where it was stored temporarily before being retrieved?

Or could it have been the initial weakpoint allowing basically full access to a target server that they could then use to infect all the PoS terminals?

Although from the sounds of it it couldn't have been used to log in, just run commands from someone else who was logged in?

Not being able to use an account to log in at a terminal doesn't prevent it from making system() calls and basically doing whatever you want. It looks like they used a SQL injection attack to get on the system, and then a privilege escalation attack against the management software to give themselves root.

Not being able to use an account to log in at a terminal doesn't prevent it from making system() calls and basically doing whatever you want. It looks like they used a SQL injection attack to get on the system, and then a privilege escalation attack against the management software to give themselves root.

I'm not clear on what BMC's software does, but it would be a hoot if they actually used the agent to somehow "batch install" their malware. I'm assuming the BMC agent is running on all the POS terminals...

Amazing. They actually regarded patchwork that prevents login on the maintenance account the solution. It sure tightens access somewhat but provides no real security. So from the PDF, it is somewhat like a loginless maintenance account on UNIX. Except that one (anyone?) can run batch programs under this account if one knows its password.

Krebs also repeated what Ars noted two weeks ago—that there's a compelling case to be made that, just like the co-conspirators of now-convicted Albert Gonzalez, the people who hacked Target may have first penetrated the network by mounting a SQL injection attack on Target's website.

Really? -- Kyle.

edit: So people aren't incensed that 40 million payment cards may have been compromised because of a 15+ year old security weakness? ok, I stand corrected, it's just me then.

Nobody said that and your two word comment did nothing to provide any context to the text you quoted.

Wow, a software vendor installs a system-level account with full privileges and only secures it with the password 'BackupU$r'? Talk about pathetic security. Any decent hacker would be able to get their hands on the encrypted passwords on a server, then it would take all of perhaps 5 minutes with a password cracking program to figure out such a simple password.

I'm just not surprised by this in the Windows world. To many apps out there that need some admin level account in order to function. This is basic stuff in the unix world.

You have to wonder how many of these software packages have back doors in them just waiting for someone to find it.

Lots, I expect. I may be thinking about this somewhat naively, but it seems like a common problem -- "When authentication is done via username/password, how do you allow automated tools to get access?" They must necessarily know the secret password.

If you have account/password combo be user-configurable, then you have to have the passwords hanging out in some sort of configuration file somewhere. They don't necessarily have to be in plaintext, but if they're encrypted in the config file, then whichever tools are going to use the password(s) must be able to decrypt them. That doesn't gain you a whole lot of ground -- as a hacker it's not going to be too difficult to extract the decryption details from one of your little automated tools.

The "obvious" alternative is to have a non-configurable account/password that all of your tools know. It's simpler than mucking with hiding passwords in config files, and isn't all that different in terms of actual security. In the former scenario the hackers have to extract the encryption key from your tool, and in this scenario they have to extract the password. One may be simpler to accomplish than the other, but you have to assume that either could be achieved.

As I understand it, the "better" alternative comes down to, "Don't use username/passwords" for authentication. Use Public Key Infrastructure (PKI) instead, and let the OS handle the task of securing keys.

I'm curious to hear what someone with more security experience than me thinks of this summary. If I'm overlooking something, then I expect that I'm not alone, but it'd be good to know about. =)

Wow, a software vendor installs a system-level account with full privileges and only secures it with the password 'BackupU$r'? Talk about pathetic security. Any decent hacker would be able to get their hands on the encrypted passwords on a server, then it would take all of perhaps 5 minutes with a password cracking program to figure out such a simple password.

Well less than 5 minutes...

I install and support system management software - not BMC! - and my installer forces password creation....even, and especially, for accounts that are 'set and forget' service accounts. We also recommend the complexity be whatever the client policy requires OR BETTER.

And while I'd like to believe this is isolated, I suspect there are tons of similar stupidity going on.

I'm no expert but I think that the PCI Security Standards have a lot of loopholes grandfathered in - and even without that, I don't know that this is the kind of thing that would be caught by an audit anyway.

If you read the support document Krebs linked to, calling it a back door is a bit of a stretch.

It's an account used by the application to send MAPI email and "Investgate script actions". It does not belong to a group and has no expanded privileges by design, as it is a security feature actually used to reduce privileges when running those features.

They actually repeat several times in the document to not enable the feature if you are not going to use it.

Given that the malware also impersonated other processes of software made by the same company, it stands to reason that the user name is meant to camouflage the malware's actions.

Wow, a software vendor installs a system-level account with full privileges and only secures it with the password 'BackupU$r'? Talk about pathetic security. Any decent hacker would be able to get their hands on the encrypted passwords on a server, then it would take all of perhaps 5 minutes with a password cracking program to figure out such a simple password.

The software does nothing of the sort, according to the document linked by Krebs. In my opinion, he quoted it selectively to inflate the drama of the article.

What baffles me is that Target would have a very complex network at corporate -- actually many LANs and WANs. Once one server was somehow compromised, how on earth would the attacker know where to go from there? Had help?

The "obvious" alternative is to have a non-configurable account/password that all of your tools know. It's simpler than mucking with hiding passwords in config files, and isn't all that different in terms of actual security. In the former scenario the hackers have to extract the encryption key from your tool, and in this scenario they have to extract the password. One may be simpler to accomplish than the other, but you have to assume that either could be achieved.

As I understand it, the "better" alternative comes down to, "Don't use username/passwords" for authentication. Use Public Key Infrastructure (PKI) instead, and let the OS handle the task of securing keys.

I'm curious to hear what someone with more security experience than me thinks of this summary. If I'm overlooking something, then I expect that I'm not alone, but it'd be good to know about. =)

Good idea. That's exactly what smart cards are supposed to do - log you on with proof-of-possession of a private key.

However, changing up years of software stack that relies on password-based auth is hard. I don't mean that as a cop out, but it's a big-ass problem. Especially when you have (potentially) decades of legacy code that only knows how to deal with symmetric-secrets.

Luckily, this is a well-known problem in the industry, and smart people are working on it. I'm hoping something good comes from the FIDO alliance: http://fidoalliance.org/

Wow, a software vendor installs a system-level account with full privileges and only secures it with the password 'BackupU$r'? Talk about pathetic security. Any decent hacker would be able to get their hands on the encrypted passwords on a server, then it would take all of perhaps 5 minutes with a password cracking program to figure out such a simple password.

What did you expect from a Microshaft system?

For everyone that got Microshaft systems, please take the boxes/contracts/PDFs/whatever you got that tells your rights and obligations and find the part that they offer no warranty and say their system should not be used in mission critical or secure applications.

Maybe one or two people will open their eyes after this.

Why people continue using systems that offer such disclaimers and dare complain about when bad things happen is beyond me. If target used linux/BSD/VMS it wouldn't be in the bad news now.

*bashes Microsoft for including a CYA clause in their EULA**unironically suggests using Linux instead*

Spoiler alert: basically every Linux distro includes exactly the same clause.

Here's Red Hat's:

Quote:

3. Limited Warranty. Except as specifically stated in this Section 3, a separate agreement with Red Hat, or a license for a particular component, to the maximum extent permitted under applicable law, the Programs and the components are provided and licensed "as is" without warranty of any kind, expressed or implied, including the implied warranties of merchantability, non-infringement or fitness for a particular purpose. Red Hat warrants that the media on which the Programs and the components are provided will be free from defects in materials and manufacture under normal use for a period of 30 days from the date of delivery to you. Neither Red Hat nor its affiliates warrants that the functions contained in the Programs will meet your requirements or that the operation of the Programs will be entirely error free, appear or perform precisely as described in the accompanying documentation, or comply with regulatory requirements. This warranty extends only to the party that purchases subscription services for the Programs from Red Hat and/or its affiliates or a Red Hat authorized distributor.

I'd just love to hear about where Microsoft claims you shouldn't use their products for "mission critical applications", though. Find me that PDF!

It looks like they could have just used a documented innocuous account name to cloak their presence. So that anyone who looks at the process table will ignore their activities.Like running your unix APT as user syslog.

It looks like they could have just used a documented innocuous account name to cloak their presence. So that anyone who looks at the process table will ignore their activities.Like running your unix APT as user syslog.

They could do this even on systems where BMC has no presence.

I have two scary conclusions after knowing how the attack was carried out:

First, it doesn't matter if you used chip + pin or swiped the card, so the chip + pin is obsolete at this point.

If the crackers have gone slower, they could have done it for years undetected.

The third conclusion, or addendum, is to pay cash because trusting sysadmins in the retail business is too much. That can only be corroborated by their staunch defense of the security of such systems when reality says otherwise.

Not to derail this back on topic, but if the terminals were domain joined, it is trivial to use Group Policy to give any account more access. Log in as service, log in locally or log in via Remote Desktop; it is all there and hard to catch the change if you do not have a very tight change control system in place.

'You may know yourself that Microsoft does not produce programs that it warrants as "mission critical", as any EULA clearly attests to that fact. You can tinker and try and prove all this to yourself.'

I'm no expert but I think that the PCI Security Standards have a lot of loopholes grandfathered in - and even without that, I don't know that this is the kind of thing that would be caught by an audit anyway.

Wow, a software vendor installs a system-level account with full privileges and only secures it with the password 'BackupU$r'? Talk about pathetic security. Any decent hacker would be able to get their hands on the encrypted passwords on a server, then it would take all of perhaps 5 minutes with a password cracking program to figure out such a simple password.

I'm just not surprised by this in the Windows world. To many apps out there that need some admin level account in order to function. This is basic stuff in the unix world.

This really has nothing whatsoever to do with Windows vs. unix. It's just as easy for a skilled hacker to get the hashed passwords from a unix system as it is a Windows system. Then you just unleash a password cracking program like John the Ripper on the hashes. A unix password as weak as this would be cracked just as quickly as a Windows password this weak.

Wow you might want to consider working for our governor here in Georgia. He certainly needs folks to help deflect blame for this poor handling of the snow storm over here by misdirecting people and blaming other agencies. I'm no fan of Microsoft but i would love to see a Eula for windows server saying don't use this for mission critical.