Print

Zeichick’s Take: Preying on the weaknesses



Alan Zeichick
Email
August 17, 2012 —  This past week, I’ve started receiving messages from eFax telling me that I’ve received a fax, and to click on a link to download my document. As a heavy eFax user, this seemed perfectly normal... until I clicked one of the links. It took me to some malware site. Fortunately, the site seemed to be designed to target Windows computers, and simply froze on my Mac’s browser.

The faux eFax messages were incredibly well designed, had clean headers, and made it through my e-mail service provider’s malware filters.

Since then, six of those malicious messages have appeared. I have to look carefully at the embedded link to distinguish those from genuine eFax messages, which have links to genuine faxes.

The cybercrime wars continue unabated, with no end in sight.

Malicious e-mail, whether it’s phishing, a “419”-style confidence scam, or an attempt to add your computers to someone’s botnet, is only one type of cybercrime. Most of the time, as software developers, we’re not focusing on bad e-mails, unless we’re trying to protect our own e-mail account, or worrying about the design of e-mails sent into automated systems. SQL Injection delivered by e-mail? That’s nothing I want to see.

Most of the attacks that we have to contend with are more directly against our software, or the platforms that they are built upon. Some of those attacks come from outside; some from inside.

Some attacks are successful because of our carelessness in coding, testing, installing or configuring our systems.

Other attacks succeed despite everything we try to do, because there are vulnerabilities we don’t know about, or don’t know how to defend against.

And sometimes we don’t even know that a successful attack occurred, and that data or intellectual property has been stolen.

We need to think long and hard about software security. SD Times has run numerous articles about the need to train developers and tester to learn secure coding techniques. We’ve written about tools that provided automated scanning of both source code and binaries. We’ve talked about fuzz testers, penetration tests, you name it.

What we generally don’t talk about is the backstory—the who and the why. Frankly, we generally don’t care why someone is trying to hack our systems; it’s our job to protect our systems, not sleuth out perpetrators.

That said, I’d like to invite you to read a story by SD Times editor Suzanne Kattau, “Cybercrime: How organizations can protect themselves,” where she interviewed Steve Durbin, for the Information Security Forum. It’s interesting to see this perspective on the broader problem. After all, we’re all soldiers in the cybercrime wars, whether we like it or not.

Alan Zeichick is editorial director of SD Times. Read his blog at ztrek.blogspot.com.




Related Search Term(s): security


Share this link: http://sdt.bz/36877
 


Comments


08/21/2012 11:07:25 AM EST

Please allow me to emend the claim that "sometimes we don’t even know that a successful attack occurred". The standard case for some years now has been that we do not know when attacks have succeeded. We find out later, or someone else discovers that one machine in a network has served as a platform for network discovery, surveillance, and control, leaving an agent on each machine or just returning to each machine as needed. Sometimes attackers come and go leaving no trace, but generally they stay on once the breach is exploited. In fact, sometimes multiple attackers occupy a machine and they may get into disagreements. I had such a situation, with malicious common criminals exploiting in one case a standard US backdoor and in another the old Sony rootkit. They jostled one another and when I blocked network traffic completely I found the US goverment on my systems, having forced their way in upon finding the front door locked, leaving the network vulnerable to anyone looking for adventure. Now the FBI, DHS, etc. want Congress to legalize retroactively the horse pooh these and other relevant agencies have been dooing for the last decade. With the US government heavily involved in hacking its citizenry and with other parties (local law enforcement, media companies, computer manufacturers and vendors, industry lobbying groups, web vigilantes, and, yes, software developers, among others) who feel they have "rights" regarding computing equipment they do not own, some of the evil originates with misguided abusers of power or opportunity. Especially since 2001 we have as a society created - with no broad agreement - a surveillance state that regards effective network defense as a threat. So self-defense for many of us may do more harm than good. In all cases, those looking to pwn your box prefer that you do not detect their presence. Generally the attackers succeed in not being found. Finding their presence is not a simple thing, and smug confidence that your system is clean impedes discovery. Once entrenched, the toolkits prove difficult to remove, even if you change equipment. To hear experienced administrators talking about wiping disks and reinstalling systems as curative for these issues really saddens me. We have a lot of willful ignorance of the computer-security crisis. Unfortunately as well, the industry has willingly undermined network and machine and software safety with backdoors, among other ways. Where it has not been done willingly, code can be adjusted in other ways. As I typed this, I just flashed back about six years to a goverment contractor telling me - in hacker-speak and writing remotely into a file on my own machine - that my resistance was absurd because whatever I did to my network I would by undermined by the fact that they had free access to my connections to the web through my ISP. That wasn't the half of it. It turned out they controlled and actively visited my whole apartment building (as far as I could tell) and they arrived on my machines by wifi, telephone, bluetooth and other radio, powerline, cable, and standard wired web connections, as available and needed. They dropped what they needed in small packets ready for automated recombination where they were deprived of system-borne drivers and apps. Code would be hidden directly in programs and files unrelated to their network activities and reactivated to to jobs. I found their tools on every public (rental machines, Kinko's, library, retailer demos, etc.), academic, and personal computer I could get access to at that time. Researching this was for years a bit of an obsession for me, because the ugliness of it proved to be at each turn worse. It is bottomless, indeed, because now on top of secrecy and misclassification of the facts at the government level, these abuses are being resold as necessary for - of all things - our security as a nation. After all that has gone on, bought and/or duped politicians are being primed to codify this insanity as legal and even necessary. Learning what I did required an enormous expenditure of resources. I would not recommend doing things the way I did, particularly if you fancy continuing to develop systems and applications for a living. One should be aware that the problem is enormous, and that developers quite generally are targeted for abuse. Getting access to code at the source, be it firmware or software, counts among the most appealing and fertile of targets for network creeps. None of us cannot afford complacency on this and we put more than our networks at risk where we descend into complicity.

United StatesRobert Callahan


close
NEXT ARTICLE
Cigital Develops Ready-to-Use Tools for Securing the Smart Grid
Cigital Inc. announced the release of the Guide to Developing a Cyber Security and Risk Mitigation Plan Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
MAY 2013 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?