In the wake of the statute, numerous computer security companies announced their relocation out of Germany. However, to date there have been no prosecutions under this provision, and only a small amount of reported litigation. So far, the statute that scared the bejeezus out of the legitimate security community has not deterred or diminished the spread of hacker tools in Germany or anywhere else and has created legal uncertainty about potential liability. The German law came out of the February 24, 2005 Council of Europe’s Convention on Cybercrime ( pdf ). This convention compelled signatories to adopt implement legislation that, among other things, defined cybercrime, provided procedures for collecting evidence, and create a framework for international cooperation on cybercrime investigations. Article 6 of the Treaty required signatories to make it a crime to intentionally engage in: the production, sale, procurement for use, import, distribution or otherwise making available of . . . a device, including a computer program, designed or adapted primarily for the purpose of committing [a computer crime] [or] a computer password, access code, or similar data by which the whole or any part of a computer system is capable of being accessed, with intent that it be used for the purpose of committing [a computer crime]. The treaty language goes on to note that it would not be a crime to produce, sell or distribute a “hacker tool” if it is for a legitimate security purpose. Of Tools and Authors Germany adopted Section 202(c) of its penal code in an effort to comply with its obligations under the COE Cybercrime Convention. The German law makes it an offense to create, obtain or distribute any computer program that violates its cybercrime laws. The penalty set by law is up to a year in jail and fines. The statute is broad enough to cover the creation and transmission of a host of programs — whether in hardware, software or both — including password crackers, decryption programs, penetration testing tools, and other common security tools, if it is done as a way of preparing to commit a cybercrime. The statute requires that the commission of the criminal offense be the express purpose of the computer program. The intent of the programmer does not, apparently, matter. Worded differently, the statute could have focused on the intent of the author or distributor, and not on the purpose of the tool. The law still would have left open the question of whether committing a crime had to be the sole purpose, or just one of the purposes, of the author or distributor of the hacker tools. The German law was intended to criminalize only the creation or distribution of devices (including software) that were “designed or adapted primarily for the purpose of committing [cybercrime] offences.” However, these offenses include things like unauthorized access and destruction. A tool does not know whether the access is authorized or not. It does not know whether the file destruction is with or without the consent of the file owner. Tools primarily designed to find and exploit vulnerabilities are commonly used by security professionals to test and secure software, networks, and applications. They are, in fact, primarily designed to do things which, if not for the authorization of the network owners, would be a violation of the statute. Moreover, whether the use of tools without the authorization of the owner of the hardware or software is “authorized” is hardly a neat question. Apple recently argued (a href=”http://www.copyright.gov/1201/2008/responses/apple-inc-31.pdf”> pdf) that the use of software by the owner of an iPhone or iPod Touch to jailbreak their own phone violated the provisions of the U.S. Digital Millennium Copyright Act, and was therefore unlawful and unauthorized. Under this interpretation, the creation or distribution of such software, which would be primarily designed to make an “unauthorized” access to your own phone, would be a crime. Terms of Service, Terms of Use, and End User License Agreements would set out the conditions under which the licensee could test the security of the software, hardware or other products they were buying or licensing. A notorious case of a few years back involved Network Associates EULA which prohibited both benchmarking and the publication of the results of benchmarking. Thus, contract terms, which limit the right to do security testing, are then used to render testing tools into felonies. Read the original here: Mark Rasch: Hacker-Tool Law Still Does Little

Continue Reading

Obviously this hasn’t proven to be the case. Even though intrusion-detection systems are readily available, many organizations still don’t use them effectively. Too often the IDS sits without maintenance or updates, poorly monitored, generating alerts that are completely irrelevant to the daily work of the security and staff. The key to realizing the benefits an IDS offers is to focus less on the technology, and more on how it will be used by a security analyst. This article explores the discipline of intrusion analysis, focusing primarily on techniques to extend IDS capabilities beyond simple alert data into a tool for attack indications and warning, policy enforcement, and network defense. Emphasize the Analyst, not the IDS By now pretty much everyone in the security industry understands the basic ideas behind an IDS: monitor observable behavior, conduct some kind of automated test to determine if it is potentially malicious, and alert the analyst as required. While the security industry and professionals continue to seek the “Best in Class” solution to all IDS needs, the reality is there is no solution that eliminates reliance on human decision-making as part of the analysis process. Too many companies forget this, investing heavily in the infrastructure without making a comparable investment in their analytical personnel. Even large companies make the mistake of relying on the machine rather than the analyst. From a balance-sheet perspective, it makes a weird sort of sense. On one hand, you have a capital asset you can depreciate annually, while on the other, you have a recurring expense in training. Many companies simply stop right there. The reality, however, is that a sufficiently skilled analyst can analyze network or host data with even the most rudimentary of tools. In fact, that’s how the industry got started with tools as simple as tcpdump , shadow , and the early versions of snort . This is one of the classic mistakes in deploying IDS: over-reliance on the technology. Whether the solution is network or host-based, whether it works on a traffic analysis, signature matching, anomaly detection, or a hybrid model, ultimately all IDS does is present data of potential interest to a human analyst. One good model for training IDS analysts can be found in the Department of Defense’s Information Assurance Workforce Improvement Program, documented in DoD Instruction 8570.01-M . This program establishes a training plan for Computer Network Defense (CND) analysts that yields an extremely effective skill set for IDS analysis, regardless of the technology used in the enterprise. Using this standard, a workforce model might look like the table below. Table 1 – A model for a security-analyst workforce Pre-Deployment Planning Many times companies deploy IDS too early. Before investing heavily in an IDS solution, it is a good idea to have a security program and architecture for it to operate within. Originally posted here: Infocus: Enterprise Intrusion Analysis, Part One

Continue Reading

Data Recovery on Linux and ext3 Abe Getchell 2008-10-03 This article discusses the process of recovering deleted data from an ext3 partition, on a system running Linux, using a process called data carving. This basic technique is useful in any number of situations, such as recovering data that has been accidentally deleted by a user, information removed in an attempt to erase signs of a system intrusion that could be used to track the source, or data erased by an end-user attempting to cover up an acceptable use policy infraction. This article assumes that you have a basic understanding of ext3 and the inner workings of filesystems. It is important to note that there is a certain amount of risk associated with this process. When performed improperly, the data you are attempting to recover, or other data stored on the system, could be permanently lost. While this technique is quite accurate most of the time, and very useful in any number of different situations, it is not “forensically sound” and will not hold up legally for use in court. Special software, hardware, and procedures — or professional services — are a must in situations when legal action is required. The tools used in this article are freely available and can be downloaded from their respective websites. The basic recovery process In this section we will go step-by-step through the data recovery process and describe the tools, and their options, in detail. We start by listing a directory below. [abe@abe-laptop test]$ ls -al total 27 drwxrwxr-x 2 abe abe 4096 2008-03-29 17:48 . drwx—— 71 abe abe 4096 2008-03-29 17:47 .. -rwxr–r– 1 abe abe 42736 2008-03-29 17:47 weimaraner1.jpg In the listing above we can see that there is a file named weimaraner1.jpg in the test directory. This is a picture of my dog. I don’t want to delete it. I like my dog. [abe@abe-laptop test]$ rm -f * Here we can see I am deleting it. Whoops! Sorry buddy. Let’s gather some basic information about the system so we can begin the recovery process. [abe@abe-laptop test]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 71G 14G 53G 21% / /dev/sda1 99M 19M 76M 20% /boot tmpfs 1007M 12K 1007M 1% /dev/shm /dev/sdb1 887M 152M 735M 18% /media/PUBLIC Here we see that the full path to the test directory (which is /home/abe/test ) is part of the / filesystem, represented by the device file /dev/sda2 . [abe@abe-laptop test]$ su – Password: [root@abe-laptop ~]# debugfs /dev/sda2 Using su to gain root access, we can start the debugfs program giving it the target of /dev/sda2 . The debugfs program is an interactive file system debugger that is installed by default with most common Linux distributions. This program is used to manually examine and change the state of a filesystem. In our situation, we’re going to use this program to determine the inode which stored information about the deleted file and to what block group the deleted file belonged. debugfs 1.40.4 (31-Dec-2007) debugfs: cd /home/abe/test debugfs: ls -d 1835327 (12) . 65538 (4084) .. (4072) weimaraner1.jpg After debugfs starts, we cd into /home/abe/test and run the ls -d command. This command shows us all deleted entries in the current directory. The output shows us that we have one deleted entry and that its inode number is 1835328 — that is, the number between the angular brackets. debugfs: imap Inode 1835328 is part of block group 56 located at block 1835019, offset 0×0f80 The next command we want to run is imap , giving it the inode number above so we can determine to which block group the file belonged. We see by the output that it belonged to block group 56. debugfs: stats [...lots of output...] Blocks per group: 32768 [...lots of output...] debugfs: q Running the stats command will generate a lot of output. The only data we are interested in from this list, however, is the number of blocks per group. In this case, and most cases, it’s 32768. Now we have enough data to be able to determine the specific set of blocks in which the data resided. We’re done with debugfs now, so we type q to quit. [root@abe-laptop ~]# dls /dev/sda2 1835008-1867775 > /media/PUBLIC/block.dat Read the original here: Infocus: Data Recovery on Linux and ext3

Continue Reading

However, criminals have changed the way they use bot agents, with larger botnets commonly used for another kind of mass-attack: exploiting Web site vulnerabilities to send commands to the back-end database, an attack known as SQL injection. While SQL injection itself is a rather old class of Internet attack, it has proved to be an extremely successful vector for compromising Web applications and retrieving confidential business data, as evidenced in the most recent court documents filed following the Heartland Payment Systems and Hannaford data breaches . Moreover, year on year the number of SQL injection attacks have increased. The attacks rose 50 percent in the first quarter of 2009, and then doubled in the second quarter. While most SQL-injection (SQLi) attacks have traditionally been conducted manually using automated tools, bot clients have become more sophisticated and have inherited a wider variety of plug-in features. The overall trend appears to be towards distributed attacks that leverage existing botnet infrastructures, offering efficiencies in targeted SQL injection attacks and, most importantly, massively reducing the time needed to both compromise the back-end database server and extract valuable information. As such, the probability of continued increases in database attacks is high. Looking back, the first criminals to apply SQL injection to botnets appear to have wanted to increase botnet propagation through drive-by-download attacks. This tactic exploited the back-end databases of vulnerable Web applications to inject malicious HTML frames into dynamic page-generation repositories. At the same time, individual bot agents had to be updated with new modules capable of performing specialized SQL injection attacks. For example, in mid-2008, the Asprox botnet was updated with a module called msscntr32.exe which contained an auto-seeking database attack kit. Early attacks would search Google for vulnerable Web applications, but the process often targeted and exploited multiple times by bot agents from the same botnet. This high degree of overlap did not matter much to botnet operators because counts of 100,000 successful frame injections were not uncommon at the time. In fact, a handful of operators managed to reach volumes of over a million successful compromises due to particularly well-constructed exploits for widespread and vulnerable Web application platforms. Bot operators were quick to improve their SQL injection attack modules, and it was not long before the duplication between bot agents was largely eliminated. Several of the modules now distributed to, or embedded within, bot agents employ improved tactics for attacks and make greater use of command-and-control coordination. Key to this evolution is the systems’ ability to operate from a master list of potentially vulnerable URLs harvested from Google, which the central server doled out. SQL injection tools and tactics have continued to evolve. Improved scripting language logic within bot agents and the adoption of more advanced scripting languages on the compromised host allow the agents some autonomy when constructing an attack. Some of this sophistication has clearly been adapted from password brute-force tactics, and some SQL-injection modules are capable of intelligently generating dynamic attack strings to enumerate and eventually exploit vulnerable Web applications. Several botnets already have the capability to fully enumerate databases of vulnerable Web applications and to automatically extract large volumes of confidential or personal data by simultaneously employing multiple bot agents against a single vulnerable Web application. The complexity of database systems and their temperamental responses to the application of patches and security updates often results in a kid-glove approach by system operators in keeping them secure. However delays in patching backend databases and the trusted applications that interface with them are increasingly seized upon by hackers, making it critical for organizations to hone their processes and patch systems within hours of a solution becoming available. Despite this, most database vulnerabilities exploited by SQL injection lie predominantly within the custom routines and processing logic of the public application. Organizations need to regularly assess their applications for newly introduced vulnerabilities and original attack vectors. While developing fixes for these kinds of custom vulnerabilities can take time, a mix of in-bound request filtering and backend rate-limiting technologies can help slow down or prevent many automated attack vectors from being successful while more specific security patches are tested and deployed. Unfortunately, the bot operators hold the upper hand over those responsible for protecting corporate Web applications. The speed at which attacks can be launched using new exploit material will most often defeat those responsible for patching newly disclosed vulnerabilities. Meanwhile, the rapid pace with which even smaller botnets can brute-force database authentication credentials and enumerate a database is staggering. In short, the SQL injection technologies used by botnet operators will continue to advance. Their design quite intentionally makes it impractical to block or filter based upon the attackers’ IP addresses. For the time being, it’s still mostly a green-field environment for botnet operators. Organizations seeking to defuse these threats must reevaluate their Web application defenses, ensuring that any intrusion prevention systems (IPS) or Web application firewall (WAF) technologies are robust against high-volume and obfuscated SQL-injection strings. Several top-tier intrusion prevention technologies have already begun to move on from signature-based systems and have been incorporating more advanced detection algorithms. That said, the arms war is only just beginning over this emerging technique. More heavily obfuscated SQL attack formats will continue to evolve as the technologies capable of protecting against an attack become widely deployed. Until then we can all expect to hear more frequently about data breaches due to successful botnet attacks. Read the rest here: Gunter Ollmann: Time to Squish SQL Injection

Continue Reading

While we speak of financial transactions in the hundreds of billions of dollars as being something as routine as brushing our teeth, we question the value of programs that cost in the single-digit millions and quibble with friends over dollars. Similarly, there are many problems in our industry that, when explained to an outsider, sound like they should have been solved decades ago. It is only when we relate the number of systems that need to be considered in the repair that we truly communicate the difficulty of the problem. This is to be expected — it is irrational to expect people to understand scale without training. After all, we are not primed for the task.  We evolved in hunter-gatherer tribes consisting of less than a hundred people, and developed number systems derived from the count of immediately visible objects, namely the number of fingerers on our two hands. If we are unable to communicate the scale of a given security issue, we are unable to communicate the actual threat we face. Problems change dramatically as you move upwards in scale, and what may be a tractable issue when considered on a case-by-case basis becomes a major issue when multiplied by a billion instances. A reason why computer security is a challenging discipline is precisely because of the scale of the issues we now face. For example, antivirus software works pretty well on an individual level. Let’s assume that the commonly available antivirus products provide 99.8 percent effectiveness against threats. Granted, this number is wildly inflated, but it is useful for the sake of argument. If a single computer user faces a novel piece of malware once a week, they would on average have to wait almost seven years before they were infected. When brought up to scale, the size of the problem is a bit more sobering. Analysts currently estimate that there are around one billion computers in the world, leaving 2 million computers vulnerable to attack at any given moment. Even if only 10 percent of the systems were connected to the Internet and vulnerable to the infection, we would expect 200,000 new infections every week, given a 99.8-percent protection rate. That forms the basis of quite a sizable botnet. The cost of cleanup is equally disconcerting. Heavily infected systems require a fair amount of manual labor to bring back to a clean state. If we assume it costs around $100 per system in professional services to remediate the infection, we end up with a final cost of around $20 million spread across the compromised user base. Similar examples can be found in the massive cleanup operation that software developers have undertaken to fix unsafe code that could lead to security vulnerabilities. Changing a single call to strcpy() or strcat() to strncpy() or strncat() may take a few seconds of typing and a minute of testing to fix a small application. If we consider the number of places this had to be addressed in the billions of lines of legacy code that were already in production and deployed in numerous locations, we can understand why the repair work has taken tens of thousands of man years and a better part of a decade to complete. Many of these issues of scale are inherent properties of distributed systems. The market decided years ago that the increased flexibility and elimination of single points of failure afforded by a large number of decentralized systems was preferable to a limited number of “mainframe” systems. We accepted a tradeoff, however, that the per-user cost of system management skyrocketed, and the corresponding cost of repairing security problems became prohibitive. Users are turning away from distributed software and once again adopting centralized applications in the form of web-based software-as-a-service (SaaS) offerings. It will be easier for administrators to repair security issues inside these isolated walled gardens than it would be to remediate software on everyone’s endpoint host. However, this does not solve the malware problem by any means, as the endpoints used to connect to these centralized services will still be compromised. Recentralization may make it easier to provide a localized band-aide, but it does nothing to fix the continuing large-scale security issues that persist on the endpoint. In the end, consumers of our products and services want us to tell them we can “solve” a class of security problems, be it computer viruses or code vulnerabilities. The sheer number of locations that we are required to touch to prevent or repair a security event means that we can never eliminate an issue. The best our profession can hope to do is create applications and policies that will minimize the pain until the consumer’s attention, and the attacker’s attention for that matter, is drawn to a new area. This isn’t defeatism; this is the reality in which we must operate. Visit link: Adam O’Donnell: The Scale of Security

Continue Reading

The Zero Day Initiative, TippingPoint’s bug bounty program, spends 30 percent of its effort helping Microsoft mitigate bugs in its Windows operating system and applications, according to data posted online on Thursday. The data, part of a presentation given by ZDI’s Pedram Amini last month, shows that about a quarter of the bugs accepted by ZDI since its launch in August of 2005 were vulnerabilities in Microsoft software. The group has only accepted about 30 percent of the 1,900 flaws submitted by researchers for all software. “That’s 33 Microsoft critical issues we are responsible for disclosing on average per year,” Amini wrote on ZDI’s blog. “As Microsoft accounts for most of our purchases it is no surprise that they account for most of our expenditures as well — 30 percent.” Flaws in Apple software came a distant second to Microsoft, accounting for only 8 percent of the group’s research expenditures, he stated. The research also showed that the Mozilla Foundation led the industry with the fastest vendor response time overall. The developer of the Firefox browser averaged 48 days from notification to patch. Apple came in second, with an overall average of 91 days from notification to patch. Microsoft hovered at the center of the pack at 197 days, while Symantec, the owner of SecurityFocus , sported the worst performance — 307 days on average. Hewlett-Packard, Microsoft and IBM posted records for the longest time to fix a vulnerability. HP placed first and second with two vulnerabilities that continue to be outstanding at 1,071 days and 911 days. Microsoft held the third and fourth positions with two vulnerabilities, since patched, that had remained outstanding for 875 days and 866 days, respectively. IBM’s worst response time is an issue that remains outstanding after 847 days. “The presented data was our first unveiling of a vendor ‘report card,’” stated Amini. “Within the next month or so, we intend on creating a permanent home on the ZDI website with all these statistics and more.” If you have tips or insights on this topic, please contact SecurityFocus . Posted by: Robert Lemos Read the original here: Brief: Vulnerability sales help secure Microsoft

Continue Reading

Sensitive gov’t docs leaked over peer-to-peer Published: 2009-10-30 The Congressional Committee on Standards of Official Conduct confirmed on Thursday that sensitive files from the group’s deliberations had been leaked to the public via a peer-to-peer file sharing network. Some 30 members of the House of Representatives and staff members are currently being investigated by the bi-partisan group of representatives, according to a confidential report prepared by the committee in July and leaked inadvertently by a staff member. The 22-page report summarizes the investigations of the ethics committee, according to an article in the Washington Post . “Our initial review suggests that this unlawful access to confidential information involved the use of peer-to-peer file sharing software on the personal computer of a junior staffer, who is no longer employed by the Committee, while working from home,” the committee said in a statement issued on Thursday. “The potential exposure is limited to several specific documents.” The security slip is the latest by members of Congress. Despite holding multiple hearings on the failings of federal agencies to secure their systems, multiple members of Congress have had their own systems compromised and data stolen . In 2006, a staff member of a Republican lawmaker attempted to hire hackers to change a college grade, but fell prey to practical jokers at Attrition.org. In another incident in 2004, two Republican staffers accessed thousands of confidential Democratic memos and leaked them to colleagues. In the latest incident, the committee warned colleagues to take care with confidential documents. “Although peer-to-peer technology may offer benefits to the users of such networks — whether consumers, businesses or government — they should also be aware of (the) risks that may be associates with their use,” the committee said in its statement. If you have tips or insights on this topic, please contact SecurityFocus . Posted by: Robert Lemos Visit link: Brief: Sensitive gov’t docs leaked over peer-to-peer

Continue Reading