Risk
12/6/2012
02:35 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

'Project Mayhem' Hacks Accounting Software

No exploit required for defrauding Microsoft and other accounting systems, researchers at Black Hat Abu Dhabi reveal

Researchers today unleashed proof-of-concept code that would allow an attacker to basically write himself a check from the victim organization's account.

The Python-based tool is just one example of the type of advanced financial fraud that could be perpetrated against accounting applications and databases, according to SecureState researchers, who at Black Hat Abu Dhabi demonstrated their tool and findings on threats to accounting software. They focused their efforts on Microsoft's Dynamics Great Plains application, but they say the same types of attacks could also be aimed at other accounting packages.

No vulnerabilities were discovered or exploited in the Microsoft product, either: The attacks demonstrate how cybercriminals or malicious insiders could easily have their way with an organization's financial systems and do some serious harm. "We're not exposing any kind of vulnerabilities in Microsoft Dynamics Great Plains. What makes this interesting is that it basically uses the technique we see a lot in malware that does injection and hooking," says Tom Eston, manager of SecureState's penetration testing team, one of the researchers behind the so-called Project Mayhem research.

The Mayhem script detects that the Microsoft software is running, and creates a backdoor for the attacker to remotely make SQL queries and commit all types of financial fraud. "It doesn't even need to install a traditional piece of [Trojan] backdoor malware like" most financial fraud malware does today, says Eston, who demo'ed the tool today with research partner Brett Kimmell, manager of the risk management group at SecureState.

"We compare it with a banking Trojan that hijacks ACH and wire transfers without the user's knowledge, but this time we're looking at the accounting system instead of the online banking session," Eston says.

Microsoft's accounting program isn't the only potential victim here. "You could take this same concept and apply it to MAS 90, Peachtree, Oracle, and even SAP," Eston says.

The research is a rare drill-down into the risks of attackers and insiders performing damaging financial fraud via the victim's own financial systems, but it's not the first look at ERP application security. Two years ago at Black Hat Europe, researchers at Onapsis demonstrated how an attacker could inject rootkits and backdoors into an SAP ERP system to intercept automated payments, for example.

"As we always pointed out, this is a common problem among all ERP systems -- traditional security controls have become obsolete to protect against the modern cyberthreats that affect these business-critical platforms," says Mariano Nunez, CEO of Onapsis. "From Onapsis, we have been raising awareness on how SAP and Oracle ERPs, such as JD Edwards and Siebel, are also prone to these attacks and how companies can protect themselves."

[Black Hat Europe researcher demonstrates techniques for inserting 'backdoors' into popular enterprise resource planning apps that aren't properly secured. See SAP, Other ERP Applications At Risk Of Targeted Attacks.]

Project Mayhem goes the heart of financial best practices. Even with all of the defense-in-depth best practices, this type of attack could succeed, the researchers say. "All it takes is for one of those controls to fail, and the accounting system can be compromised with fraud," Eston says. "This highlights that back-end controls in accounting systems ... and what the controller or CFO is doing in account reconciliation is even more important that just trying to stop an attacker from getting the machine and compromising credentials."

Unlike banking Trojans, the script used in Mayhem doesn't require admin rights or downloading new malware. It's basically old-school hacking: "It just opens up that channel into database queries to make modifications," he says.

An attacker would need to have some accounting software knowledge to pull off these attacks, however, such as knowing server naming conventions and database tables for specific software systems running in the targeted organization.

Eston and Kimmell say their project required a team effort of various expertise sets: Eston is a penetration tester, Kimmell, a former CFO familiar with the Microsoft software, and SecureState colleague and coder Spencer McIntyre.

"Anybody who gets hold of this code would need somebody with an accounting background and who knows GP Dynamics," Kimmell says.

"The PoC we've put together adds a vendor record to GP" so that the attacker could pay himself from the victim organization's accounts payable, Eston says. "It just adds their record as a 'vendor' ... We're hoping this summer to have a second, more powerful version of the PoC."

An attacker could employ this PoC either via malware or a phishing attack to steal user credentials. Or he could also directly attack the database server, the researchers say.

What can organizations do today to protect themselves since there's no "patch?"

Next Page: Protecting your accounting system Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
cpattersonv1
50%
50%
cpattersonv1,
User Rank: Apprentice
12/7/2012 | 6:21:17 PM
re: 'Project Mayhem' Hacks Accounting Software
MS should probably use SSL between the client machines and the database and lock down the database so only clients with the appropriate credentials (IP addresses, SSL Keys, and login credentials) would be allowed to make database queries and injections. They might also look at splitting up the database logins, so you have one login for queries and one login for inserts. The tables per client should be named according to the actual company so they're not standardized within GP across the board. Also the database itself needs to be encrypted (I'm not familiar with the GP system myself) so it couldn't be updated somewhere else and replaced (after the end of business). (One of the things that used to be sort of a standard practice in the 90s was make a copy, hack it offsite, then return it to the system at a later date... so there is no trail.) They might also limit access to the terminal that is authorized to only being allow to make transactions during business hours (like banker's hours for the machine itself).

There are probably hundreds of ways to secure this particular issue. Also from an IT standpoint you would require that all communications to the accounting database come from an accounting computer on the network subnet.

It sounds more like a fail on the IT department's part (or something they wouldn't consider as a possibility).

The problem is more of a human issue. The IT department thinks to themselves that the company only hires qualified people who don't have bad backgrounds. The admins are busy (probably under staffed or better yet outsourced) so they either aren't familiar with the system themselves, don't need to be familiar with the system, or don't have the time to think about all of the possible injections. The idea someone could gain access to the network, have a machine with the necessary tools to actually perform an attack, not have that attack be logged, and do this consistently is a little far-fetched?

Stepping back I see that it makes a great story, but it's just a company trying to get creative with ways of saying "There is no need for our services, but we can prove to you that you need us because we can show you a world of possibilities that are highly improbable, but capable given an enormous amount of funding, interest, and time in the realm of distant possibility."

Another thing, is the people who would have this skill set, the ability to pull off the job, and the ability to collectively network with other individuals and collaborate on something this illegal probably would only ever do this just to say it could be done as a proof of concept. It's unlikely these highly skilled professionals would be unemployed and outspoken enough to say to their other unemployed colleague, "I have a way we could make some money." A little too Hollywood for the real world.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0485
Published: 2014-09-02
S3QL 1.18.1 and earlier uses the pickle Python module unsafely, which allows remote attackers to execute arbitrary code via a crafted serialized object in (1) common.py or (2) local.py in backends/.

CVE-2014-3861
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to inject arbitrary web script or HTML via a crafted reference element within a nonXMLBody element.

CVE-2014-3862
Published: 2014-09-02
CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to discover potentially sensitive URLs via a crafted reference element that triggers creation of an IMG element with an arbitrary URL in its SRC attribute, leading to information disclosure in a Referer log.

CVE-2014-5076
Published: 2014-09-02
The La Banque Postale application before 3.2.6 for Android does not prevent the launching of an activity by a component of another application, which allows attackers to obtain sensitive cached banking information via crafted intents, as demonstrated by the drozer framework.

CVE-2014-5136
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in Innovative Interfaces Sierra Library Services Platform 1.2_3 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.