<![CDATA[[SecurityRatty] tag: basic]]> http://www.securityratty.com/tag/basic Mon, 27 Oct 2008 14:24:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[Anti-Debugging Series - Part I]]> http://www.securityratty.com/article/5dc5d012cfad6c070272eeb8f4c0dc2b http://www.securityratty.com/article/5dc5d012cfad6c070272eeb8f4c0dc2b For those that don’t know, anti-debugging is the implementation of one or more techniques within computer code that hinders attempts at reverse engineering or debugging a target process. Typically this is achieved by detecting minute differences in memory, operating system, process information, latency, etc. that occur when a process is started in or attached to by a debugger compared to when it is not. Most research into anti-debugging has been conducted from the vantage point of a reverse engineer attempting to bypass the techniques that have been implemented. Limited data has been presented that demonstrates anti-debugging methods in a high level language that the average developer can understand. It is with this in mind that I hope to begin a series of posts that present some of the methods of anti-debugging in a clear, concise, and well documented fashion. The end goal of this series is to arm developers with the techniques and knowledge that will allow them to add a layer of protection to their software while simultaneous educating reverse engineers in some of the anti-debugging methods used by malware authors today.

Before we delve into the intricacies of individual methods of anti-debugging let’s use this post to define the classes of anti-debugging that we will be discussing. While other classes may exist, the definition of these classes is an attempt to include the majority of anti-debugging methods in use today. There is some overlap between classifications and we may have left out some methods due to limited exposure or effectiveness.

API Based Anti-Debugging
API based anti-debugging is the most straightforward and possibly the easiest to understand for a typical developer. Using both documented and undocumented API calls, these methods query process and system information to determine the existence or operation of a debugger. From single line calls such as IsDebuggerPresent() and CheckRemoteDebugger() to slightly more complex methods including debugger detaching and CloseHandle() checks. These methods are generally trivial to add to an existing code base and many can even be implemented in as few as two or three lines.

Exception Based Anti-Debugging
Exception based anti-debugging is slightly different than your basic API based techniques. Many times when a debugger is attached to a process, exceptions are trapped and handled by the debugger without regard to passing the exception back to the application for continued execution. Occasionally these exceptions can even crash or terminate a process when run under a debugger and be handled gracefully when running clean. It is these discrepancies that makes exception based anti-debugging techniques possible.

Process and Thread Block Anti-Debugging
Some of the API based anti-debugging methods use published functions to query information from within the process and thread blocks for our running code. Many API based detections can be subverted within a debugger by hooking the API call and returning values that indicate a clean process. One way around this subversion is to directly query the process and thread blocks, bypassing the API calls. Direct analysis of the process and thread blocks, while more complex, can lead to a more accurate and high assurance result.

Modified Code Anti-Debugging
One of the methods that a debugger uses to signal a breakpoint is to insert a break byte into the running code at the location that it wishes to stop execution. The process execution breaks when this value is seen, giving control to the debugger. When the program is resumed, the breakpoint value is removed and replaced with the original byte, the execution backed up one byte, and the program is resumed. Detection of software based breakpoints can be achieved by analyzing the process for modifications from the expected norm.

Hardware and Register Based Anti-Debugging
A second way that a debugger can break the execution of a process is by using a hardware breakpoint. A hardware breakpoint relies upon CPU registers to store the pertinent information and to detect when the target break addresses are seen on the bus. A break interrupt is triggered at the appropriate time based on these register values. Reading or modifying the hardware can allow for the detection of a debugger.

Timing and Latency Anti-Debugging
Finally timing and latency can be used as an effective anti-debugging method. When executing a program within a debugger, specifically when single stepping, a much larger latency occurs between execution of instructions. This latency can be detected and compared against a reasonable threshold to detect the existence of a debugger attached to our process.

