It’s the money. The NYT reports that next week a paper at the IEEE security and privacy symposium will reveal the results of research into the global financial and technical architecture of spam.

“It is the banking component of the spam value chain that is both the least studied and, we believe, the most critical,” the researchers write.

The computer scientists say that because the spam system relies on just a few banks and an even smaller number of credit card processors, the business is highly vulnerable to disruption by regulators and law enforcement agencies.

Hard to believe the banking component is the least studied. Maybe that just means that everyone (myself included) focus on the technical weeds of spam linguistics.

The NYT highlights the use of diverse international paths to slip through law enforcement and regulation.

Note that the server was in China. This might set off alarm bells and be the focus for some, especially if they already are prone to believe China is the source of most attacks, but the team does an excellent job continuing further with their research and analysis.

On Oct. 27, 2010, for instance, a network of zombie computers called the Grum botnet delivered an e-mail with “Viagra Official Site” in the subject line. Users who responded to the message were directed to a Web site that had been registered nine days earlier.

The Internet system that supported the Web site was spread around the globe: the domain registrar was in Russia, the server computer was in China, and a proxy server computer was in Brazil. When a purchase was made from the Web site, the shopper was redirected from a computer in Turkey to the Azerigazbank Joint-Stock Investment Bank in Baku, Azerbaijan. The drugs themselves were sent directly from a manufacturer in India.

The weak link in the system, the researchers noted, was that the Visa payment system handled the transaction between the customer’s bank in the United States and the bank in Azerbaijan.

The infiltration of the system seems to be the key to how they built an accurate and detailed model.

As I said in my 2011 BSidesSF presentation, insider information brings investigations far closer and with better closure than from an outsider perspective. Response to attacks must include methods of surveillance and infiltration to be most effective.

The U.S. Department of Justice (DOJ) in 2010 issued its final ruling on standards for accessibility under the Americans with Disabilities Act (ADA). New guidelines affect ATM physical access, communication, features, and privacy controls.

• Same level of privacy for all types of input/output
• Speech and Braille enabled
• Speech capable of being repeated or interrupted
• All displayed information usable by visually impaired
• TTY and TRS (Telecommunication Relay Services)

These all raise interesting security control issues for the financial industry. A person using speech mode should have the option of privacy using headphones and making the screen completely blank. Even more complicated is the use of a relay service, which by definition is a person in the middle (PitM) of a secure exchange.

Perhaps most interesting is the definition of “power-driven mobility devices”. Even a Segway qualifies, so an ATM has to be accessible to them unless a financial institution can prove that its use is unreasonable or would cause a “fundamental” change to their operations.

I also noted that the federal rule calls for one compliant ATM per location (outside is not considered in the same location as inside) but California has a 50% rule.

vCenter has a flaw that provides network read access to arbitrary files. VMware has released an advisory with patch information (VMSA-2011-0008):

A directory traversal vulnerability allows an attacker to remotely retrieve files from vCenter Server without authentication. In order to exploit this vulnerability, the attacker will need to have access to the network on which the vCenter Server host resides.

If you have network access to vCenter and login as a user, the same advisory points out that session IDs are exposed.

The SOAP session ID can be retrieved by any user that is logged in to vCenter Server. This might allow a local unprivileged user on vCenter Server to elevate his or her privileges.