Heartland Payment Systems said Tuesday that hackers had compromised its computer systems and gained access to customer information related to the roughly 100 million transactions the company processes each month. Although the number of customer records that was compromised hasn't been disclosed yet, this breach is likely to give TJX, who exposed more than 45 million customer credit card numbers to hackers beginning in 2005, a run for its money as the largest breach of credit card data to-date.

The breach, the early signs of which Visa and Mastercard may have identified back in late 2008, was perpetrated using what investigators describe as highly sophiscated malware that specifically targeted Heartland. Since the means by which cyber criminals mounted this attack remain to be seen, it will be interesting to find out if the person or persons responsible were insiders, specifically out to get Heartland, or whether they were working as part of a larger effort.

Although there's no evidence yet this was an inside job, insider threats always pose a serious risk. Never has this risk been more acute than under the current economic conditions. When large groups of employees are fearful about layoffs and other hardships, employers often need to take stock of how they might be exposed if an employee with an axe to grind decided to leave something behind when they leave the company.

A few months ago, the Fortify Security Research Group (SRG) developed a custom rulepack specifically designed to help code auditors look for insider threats in Java web applications. The rulepack is available through Fortify Exchange, which is part of the Premium Content area of the Fortify Customer Portal. Currently, we're testing the rulepack with a group of interested customers to fine tune its detection capabilities and target a broader range of potential attack vectors.

Technorati Tags: insider threat breach credit card data

In FreeBSD and UNIX, characters such as < and > are allowed in file names. As these characters are the main ingredients for a straight forward cross-site scripting (XSS) attack, it is not surprising that filenames can be used to exploit XSS vulnerabilities. An internal audit recently uncovered a vulnerability in the online photo album application Gallery, which allowed to use a specially crafted filename to exploit a XSS vulnerability. For example, uploading a picture with the name <script>alert('hi')</script>somefile.gif could exploit this vulnerability.

But the danger goes even further. Files can be archived in multiple ways, including ZIP, RAR, and other formats and some languages, such as PHP, provide functionality to display the contents of these archives. Therefore, even if it is impossible to upload a file with a malicious name directly, it may still be possible to upload an archive containing files, which in turn may serve as attack vectors. For example, the following zip file will lead to an XSS vulnerability when processed by the code below:

file.zip: (1) <script>alert('hi')</script>somefile.txt (2) ... 

example.php: <?php $zip = new ZipArchive; $name = $_GET['name']; echo "The used zip file is " ; echo $name; $res = $zip->open($name); if ($res == TRUE) {      echo "Name index 0 is ";      echo $zip->getNameIndex(0);      $zip->close(); } else {     echo 'failed, code:' . $res; } ?> 

This exploit is not restricted to Unix-based operating systems either, it suffices to create a valid zip archive containing these filenames. Malicious archives like the one above can be created on a Unix system and later be used to exploit a vulnerability on a different platform. Furthermore, malicious archives can also be created on non-Unix platforms by editing the internal filenames stored in the archive before it is distributed to potential victims.

The moral of the story is don't trust input. Even if a particular source of input has external constraints placed on it, such as the characters supported by a given file system, they might be altered or negated entirely.