Part of the reason for increased popularity of Macintosh computers is that Apple has made the machines friendlier to running programs popular on Windows-based machines.

Hackers experienced with attacking Windows programs can apply some of their know-how to software modified to run on Macintosh computers.

Developers that re-craft Windows programs for Macintosh systems might not be adept at building security components on the latest Leopard operating system used in Apple machines.

Windows developers take their code and make it work on Apple,” Hotchkies said. “They could take potential vulnerabilities with them or possibly create new ones because they are working on an entirely different platform.”

I haven’t heard about any zero-day exploits to the iPhone yet (as long as you don’t count jailbreaking), but I’m sure they’re on the way. Read the article here.

The ID theft ring stole more than 40 million credit and debit card numbers, said Michael Sullivan, U.S. attorney for the District of Massachusetts. The criminals installed sophisticated “sniffer” programs on the retailers’ networks, allowing them to collect credit card and password information, he said during a press conference.

The defendants then used these cards to withdraw tens of thousands of dollars at a time from cash machines, the DOJ said. Gonzalez and others were allegedly able to conceal and launder their fraud proceeds by using anonymous Internet-based currencies and by channeling funds through bank accounts in Eastern Europe, the DOJ said.

Wow. Pretty devious. Read my earlier post about the TJX hacking here.

I’ll detail the hack in a later post.

First here’s a link to a post on Glen Gordon’s blog about injection: http://blogs.msdn.com/glengordon/archive/2008/04/15/some-sql-injection-attack-misperceptions-and-reality.aspx. Glen includes a nice list of common mistakes when thinking about preventing injection attacks.

Next is a link from the MSDN magazine showing how to stop injection attacks: http://msdn2.microsoft.com/en-us/magazine/cc163917.aspx
I know this was a lazy post, but cut me some slack. I’ve got a 2 month old baby and a new PS3.

• Databases
• Form fields
• Session variables
• Query string
• Cookies

Using the library is very simple. Just add a reference to the dll to your project, and you’re ready to go. Here’s a quick and dirty code example encoding a value from the query string:

string Name = AntiXss.HtmlEncode(Request.QueryString["Name"]);

A good rule to live by is “When in doubt. Encode it.” Just don’t encode it twice.

You can download the library from Microsoft here.

We work on strictly enterprise applications and as a result we’re tucked in behind a nice corporate firewall. This is no comfort though because we have sites all over the world, and there are countless opportunities for attackers to get behind enemy lines. Because I’m beginning to take a more in-depth approach to security and how I write code, I thought I would share some of my lessons here in yet another series of blog posts (like the Second Look at Linux and FLOSS series weren’t enough). My next installment will concentrate on using the Anti-Xss library as well as a few code samples. The library is free to use and provides an easy method for encoding output from untrusted sources (i.e. the user).

It’s not a secret that WEP is not secure, and the IT management for TJX must have known it. Now I’m sure it’s expensive to upgrade the wireless systems in however many stores they operate, but security isn’t a “don’t fix it if it ain’t broken” type of thing. Keeping your security current has to be a priority, because you can guarantee that attackers are looking for any vulnerability they can find. They’re looking for the path of least resistance, and WEP ain’t very resistant.

The hackers who ransacked TJX Companies Inc.’s computer network and exposed at least 45.7 million credit and debit card holders to identity fraud reportedly began their assault by exploiting Wi-Fi weaknesses at a Marshalls clothing store near St. Paul, Minn.

I don’t believe the use of WEP is the only lax security issue TJX was guilty of either. Why keep so much customer personal data for so long? I believe that’s part of the issue. The fact that the major credit card companies require merchants to keep the card number for transactions simply adds to the problem. I realize it’s saved in the case of a disputed charge, but that doesn’t change the fact that it’s a honey pot to attackers. If the credit card number doesn’t have to be stored, then there’s no threat of customers being affected by a security breach.

So here’s my proposal. Associate a second number with a credit card, and store that number in the merchants’ systems. This number isn’t useful by itself, but it can be used by VISA or MasterCard to determine the card holder. If the merchant’s system is compromised, the secondary number can’t be used to make purchases or just about anything else for that matter. It’s only useful to the credit card company when a charge is disputed. Does this sound plausible to you?

There’s always cash though.

According to Spamhaus RBN is “Among the world’s worst spammer, child-pornography, malware, phishing and cybercrime hosting networks. Provides “bulletproof hosting”, but is probably involved in the crime too”. RBN was the subject of an article in the Washington Post on October 13, 2007, where Symantec and other security firms claim RBN provides hosting for many illegal activities, including identity theft and phishing. The article quotes a spokesman for Kaspersky Labs that the owners of RBN might not have directly violated the law as they primarily provide hosting services; their customers are apparently the ones violating laws. 

The Internet is the most significant technological advancement in my lifetime, but with the benefits its offered there are also those who use it as a tool for mischief. To be a successful spammer or to have a successful phishing site requires a hosting provider that at best looks the other way or at worst supports your activities.

One alleged “phishing” gang, known as the Rock Group, which used the company’s hosting service, is estimated to have made $150 million last year by tricking people into providing bank account details.

The RBN is also said to have developed dozens of fake anti-spyware and anti-virus programs to dupe people into giving it access to their computers in the mistaken belief that they were protecting themselves from online threats.

The RBN’s activities are so notorious that VeriSign, one of the world’s biggest Internet security companies, has dubbed it “the baddest of the bad.”

What really irritates me is that these losers don’t even have the courage to commit their crimes face-to-face. I can just imagine some greasy, smelly neck-bearded geek trying to hold up a little old lady and getting a beat down by granny. Hell, these guys may even have political connections.

It has recently been alleged that the founder and leader of the organisation, known as ‘Flyman’, is related to a “powerful and well-connected” Russian politician. In light of this, it is entirely possible that recent cyber-terrorism activities, such as the May 2007 denial of service attacks in Estonia, may have been co-ordinated by or out-sourced to such an organisation. Although this is currently unproven, intelligent estimates suggest this may be the case.

Like any other criminal organization, they’re highly organized.

Now considering the fact that the RBN and their accomplices are practically big business it may seem like there’s nothing we as developers can do. That’s not the case. We’ve all got family or friends who aren’t exactly tech-savy.

• Warn them about phishing scams. Make sure they know their bank or credit card company isn’t going to contact them via email requesting information.

• Help them install a virus scanner and anti-spyware software from reputable companies (AVG, AdAware, etc).

• Warn them about not downloading and running sofware they find online.

• Install Firefox for them and get them off of IE if they’re on Windows.

It only takes a little prudence and knowledge to avoid becoming yet another cyber-victim. As a the resident geek in your family (don’t deny it – you know you are), help make it just a little more difficult for these losers to find more victims.

Let’s think of a scenario such as this: I’m using an open source library to handle zipping and unzipping of files in an application I’m deploying to multiple servers in my corporate network. Now let’s say the build or dependency server of the open source library I’m using has been compromised and a trojan has been inserted into the library. Now I’ve unknowingly introduced that trojan to several production servers on my corporate network. Developers and IT departments are obsessed with securing their networks and operating systems, the development stack must secured as well.

It seems the main culprit is automated dependency management system. According to Brian Chess of Fortify Software:

The first and simplest is to refrain from adopting automated dependency management systems altogether. Managing dependencies manually eliminates the potential for unexpected behavior caused by the build system.

While I haven’t heard of an open source project being compromised yet, I don’t think it’s unreasonable to say that the possibility is there. Here’s a link (pdf) to the Fortify Software report detailing the topic.