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?