Each of the classes of anti-debugging outlined above has merit when used individually to protect a process. While none of them can be assured to ever protect a program from a determined reverse engineer or debugger, implementation of these techniques (or many of them if appropriate) can sufficiently slow down the debugging process and hopefully make the attacker spend his time on other, easier, ventures. In the remainder of this series on anti-debugging we will review in depth some of the more interesting methods of each of the above classes. So bring along your debugger and your development environment and let the games begin.

]]> Tue, 02 Dec 2008 17:56:25 +0000 process execution breaks execution process methods query process hardware breakpoint hardware process information target process methods Anti-Debugging Series - Part I <![CDATA[Yet Another Web Malware Exploitation Kit in the Wild]]> http://www.securityratty.com/article/5caa05f53942f1ddb87a74f20c2c3599 http://www.securityratty.com/article/5caa05f53942f1ddb87a74f20c2c3599
With business-minded malicious attackers embracing basic marketing practices like branding, it is becoming increasingly harder, if not pointless to keep track of all XYZ-Packs currently in circulation. How come? Due to their open source nature allowing modifications, claiming copyright over the modified and re-branded kit, the source code of core web malware exploitation kits continue representing the foundation source code for each and every newly released kit.

In fact, the practice is becoming so evident, that anecdotal evidence in the form of monitoring ongoing communications between sellers and buyers reveals actual attempts of intellectual property enforcement in the form of  exchange of flames between an author of a original kit, and a newly born author who seems to have copied over 80% of his source code, changed the layout, re-branded it, added several more exploits and started pitching it as the most exclusive kit there is available in the underground marketplace.

What's new about this particular kit anyway? Changed iframe and js obfuscation techniques, doesn't require MySQL to run, with several modified Adobe Acrobat and Flash exploits - all patched and publicly obtainable. This is precisely where the marketing pitch ends for the majority of malware kits released during the last quarter.

As always, there are noticable exceptions to the common wisdom that time-to-underground market isn't allowing them to innovate, but thankfully, these exceptions aren't yet going mainstream. What is going to change in the upcoming 2009? Web malware exploitation kits are slowly maturing into multi-user cybercrime platforms, where traffic management coming from the SQL injected or malware embedded sites is automatically exploited with access to the infected hosts or to the traffic volume in general offered for sale under a flat rate, or on a volume basis.

Converging traffic management with drive-by exploitation and offering the output for sale, all from a single web interface, is precisely what malicious economies of scale is all about.

Related posts:
Cybercriminals release Christmas themed web malware exploitation kit
New Web Malware Exploitation Kit in the Wild
Modified Zeus Crimeware Kit Gets a Performance Boost 
Zeus Crimeware Kit Gets a Carding Layout
Web Based Malware Emphasizes on Anti-Debugging Features
Copycat Web Malware Exploitation Kit Comes with Disclaimer
Web Based Malware Eradicates Rootkits and Competing Malware
Two Copycat Web Malware Exploitation Kits in the Wild
Copycat Web Malware Exploitation Kits are Faddish
Web Based Botnet Command and Control Kit 2.0
BlackEnergy DDoS Bot Web Based
A New DDoS Malware Kit in the Wild
The Small Pack Web Malware Exploitation Kit
The Nuclear Grabber Kit
The Apophis Kit
Nuclear Malware Kit
The Random JS Malware Exploitation Kit
Metaphisher Malware Kit Spotted in the Wild
]]> Tue, 02 Dec 2008 03:24:43 +0000 kit malware exploitation kit nuclear malware kit zeus crimeware kit malware exclusive kit nuclear grabber kit apophis kit ddos malware kit Yet Another Web Malware Exploitation Kit in the Wild <![CDATA[Tips for staying safe online this Holiday season]]> http://www.securityratty.com/article/4601cb0e0df5f980983616dff3fecc59 http://www.securityratty.com/article/4601cb0e0df5f980983616dff3fecc59 Great article by Mr Walling.
Take the time read the tips and maybe you wont become a statistic this season
clipped from www.marketwatch.com
Walling Data’s Top Ten Safety Tips for Online Shopping

“The Internet is safe if you follow basic, fundamental rules of
using a computer safely,” says Luke Walling, Founder and President of Walling
Data, one of the largest distributors of online security products in
the country. “Many people think of their computer much like
they would an appliance, such as a microwave or stereo that behaves in a
predictable pre-programmed way. But, in reality computers
are dynamic devices that evolve dramatically with the installation of
each new program. It’s important to remember that viruses
and spyware are programs as well.”
  blog it

