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
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-5395
Published: 2014-11-21
Multiple cross-site request forgery (CSRF) vulnerabilities in Huawei HiLink E3276 and E3236 TCPU before V200R002B470D13SP00C00 and WebUI before V100R007B100D03SP01C03, E5180s-22 before 21.270.21.00.00, and E586Bs-2 before 21.322.10.00.889 allow remote attackers to hijack the authentication of users ...

CVE-2014-7137
Published: 2014-11-21
Multiple SQL injection vulnerabilities in Dolibarr ERP/CRM before 3.6.1 allow remote authenticated users to execute arbitrary SQL commands via the (1) contactid parameter in an addcontact action, (2) ligne parameter in a swapstatut action, or (3) project_ref parameter to projet/tasks/contact.php; (4...

CVE-2014-7871
Published: 2014-11-21
SQL injection vulnerability in Open-Xchange (OX) AppSuite before 7.4.2-rev36 and 7.6.x before 7.6.0-rev23 allows remote authenticated users to execute arbitrary SQL commands via a crafted jslob API call.

CVE-2014-8090
Published: 2014-11-21
The REXML parser in Ruby 1.9.x before 1.9.3 patchlevel 551, 2.0.x before 2.0.0 patchlevel 598, and 2.1.x before 2.1.5 allows remote attackers to cause a denial of service (CPU and memory consumption) a crafted XML document containing an empty string in an entity that is used in a large number of nes...

CVE-2014-8469
Published: 2014-11-21
Cross-site scripting (XSS) vulnerability in Guests/Boots in AdminCP in Moxi9 PHPFox before 4 Beta allows remote attackers to inject arbitrary web script or HTML via the User-Agent header.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?