Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Netcetera, profile picture
Uploaded byNetcetera
KEY, PDF699 views

ONE Conference: Vulnerabilities in Web Applications

Vulnerabilities in Web Applications discusses common security risks for web applications. It summarizes a study showing that over 60% of cyber attacks target web applications. The document recommends following standards like PCI-DSS and OWASP to integrate security into the software development lifecycle. It also describes how Anonymous hackers exploited SQL injection and password reuse vulnerabilities to compromise HBGary Federal's systems and steal internal data, bringing the company down. The key lessons are that security must be a priority from design through maintenance, and that even small vulnerabilities can have major consequences if not addressed.

Technology◦
Related topics:
web-applications•
Downloaded 16 times
Vulnerabilities in Web Applications Simon Dietschi, Netcetera AG
Why care about (web application) security?
Sources of risks experienced by organizations sampled in the USA (2011) Viruses, worms, trojans Malware Botnets Web attacks Stolen devices Malicious code Malicious insiders Phishing Denial of service 0 25 50 75 100 Ponemon Institute© Research Report, SANS Cyber Security Risks, Web-Hacking-Incident-Database
Motivation • Wake-up call for security awareness • Security as a topic critical to the success of an information system • Insecure web applications in financial, healthcare, power, defense, aviation and other critical infrastructures • More than 60% of all cyber attacks against web applications
Where to start?
Standards, Principals, Guidelines
PCI-DSS Payment card industry data security standard
PCI-DSS in practice • Designed for the payment card industry • Too heavy for projects without the need to be PCI certified • PCI requirements only define the different processes that have to be in place • Does not define how the processes have to be implemented, only the expected outcomes
What can we take from PCI-DSS?
Requirement 6 • Ensure that all system components and software are patched from known vulnerabilities • Incorporate information security throughout the software lifecycle • Develop applications based on secure coding guidelines, prevent coding vulnerabilities during development • In production, address new threads and vulnerabilities on an ongoing basis
OWASP Open web application security project
What can we take from OWASP?
OWASP Top 10 • List of top 10 most critical web application security risks • Covers likelihood and consequence factors, severity • Good start point for developers, designers, architects and organizations
OWASP ASVS • Application Security Verification Standard • Concrete approach for verification of web application security and integration into existing software lifecycle • Level based coverage, customizable depending on the project needs • Approach to become a commercially-workable open standard
Measures & Prevention
SDLC Secure Software Development Lifecycle
Testing, QA, Analysis Design Development Production Acceptance
Define application security requirements by risk level Testing, QA, Analysis Design Development Production Acceptance
Define application Plan how to security meet security requirements by requirements risk level Testing, QA, Analysis Design Development Production Acceptance
Define application Plan how to Implement security meet security secure requirements by requirements architecture risk level Testing, QA, Analysis Design Development Production Acceptance
Define application Plan how to Implement Verify security security meet security secure requirements requirements by requirements architecture risk level Testing, QA, Analysis Design Development Production Acceptance
Define application Plan how to Implement Verify security Fix findings security meet security secure requirements requirements by requirements architecture risk level Testing, QA, Analysis Design Development Production Acceptance
So now we are done?
Ongoing Security • Policies, guidelines • Education, security training, principles, best practices • Design reviews, code reviews, security testing • Vulnerability management, environment hardening
Security V.S. Business needs • Management: “Use remaining project budget for security...” • Security often seen as too expensive and therefore disregarded within a project • Security is a hidden business need too, but who has to pay for it ? • Solution: Integrate security into business needs
HBGary Hack
HBGary V.S. Anonymous • HBGary Federal: • Security company • Provides information security solutions to U.S. government • CEO: Allen Barr
HBGary V.S. Anonymous • Anonymous:
1. Step: SQL-Injection • Custom CMS by third-party company used for hbgaryfederal.com • SQL-Injection over URL was possible: http://www.hbgaryfederal.com/pages.php?pageNav=2&page=27 …pages.php?pageNav=2&page=27;update users set passwd=‘1234’ where username=‘admin’; Code: title=SQL(“select title from page where pageid= $url_param(page)”);
What happened? • Anonymous successfully reseted CMS Admin account • Anonymous took list of usernames, emails, passwords from CMS DB • Password encryption was not strong enough • Anonymous retrieved passwords from HBGary CEO and COO • Responsible at the company that implemented the CMS - fired
Lessons learned • For developers: be aware of SQL-Injection and use salts for password hashes • Enforce sufficient password complexity • Be aware of security, especially if custom or third party software is being used
2. Step: attacking the support server • Password of the COO allowed to remote log into the support server (support.hbgary.com) • Linux with unpatched vulnerability allowed to become root
What happened? • Several backup and research data has been stolen by Anonymous • Backup data was deleted by Anonymous
Lessons learned • Reuse of passwords is very bad • Do not keep sensitive data on servers faced to the internet • Patching known vulnerabilities is very important
3. Step: Compromising Email accounts • Google Apps was used by HBGary Federal as email services • The CEO and COO passwords worked there as well • The CEO account had admin privileges
What happened? • Anonymous locked out HBGary from any email access • Anonymous published over 68k of company emails on the internet • Publication included reputation destructive, internal content
HBGary Hack • Anonymous did some social engineering too • But finally, they brought down HBGary (28. February 2011)
Conclusion • Well known and easy to detect SQL-Injection vulnerability was the root cause • Security is very important, for software, systems and persons • Vulnerabilities can damage reputation or bring down a whole company
To take home • Security is not a skill, it is a mindset • Build security into a web application’s architecture from the start • Keep information security an ongoing and evolving process
Thanks, and stay secure