Feed Ads By BidVertiser.comFeed Ads By BidVertiser.com

]]> Fri, 28 Nov 2008 13:37:01 +0000 online tips online security products computer safely safety tips computer dynamic devices datas top safe Tips for staying safe online this Holiday season <![CDATA[The Future of Ephemeral Conversation]]> http://www.securityratty.com/article/1474b03de8a1d60cdf0aa28759ddce93 http://www.securityratty.com/article/1474b03de8a1d60cdf0aa28759ddce93 When he becomes president, Barack Obama will have to give up his BlackBerry. Aides are concerned that his unofficial conversations would become part of the presidential record, subject to subpoena and eventually made public as part of the country's historical record.

This reality of the information age might be particularly stark for the president, but it's no less true for all of us. Conversation used to be ephemeral. Whether face-to-face or by phone, we could be reasonably sure that what we said disappeared as soon as we said it. Organized crime bosses worried about phone taps and room bugs, but that was the exception. Privacy was just assumed.

This has changed. We chat in e-mail, over SMS and IM, and on social networking websites like Facebook, MySpace, and LiveJournal. We blog and we Twitter. These conversations -- with friends, lovers, colleagues, members of our cabinet -- are not ephemeral; they leave their own electronic trails.

We know this intellectually, but we haven't truly internalized it. We type on, engrossed in conversation, forgetting we're being recorded and those recordings might come back to haunt us later.

Oliver North learned this, way back in 1987, when messages he thought he had deleted were saved by the White House PROFS system, and then subpoenaed in the Iran-Contra affair. Bill Gates learned this in 1998 when his conversational e-mails were provided to opposing counsel as part of the antitrust litigation discovery process. Mark Foley learned this in 2006 when his instant messages were saved and made public by the underage men he talked to. Paris Hilton learned this in 2005 when her cell phone account was hacked, and Sarah Palin learned it earlier this year when her Yahoo e-mail account was hacked. Someone in George W. Bush's administration learned this, and millions of e-mails went mysteriously and conveniently missing.

Ephemeral conversation is dying.

Cardinal Richelieu famously said, :If one would give me six lines written by the hand of the most honest man, I would find something in them to have him hanged." When all our ephemeral conversations can be saved for later examination, different rules have to apply. Conversation is not the same thing as correspondence. Words uttered in haste over morning coffee, whether spoken in a coffee shop or thumbed on a Blackberry, are not official pronouncements. Discussions in a meeting, whether held in a boardroom or a chat room, are not the same as answers at a press conference. And privacy isn't just about having something to hide; it has enormous value to democracy, liberty, and our basic humanity.

We can't turn back technology; electronic communications are here to stay and even our voice conversations are threatened. But as technology makes our conversations less ephemeral, we need laws to step in and safeguard ephemeral conversation. We need a comprehensive data privacy law, protecting our data and communications regardless of where it is stored or how it is processed. We need laws forcing companies to keep it private and delete it as soon as it is no longer needed. Laws requiring ISPs to store e-mails and other personal communications are exactly what we don't need.

Rules pertaining to government need to be different, because of the power differential. Subjecting the president's communications to eventual public review increases liberty because it reduces the government's power with respect to the people. Subjecting our communications to government review decreases liberty because it reduces our power with respect to the government. The president, as well as other members of government, need some ability to converse ephemerally -- just as they're allowed to have unrecorded meetings and phone calls -- but more of their actions need to be subject to public scrutiny.

But laws can only go so far. Law or no law, when something is made public it's too late. And many of us like having complete records of all our e-mail at our fingertips; it's like our offline brains.

In the end, this is cultural.

The Internet is the greatest generation gap since rock and roll. We're now witnessing one aspect of that generation gap: the younger generation chats digitally, and the older generation treats those chats as written correspondence. Until our CEOs blog, our Congressmen Twitter, and our world leaders send each other LOLcats – until we have a Presidential election where both candidates have a complete history on social networking sites from before they were teenagers– we aren't fully an information age society.

When everyone leaves a public digital trail of their personal thoughts since birth, no one will think twice about it being there. Obama might be on the younger side of the generation gap, but the rules he's operating under were written by the older side. It will take another generation before society's tolerance for digital ephemera changes.

