The US Department of Justice has released a bulletin describing a Former Fannie Mae Contractor Employee Indicted For Computer Intrusion:

According to the one count indictment and affidavit in support of a criminal complaint previously filed on January 6, 2009, Makwana was a contractor employee, working at Fannie Mae’s Urbana, Maryland facility from 2006 to October 24, 2008. He was a computer programer proficient in a computer language designed to operate Fannie Mae’s 4,000 computer servers, and was part of a group that created computer scripts for Fannie Mae. As such, Makwana had access to Fannie Mae’s servers throughout the United States.

It is the ultimate insider attack. The accused was operating with system level privileges on all servers in the company. He was terminated two weeks after he pushed a script to Unix servers without prior approval. Fannie Mae apparently allowed him to keep writing scripts, but he was no longer allowed to push them.

The indictment and affidavit allege that Makwana was terminated on October 24, 2008, and advised to turn in all of his Fannie Mae equipment, including his laptop. According to the affidavit, on October 29, 2008, a Fannie Mae senior engineer discovered a malicious script embedded in a routine program. The legitimate and malicious script were removed that day. The engineer and his supervisors ordered a standard lock down of all access to the servers. The indictment alleges that Makwana entered the malicious code on October 24, 2008, and that it was set to execute on January 31, 2009. The malicious code was designed to propagate throughout the Fannie Mae network of computers and destroy all data.

Had the script executed a day or so after termination, Fannie Mae would have been devastated. Instead, the timer was set for a month, which gave other engineers enough time to find the bomb and disable it.

Makwana’s script was set to wipe out all passwords, replace all data with zeros, disable high-availability software including remote power controls, and then shut everything down. Anyone that attempted to login would see the message “Server Graveyard”. In other words, his aim was to reduce 4,000 servers to blank hardware and require on-site visits to rebuild them. Fannie Mae suggested that recovery from this level of incident would have taken at least a week.

The United States District Court of Maryland has the criminal complaint, which cites Title 18, United States Code, Section 1030(a)(5). I found it at inman.com.

Despite MAKWANA’s termination, MAKWANA’s computer access was not immediately terminated. Access to ABC’s computers for contractor’s employees was controlled by the ABC procurement department, which department did not terminate his MAKWANA’s computer access until late in the evening on October 24,2008.

[…]

The malicious script was at the bottom of the legitimate script, separated by approximately one page of blank lines, apparently in an effort to hide the malicious script within a legitimate script. It was only by chance that SK scrolled down to the bottom of the legitimate script to discover the malicious script. The legitimate and malicious script were removed and placed into an archive file on October 29,2008.

[…]

SK immediately looked at the logs from October 24, 2008, the date of the creation of the malicious script, and noticed MAKWANA’s username and files accessing the dsysadmOl server, on which the malicious script was created.

The compliant continues with a description of how Makwana used SSH from his laptop at his desk to login at 2:53pm on his day of termination, just two hours before he turned it in, to access a development server. Premeditation to the attack is suggested in the complaint as a few days before he was terminated he emailed his relatives in India and told them not to travel to the US.

Although the Microsoft Bluetooth Stack OBEX Directory Traversal reported by Alberto Tablado is interesting, he puts a heavy emphasis on the requirement for pairing before the exploit can work:

There exists a Directory Traversal vulnerability in the OBEX FTP Service in Microsoft Bluetooth Stack implemented in Windows Mobile 5.0 & 6 devices. A remote attacker (who previously owned authentication and authorization rights) can use tools like ObexFTP to traverse to parent directories out of the default Bluetooth shared folder. This means the attacker can browse folders located on a lower level, download files contained in those folders as well as upload files to those folders.

The only requirement is that the attacker must have authentication and authorization privileges over the OBEX FTP service. Pairing up with the remote Windows Mobile device should be enough to get it. In case the attacker succeeded in getting the proper privileges, further actions will be transparent to the user.

That is more than a minor detail. What are the chances you would pair with a device you do not own, know or trust? I mean pairing with an unknown device is giving that device the key to your data…so would you give your key to an unknown device? I have done a fair bit of analysis of this and it’s non-trivial. In other words, the likelihood of the exploit working should be low because establishing a bluetooth pairing with unknown devices tends to be low.

You will not get an argument against end-to-end encryption, especially since I’ve been working on exactly such a solution since 2004. I think it is great that everyone seems to be headed this direction finally. A CFO once told me he would not approve the dollars for encryption until he saw it become mainstream news…well, we have arrived. With that in the pocket there is another element in the Heartland story that needs more discussion.

Would a well-configured monitoring/SIEM solution have helped prevent the heartland breach?

The clue to finding the malware was a set of orphaned .tmp files. In other words, an unknown/hidden application in slack space dumped a few files to the OS that were not recognized. StorefrontBacktalk has details:

While the first team was working, Heartland had a second forensic team brought in to check the entire system. “That first firm had a very specific scoping of their assignment. The second firm was working in parallel on the rest of that processing.”

That second team “was nearing conclusion” and was about to make the same assessment the first team did: clean bill of health. But one of the last things that external, qualified risk assessor did was to try and match various temp files with their associated application. When some orphans—.tmp files that couldn’t be matched to any application or the OS—were turned over to Heartland’s internal IT group, they also couldn’t explain them, saying that it was “not in a format we use,” Baldwin said. More investigation ultimately concluded that those temp files were the byproduct of malware, and more searching eventually located the files in the unallocated portions of server disk drives.

Had the system been alerting on tmp files, the malware would have been identified earlier. That’s a great way to catch malware, since you can guarantee that the attackers will have a hard time eliminating tmp files being written to spaces they do not anticipate. In other words, they will have to program far more cleanly to avoid a dirty software detector such as SIEM.

Fun, no?