Mobile, Token, Tokenless, Vulnerability

How the Eurograbber attack stole 36 million euros

Check Point has revealed how a sophisticated malware attack was used to steal an estimated €36 million from over 30,000 customers of over 30 banks in Italy, Spain, Germany and Holland over summer this year.
The theft used malware to target the PCs and mobile devices of banking customers. The attack also took advantage of SMS messages used by banks as part of customers’ secure login and authentication process.

The attack worked by infecting victims’ PCs and mobiles with a modified version of the Zeus trojan. When victims attempted online bank transactions, the process was intercepted by the trojan.

Under the guise of upgrading the online banking software, victims were duped into giving additional information including their mobile phone number, infecting the mobile device. The mobile Trojan worked on both Blackberry and Android devices, giving attackers a wider reach.

With victims’ PCs and mobile devices compromised, the attackers could intercept and hijack all the victims’ banking transactions, including the key to completing the transaction: the bank’s SMS to the customer containing the ‘transaction authentication number’ (TAN). With the account number, password, and TAN, the attackers were able to stealthily transfer funds out of victims’ accounts while victims were left with the impression that their transaction had completed successfully.

The attack infected both corporate and private banking users, performing automatic transfers that varied from 500€ to 250,000€ each to accounts spread across Europe.

The attack involved 10 stages, starting with an initial infection by a modified version of Zeus:

  • Users’ PCs become infected by a modified Zeus trojan by accidentally visiting an infected web page, or following a link from a phishing email. This opened the door for the attack.
  • Users visit their bank’s webpage and log in to their account to make a transaction.
  • The modified Zeus trojan injects malicious code into the bank webpage, including a request for users to enter their mobile information, including its number and operating system.
  • This information is sent over the Internet to the attacker’s “drop zone” system where it is stored.
  • The attacker’s server sends an SMS message to the user’s mobile device that includes a link to the mobile device-targeting trojan, a version of Zitmo (Zeus in the mobile).
  • User are directed to click on a link in the SMS to ‘upgrade the security of the online banking system’. This installs the mobile Trojan on the mobile device and completes the system.
  • Now, every time the user logs into their bank account, the Trojan initiates an automatic transaction to transfer money out of the victim’s account using their real credentials.
  • To complete the transaction, an SMS message containing the TAN is sent to the victim’s mobile device, and the mobile Trojan delivers the TAN to the attacker’s server.
  • The customized Zeus Trojan Javascript running on the victim’s computer receives the TAN.
  • The Eurograbber attack is complete and the attackers transfer money out of a victim’s account.
News, Vulnerability

Sage reveals decode password processes

Sage reveals decode password processes

Summary: A Sage help desk document showed insight into the company’s help desk processes. These can be used by dishonest people to socially engineer their way into Sage systems

The link in question relates to a payroll help desk article entitled: “Real time password decode process.” It has since been placed behind a ‘permission wall’ but at the time of the Tweet, the linked document was in plain view from any browser. I saw it on an Android device.

I asked Sage to comment on the issue.

They said: “The link points to an article in our ‘ask sage’ knowledgebase that we provide to our supported customers, business partners and our internal support technicians. This is a dedicated service (not connected to any other systems or services) and contains no customer or business data.” So far so good.

However, the 11 step process describes in significant detail how to provide the requisite customer help, the methods Sage employs, how to identify that the call is bona fide, the name of the remote software support system they have deployed to retrieve the relevant files for decoding, links to other security related documents and talks about seven ‘common passwords types’ that Sage customers might use. See graphic below (password types are excluded):

sage password types

As Sage explained: “At no point in the article does it advise how to decode a password, just how to get the data to Sage for our internal Data Services team to decode.” Unfortunately, that’s not the point.

Among other things, the document clearly sets out how to ensure that the help desk technician is speaking to the right person within the customer organisation and if not then how to update the Sage internal contact systems.

A knowledge of help desk processes could be used to contact Sage customers with the purpose of obtaining passwords. All that would be required is a simple re-engineering of the password decode process to get the customer to reveal the appropriate information and at worst, to manually hand over sensitive files.

Such a re-engineering would not work in every case and of course a nefarious individual would need to know who is and is not a Sage customer. That’s not too difficult to acertain, given the fact Sage’s database of contacts can never be 100% up to date and the bones of the process for updating customer data along with the name of the system used was also in plain view.

This is not the first time that Sage has been caught out using less than optimum processes. In 2009, Jackson found that the now defunct SageLive was largely insecure:

Sage seems to be aware that security is important. They have a few pages about security that all say the right things. But in reality they fail on the most basic security measures. There’s no point in sticking your servers with Rackspace and shouting about how great the security is if the end-users password isn’t protected. After all, that’s all that is needed to get into a Sage Live account.

Defaults to “Remember me”
The default option on the Sage Live homepage is for it to remember your username and password. You can untick it if you like, but you’ll have to remember to untick it every time you log in. Other wise, all someone needs to do is fire up your computer, put in the url and click the Login button. Your password is already there!

Password shown in clear text
I really had to struggle to stop myself adding 3 exclamation marks to that sub-heading. Almost unbelievably, they show your password on-screen when you log-in – in plain text.

It’s sent to their central “passport” service using a GET rather than a POST – so your password is actually in the requested URL which is displayed in the status bar.

What was surprising is that Jackson’s SageLive post was live for nearly a week before Sage closed SageLive off ‘for maintenance.’ Immediately prior to the take down, I contacted Sage to ask whether they were aware of the issues and it was only then that SageLive was killed. On this occasion, it is my understanding that the support document link was live for anyone to see for a month. It was only after the Tweets started flowing that Sage acted.

Sage said: “This service is secure albeit we will be looking into why this particular article was visible to customers rather than being restricted to technicians.” Surely the broader questions must be:

  • How many other documents are there that can be easily accessed in this manner?
  • How does Sage manage the third party support relationship such that it knows customer security related requests are handled appropriately?
  • What is Sage doing to refine its decode or re-engineer its password processes to ones that are more secure?
  • What is Sage doing to ensure that customers setup passwords that have a good chance of remaining secure?

Sage reveals decode password processes | ZDNet via Sage reveals decode password processes | ZDNet.