This essay previously appeared on The Wall Street Journal website (not the print newspaper), and is an update of something I wrote previously.

]]> Mon, 24 Nov 2008 11:06:41 +0000 ephemeral conversation conversation safeguard ephemeral conversation ephemeral ephemeral conversations conversations generation generation gap public scrutiny The Future of Ephemeral Conversation <![CDATA[Will Code Malware for Financial Incentives]]> http://www.securityratty.com/article/30eebfa1383ce3a671879e2f1f0af37d http://www.securityratty.com/article/30eebfa1383ce3a671879e2f1f0af37d
A couple of hundred dollars can indeed get you state of the art undetectable piece of malware with post-purchase service in the form of automatic lower detection rate for sure, but what happens when the vendors of such releases start vertically integrating just like everyone else, and start offering OS-independent spamming, flooding, modifications and tweaking of popular crimeware kits in the very same fashion? The quality assurance process gets centralized into the hands of experienced programmers that have been developing cybercrime facilitating tools for years.

It's interesting to monitor the pricing schemes that they implement. For instance, the modularity of a particular malware, that is the additional functions that a buyer may want or not want, increase or decrease the price respectively. Others, tend to leave the price open topic by only mentioning the starting price for their services and they increasing it again in open topic fashion.

Let's take look at some recently advertised (translated) "malware coding for hire" propositions, highlighting some of the latest developments in their pricing strategies :

Proposition 1 :
"Programs and scripts under the following categories are accepted :
grabbers; spamming tools for forums, spamming tools for social networking sites, modifications of admin panels for (popular crimeware kits), phishing pages

Platform: software running on MAC OS to Windows
Multitasking: have the capacity to work on multiple projects
Speed and responsibility: at the highest level
Pre-payment for new customers: 50% of the whole price, 30% pre-pay of the whole price for repreated customers
Support: Paid
Rates: starting from 100 euros

If, after speaking ultimate price, you decide to add to your order something else - the price change. Prepare the job immediately, which will understand what to do and how much it will cost you, if you have any suggestions for a price, then lays them immediately and not after the work is completed. If you order something that requires parsing your logs, and their continued use, you agree to provide "a significant portion of the logs, so that after putting the project did not raise misunderstandings due to the fact that some logs are no longer "fresh", because of their "uniqueness". In this case, for the finalization of the project will be charged an additional fee."

This is an example of an "open topic pricing scheme" with the vendor offering the possibility to code the malware or the tool for any price above 100 euro based on what he perceives as features included within worth the price.

Proposition 2:
"Starting price for my malware is 250 EUR. Additional modules like P2P features, source code for a particular module go for an additional 50 EUR. If you're paying in another currency the price is 200 GBP or 395 dollars. I sell only ten copies of the builder so hurry up. The trading process is simple - a password protected file with the malware is sent to you so you can see the files inside. You then sent the money and I mail you back the password. If you don't like this way you lose. 

I can also offer you another deal, I will share the complete source code in exchange to access to a botnet with at least 4000 infected hosts because I don't have time to play around with me bot right now.

This proposition is particularly interesting because the seller is introducing basic understanding of exchange rates, but most of all because he's in fact offering a direct bargain in the form of access to a botnet in exchange for a complete source code of his malware bot. Both propositions are also great examples that vendors engage by keeping their current and potential customers up-to-date with TODO lists of features to come next to the usual CHANGELOGS, and, of course,  establish trust by allowing potential customers to take a peek at the source code of the malware they're about to purchase.

Related posts:
Coding Spyware and Malware for Hire
The Underground Economy's Supply of Goods and Services
The Dynamics of the Malware Industry - Proprietary Malware Tools
Using Market Forces to Disrupt Botnets
Multiple Firewalls Bypassing Verification on Demand
Managed Spamming Appliances - The Future of Spam
Localizing Cybercrime - Cultural Diversity on Demand
E-crime and Socioeconomic Factors
Russia's FSB vs Cybercrime
Malware as a Web Service
Localizing Open Source Malware
Quality and Assurance in Malware Attacks
Benchmarking and Optimising Malware
]]> Tue, 18 Nov 2008 10:57:55 +0000 malware code source malware malware attacks malware bot proprietary malware tools source code complete source code tools Will Code Malware for Financial Incentives <![CDATA[Check It Out! FAIR Public Training December 10-12]]> http://www.securityratty.com/article/7c0dad2af3212f7ceb6a464d5f435a90 http://www.securityratty.com/article/7c0dad2af3212f7ceb6a464d5f435a90 There’s been quite a few people talking about what sorts of strategies make sense for security and security departments in a downturn.  And they’re all very good - but there’s one thing that I’d like to add.

One easy, inexpensive way to actually increase your effectiveness in 2009 is to, right now, make a quick review your risk management processes.  As you take a look at how you’re using risk in your organization, I’d ask you to make sure that those processes are providing value for the energy you’re spending.  If they’re not - if you’re not successfully using risk within security and with the other lines of business that you serve - then I’d like to invite you to  come take advantage of RMI’s public training session for 2008, held in Columbus Ohio on December 10-12.  >A brochure is here<.

For three days and $1,995 - you’ll get real answers to many of the commonly voiced frustrations RMI hears concerning risk & risk management.  Answers around measurement, application, communicating risk to other lines of business, heck, basic answers as to what risk is and how to get consistent, defensible values that actually mean something.

Not to mention - Strengthening your Risk Management processes increases your ability to manage risk, which reduces the amount of risk you actually face.

NEW TO THE PUBLIC STUFF!

I’m personally excited because this is the first time that our public training we’ll feature measurement “calibration” exercises and include excel tools to take home and use for quantitative FAIR analysis.  These are benefits we’ve only previously reserved for private client workshops.

I know that FAIR can help you and your organization, but as the sales guys always say, “don’t take my word for it”.  Here’s something we recently received (unsolicited) from the CSO of one of the 10 largest banks in the US, who has had several of his analysts receive this same basic training:

I would like to also add my deep appreciation for what FAIR and RMI has brought to (us) and how we go about the business of risk analysis. We have had some great conversations around risk with the lines of business that have ended very favorably for us.

More information can be found on RMI’s website here:  http://www.riskmanagementinsight.com/12_2008_training.html

Thanks.

Oh and tomorrow, we’ll talk a little bit about quantitative and qualitative risk.

]]> Wed, 05 Nov 2008 12:32:53 +0000 risk management risk management processes risk qualitative risk risk analysis fair public manage risk quantitative fair analysis Check It Out! FAIR Public Training December 10-12 <![CDATA[Extraordinary Journey from Fundamental Electronics to Fabulous Enchanted Systems with Arduino's and Magical Potions]]> http://www.securityratty.com/article/a4a9c781028d6546cebed713bcce8f51 http://www.securityratty.com/article/a4a9c781028d6546cebed713bcce8f51 Extraordinary Journey from Fundamental Electronics to Fabulous Enchanted Systems with Arduino's and Magical Potions

This is Morgellon and Droop's talks about hacking the Arduino micro controller platform from Phreaknic 12. Droops and Morgellon will take you from basic electronics to building embedded systems. Learn how to build a standalone RFID tag reader with a fancy LCD display or your own oscilloscope or children's toys that speak to you or how to solar power a geothermal heat pump. There may even be some giveaways and contests. Magical Potions will be consumed but not provided.

Check out the following sites by Droops and Morgellon:
http://dailyduino.com/
http://www.hackermedia.org/

I've done a little work to pull some noise out of the audio, but I may have made it worse in some spots. Thanks go out to the Phreaknic 12 A/V team SomeNinjaMaster, Night Carnage, Greg, Brimstone, Poiu Poiu, Mudflap, and Drunken Pirate for setting up the rigs and capturing the video.

]]> Wed, 29 Oct 2008 19:00:18 +0000 magical potions systems extraordinary journey fundamental electronics fancy lcd display geothermal heat pump morgellon fabulous phreaknic Extraordinary Journey from Fundamental Electronics to Fabulous Enchanted Systems with Arduino's and Magical Potions <![CDATA[Extraordinary Journey from Fundamental Electronics to Fabulous Enchanted Systems with Arduino's and Magical Potions]]> http://www.securityratty.com/article/5e0c1709599493465a7a30419b0c4943 http://www.securityratty.com/article/5e0c1709599493465a7a30419b0c4943 Extraordinary Journey from Fundamental Electronics to Fabulous Enchanted Systems with Arduino's and Magical Potions

This is Morgellon and Droop's talks about hacking the Arduino micro controller platform from Phreaknic 12. Droops and Morgellon will take you from basic electronics to building embedded systems. Learn how to build a standalone RFID tag reader with a fancy LCD display or your own oscilloscope or children's toys that speak to you or how to solar power a geothermal heat pump. There may even be some giveaways and contests. Magical Potions will be consumed but not provided.

Check out the following sites by Droops and Morgellon:
http://dailyduino.com/
http://www.hackermedia.org/

I've done a little work to pull some noise out of the audio, but I may have made it worse in some spots. Thanks go out to the Phreaknic 12 A/V team SomeNinjaMaster, Night Carnage, Greg, Brimstone, Poiu Poiu, Mudflap, and Drunken Pirate for setting up the rigs and capturing the video.

]]> Wed, 29 Oct 2008 19:00:18 +0000 magical potions systems extraordinary journey fundamental electronics fancy lcd display geothermal heat pump morgellon fabulous phreaknic Extraordinary Journey from Fundamental Electronics to Fabulous Enchanted Systems with Arduino's and Magical Potions <![CDATA[Extraordinary Journey from Fundamental Electronics to Fabulous Enchanted Systems with Arduino's and Magical Potions]]> http://www.securityratty.com/article/e4d175bf330f6eddab2f623702059ca6 http://www.securityratty.com/article/e4d175bf330f6eddab2f623702059ca6 Extraordinary Journey from Fundamental Electronics to Fabulous Enchanted Systems with Arduino's and Magical Potions

This is Morgellon and Droop's talks about hacking the Arduino micro controller platform from Phreaknic 12. Droops and Morgellon will take you from basic electronics to building embedded systems. Learn how to build a standalone RFID tag reader with a fancy LCD display or your own oscilloscope or children's toys that speak to you or how to solar power a geothermal heat pump. There may even be some giveaways and contests. Magical Potions will be consumed but not provided.

Check out the following sites by Droops and Morgellon:
http://dailyduino.com/
http://www.hackermedia.org/

I've done a little work to pull some noise out of the audio, but I may have made it worse in some spots. Thanks go out to the Phreaknic 12 A/V team SomeNinjaMaster, Night Carnage, Greg, Brimstone, Poiu Poiu, Mudflap, and Drunken Pirate for setting up the rigs and capturing the video.

]]> Wed, 29 Oct 2008 19:00:18 +0000 magical potions systems extraordinary journey fundamental electronics fancy lcd display geothermal heat pump morgellon fabulous phreaknic Extraordinary Journey from Fundamental Electronics to Fabulous Enchanted Systems with Arduino's and Magical Potions <![CDATA[Applying SDL Principles to Legacy Code]]> http://www.securityratty.com/article/92d969d155d0bac3cdff2f17709cb618 http://www.securityratty.com/article/92d969d155d0bac3cdff2f17709cb618 Hello, this is Scott Stender from iSEC Partners, one of the SDL Pro Network partners.  As security consultants, we at iSEC work with a variety of companies to drive security throughout their development cycle.   Clients with mature security processes ask that we help carry out parts of their process, from requirements analysis to penetration testing.  Other clients need help defining their security processes, and we help define and kickoff a program based on the Microsoft SDL, other defined processes, or variations thereof, depending on the client’s needs and abilities.  Whether participating in an existing process or helping define one, I personally have been lucky enough to have seen my fair share of successes and failures, and it is this perspective that I hope to share in this guest post.

I find that legacy code poses a unique challenge for organizations rolling out a new security process.  Often, the resources dedicated to maintaining older code are a small fraction of those devoted to new features or products.  Furthermore, the original developers for such features have often moved on, leaving no subject matter experts to drive reviews.  The astute reader will ask “How do I apply the principles of the Microsoft SDL to legacy code when I have no development resources and nobody knows how it works?”

The answer is “Start small, and build expertise over time.”

A Rising Tide Lifts All Boats

The best thing a security engineering team can do to improve security in the short term is to drive code quality, and the first step in this process is to define and enforce a secure coding standard.  This helps on two fronts: 

1.       It will improve code quality and reduce implementation flaws across the entire code base.  Unlike other security processes, driving a secure coding standard is relatively easy to accomplish across an entire code base, regardless of the code’s age, by a focused security team.  That is not to say that it is easy without qualification – a large batch of spaghetti code will require a lot of work to untangle!  Such an effort can only be called “easy” when compared to, say, comprehensive identification and remediation of design flaws across legacy features.  Even so, improving code quality through the use of secure coding standards offers a unique combination of high impact, applicability to features, and ability to be carried out by a core team that makes it a sensible first step.

 

2.       The security team might notice that some sections of code have more standards violations or outright flaws than others.  This is an instance of vulnerability clustering, a concept that has been used to predict vulnerability rates and improve quality in the functional realm.  The evidence is anecdotal, but it stands to reason that portions of code that consistently violate secure coding standards are good places to start looking for other classes of security flaw.  These are security hotspots, and should be high on the prioritized list for further review.

Security testing may also be applied to legacy code, but initial activities should be considered on a case-by-case basis based on the expected return on investment.  Such testing ranges from using inexpensive off-the-shelf tools to exercise common interfaces to rather expensive custom testing and formal analysis.  It is worthwhile to begin with off-the-shelf tools, such as those that target file parsers or web applications, and tools created as part of your greater secure development efforts.  These can help identify easily-found flaws and suggest improvements to the coding standards.  Comprehensive security testing, on the other hand, is best tackled after the Legacy Security Push.

The Legacy Security Push

Coding standards and basic testing provide bang for the buck, but formal security processes seek to provide security assurance.  The challenge for legacy code is that it needs to play catch-up.  Security processes that occur early in the development cycle, such as requirements analysis, design review, and threat modeling, are particularly difficult to achieve years after the fact.  The main goal of the Legacy Security Push is to create the deliverables from these efforts, the most important of which are security requirements and a full risk analysis.

It may sound trivial, but security requirements are essential.  Not only do they define proper operation for the system in question, they also define assumptions that are suitable for relying systems.   It is very common to find security flaws in legacy systems that arise from well-intentioned but incorrect assumptions such as “I assume that the Foo authenticates server Bar when initiating a bank transfer.”  It stands to reason that Foo would do so for such an important activity, but this assumption must be validated.  It is very common for older features to have been deployed in and written for different environments where the security assumptions that are "obvious" today just didn't apply at the time.

When reviewing legacy systems, the first step is to identify such requirements.  If the original architects, developers or managers are available, they can provide valuable insight at this stage.  More often than not this is not the case, and analysis must instead rely on what documentation is present and interaction between the software and its consumers.  The goal is the same as in requirements analysis during project inception, except that in this case one must turn the process on its head and reverse engineer requirements from system behavior.  At the conclusion of this effort, requirements can be theorized – “Foo must authenticate its server Bar before initiating a bank transfer.” 

Risk analysis can be performed once a plausible set of requirements have been identified.  Threat modeling is a more structured means of performing such an analysis, with the eventual goal of identifying means by which requirements can be violated by an attacker. 

As with requirements analysis, original developers would be a valuable resource to consult.  With or without such help, the first step is to identify how the software works.  In many cases, help is not available and performing this task requires a great deal of effort.  For features of moderate size, this author has spent upwards of a month reading code, using process profiling tools, and walking through the software with a debugger to identify program flow and security-sensitive functionality.

Once completed, actual system behavior should be documented and compared against the requirements theorized.   It might be that the requirements should be re-evaluated (New requirement:  Do not assume that Foo requires server authentication) or the system may need to be changed (New bug:   Foo does not verify the CN for Bar).  At the end, this information should be sufficient to support a comprehensive threat modeling exercise where security requirements, risks, and their mitigations can be documented.

Next Steps

Bringing a legacy feature up to par with its newer kin requires a relatively small number of items:  improved code quality, clear security requirements, and a thorough threat model.  As we have seen, performing even these tasks is quite the effort!  I am sure that it is little comfort to be reminded that accomplishing these tasks has simply laid the foundation, and that the true benefit is that the newly-reviewed legacy feature is able to participate fully in the security processes that remain: reviewing cross-component security requirements and assumptions, comprehensive testing, and incident planning, to name a few.

Unfortunately, there is no silver bullet in security assurance.  The soundness of the design and implementation of legacy software is just as important as in newer software, which is why any complete secure software development process will look backwards as well as forwards.  Feature by feature, from higher priority to lower, the overall security of the software improves as legacy code receives the full security treatment it deserves.

Did you find the silver bullet?  Might you think that defining security requirements is unnecessary?  Perhaps “It is old and has not been attacked yet.” is a valid security strategy!  Please comment below or email me directly at scott@isecpartners.com and share your thoughts.]]> Mon, 27 Oct 2008 14:24:00 +0000 legacy code mature security processes security processes cross-component security requirements security requirements processes code requirements legacy code poses Applying SDL Principles to Legacy Code