application vulnerabilities

There are different classes of application vulnerabilities like SQL injection, Buffer Overflow, Stack overflow, Cross-Site scripting and so on.

Categories of dangerous software errors:

• Insecure Interaction between Components, most frequent examples:

1. SQL Injection (CWE-89) [A1 - Injection]
2. OS Command Injection (CWE-78) [ A1 - Injection]
3. Cross-site Scripting (CWE-79) [A3 - Cross Site Scripting (XSS)]
4. Upload dangerous file in system to execute unwanted instructions in the target environment(CWE-434) [A4 - Insecure Direct Object References]
5. Cross-Site Request Forgery (CWE-352) [A8 - Cross Site Request Forgery (CSRF)]
6. Open Redirect (CWE-601) [A10 - Unvalidated Redirects and Forwards]

• Risky Resource Management, most frequent examples:

1. Classic Buffer Overflow(CWE-120)
2. Path Traversal (CWE-22) [A4 - Insecure Direct Object References]
3. Download of Code Without Integrity Check(CWE-494)
4. Inclusion of Functionality from Untrusted Control Sphere (CWE-829) [A4 - Insecure Direct Object References]
5. Use of Potentially Dangerous Function (CWE-676)
6. Incorrect Calculation of Buffer Size(CWE-131)
7. Uncontrolled Format String (CWE-134)
8. Integer Overflow or Wraparound (CWE-190)

• Porous Defenses, most frequent examples:

1. Missing Authentication for Critical Function (CWE-306) [A2 - Broken Authentication and Session Management]
2. Missing Authorization (CWE-862)[A4 - Insecure Direct Object References] 
3. Use of Hard-coded Credentials (CWE-798) [A2 - Broken Authentication and Session Management]
4. Missing Encryption of Sensitive Data (CWE-311) [A6 - Sensitive Data Exposure]
5. Reliance on Untrusted Inputs in a Security Decision (CWE-807)
6. Execution with Unnecessary Privileges (CWE-250) [A5 - Security Misconfiguration]
7. Incorrect Authorization (CWE-863) [A4 - Insecure Direct Object References] [A7 - Missing Function Level Access Control]
8. Incorrect Permission Assignment for Critical Resource (CWE-732) [A5 - Security Misconfiguration]
9. Use of a Broken or Risky Cryptographic Algorithm (CWE-327) [A6 - Sensitive Data Exposure]
10. Improper Restriction of Excessive Authentication Attempts (CWE-307) [A2 - Broken Authentication and Session Management]
11. Use of a One-Way Hash without a Salt (CWE-759) [A6 - Sensitive Data Exposure]

Note: [A9 Using Components with Known Vulnerabilities] is not mapped to any Common Weakness Enumeration (CWE) documented.

Select at least two application vulnerabilities and explain what do they mean and discuss how you would mitigate them?

• CWE-250: Execution with Unnecessary Privileges

This is on 11th rank in top 25 CWE list. In this, the software performs an operation at a privilege level that is higher than the minimum level required which creates new weaknesses or amplifies the consequences of other weaknesses. This counted under OWASP A5 - Security Misconfiguration.

Mitigation:

1. Under Architecture and Design; Operation phases, run code under lowest privileges. Create isolated accounts.
2. Under Architecture and Design phase, identify the functionality that requires additional privileges.  Raise privileges as late as possible, and drop them as soon as possible, protecting all possible communication channels that could interact with the privileged code.
3. Under phase Implementation,  extensive input validation for any privileged code
4. Under Implementation phase, make sure calls to remove permissions will not break.
5. Under Implementation phase, explicitly allow those actions while denying all else.
6. Under Operation; System Configuration phases, follow hardened configuration guide to limit the attack surface and potential risk of deployed software.

• CWE-601: URL Redirection to Untrusted Site ('Open Redirect')

This is 22 in top 25 list. If a website knowingly or unknowing allows user/attacker to input external website address and allow redirect then it is Open Redirect vulnerability. This comes under OWASP A10 - Unvalidated Redirects and Forwards

Mitigation:

1. Assume all inputs are malicious while implementation phase.
2. During Architecture and Design phase user must be planned to be informed while leaving current application in a very clear and visible manner.
3. During Architecture and Design phase, if possible inputs are limited, free to type inputs should be avoided.
4. During Architecture and Design phase, ensure that redirects are confirmed to be originated from inside the app by using legitimate encryption/ random numbers.
5. During Architecture and Design; Implementation, highlight all the possible input methods including indirect methods like api calls , external systems cookies and so on.
6. During Operation phase, use application firewall.

How would you check for SQL Injections?

CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Detecting exploiting and avoiding SQL Injection is consider being simple and it’s No 1 in to CWE list, categorized under OWASP A1 - Injection. Without sanitizing inputs from external system/users, inputs may be interpreted as SQL commands and executed to reveal internal hidden information or change sensitive data.

SQL injection could be avoided using Parameterized Queries, using Stored Procedures, sanitizing user inputs, whitelist input validation and minimizing privileges assigned to every database account.

 Various automated dynamic/static analysis tools are available to detect SQL injection but it should be taken care of at Architecture and Design, Implementation and operation phases with due care.

 During Architecture and Design phase various frameworks maybe used which prevent SQL injection, separation b/w data and code could be enforced, least permission rule may be enforced, client side and server side validations could be enforced, inputs may be limited by from predefined options if possible and so on.

 During Implementation phase, all inputs must be assumed to be dirty, escape or filter all characters that do not pass predefined whitelist, strict error handling and error messages, legitimate output messages to operation which won't reveal internal specifications of the system and so on.

During Operation phase least permission rule may be enforced and appropriate firewall rules may be enforced.

OWASP Top Ten (2013)	Common Weakness Enumeration
A1-Injection
	CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
	CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
	CWE-88: Argument Injection or Modification
	CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
	CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
	CWE-91: XML Injection (aka Blind XPath Injection)
A2-Broken Authentication and Session Management
	CWE-256: Plaintext Storage of a Password
	CWE-287: Improper Authentication
	CWE-311: Missing Encryption of Sensitive Data
	CWE-319: Cleartext Transmission of Sensitive Information
	CWE-384: Session Fixation
	CWE-522: Insufficiently Protected Credentials
	CWE-523: Unprotected Transport of Credentials
	CWE-613: Insufficient Session Expiration
	CWE-620: Unverified Password Change
	CWE-640: Weak Password Recovery Mechanism for Forgotten Password
A3-Cross-Site Scripting (XSS)
	CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
A4-Insecure Direct Object References
	CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
	CWE-99: Improper Control of Resource Identifiers ('Resource Injection')
	CWE-639: Authorization Bypass Through User-Controlled Key
A5-Security Misconfiguration
	CWE-2: Environment
	CWE-16: Configuration
	CWE-209: Information Exposure Through an Error Message
	CWE-215: Information Exposure Through Debug Information
	CWE-548: Information Exposure Through Directory Listing
A6-Sensitive Data Exposure
	CWE-310: Cryptographic Issues
	CWE-311: Missing Encryption of Sensitive Data
	CWE-312: Cleartext Storage of Sensitive Information
	CWE-319: Cleartext Transmission of Sensitive Information
	CWE-320: Key Management Errors
	CWE-325: Missing Required Cryptographic Step
	CWE-326: Inadequate Encryption Strength
	CWE-327: Use of a Broken or Risky Cryptographic Algorithm
	CWE-328: Reversible One-Way Hash
A7-Missing Function Level Access Control
	CWE-285: Improper Authorization
	CWE-287: Improper Authentication
A8-Cross-Site Request Forgery (CSRF)
	Cross-Site Request Forgery (CWE-352)
A9 - Using Components with Known Vulnerabilities
	unusual human error
A10 - Unvalidated Redirects and Forwards
	CWE-601: URL Redirection to Untrusted Site ('Open Redirect')

WEP | WPA PSK

The protocol IEEE 802.11 using WEP is very weak.

The three core deficiencies with Wired Equivalent Privacy (WEP) are the use of static encryption keys (Rivest Cipher 4 {RC4} algorithm, which is a stream-symmetric cipher), the ineffective use of initialization vectors (the same IV values are used over and over again), and the lack of packet integrity Assurance (flipping specific bits and altering the Integrity Check Value). 

Also briefly discuss WPA PSK mode. Is it hackable?

1. Wi-Fi Protected Access (WPA) was an intermediate measure to take the place of WEP, pending the availability of the full IEEE 802.11i standard. WPA2 replaced WPA and implements the mandatory elements of IEEE 802.11i.  If authentication server (AP) like Remote Authentication Dial-In User Service (RADIUS), is used its WPA-Enterprise.  If pre-shared key is used in WPA, its Wi-Fi Protected Access pre-shared key (WPA PSK). A user cannot make network call unless he is fully authenticated ( true only in WPA-Enterprise, not in PSK), Further at lower layers, it uses Temporal Key Integrity Protocol (TKIP) [RC4] and Counter Mode Cipher Block Chaining Message Authentication Code Protocol, Counter Mode CBC-MAC Protocol (CCMP) [AES algorithm].  AES (under WPA2) is a more appropriate algorithm for wireless than RC4 (under WPA). 
2. Cracking WPA2-PSK Passwords with Cowpatty & Aircrack-Ng

DES (Data Encryption Standard) is weak because of the Key size but what else make DES weak?

1. Key Complement weakness reduces brute force attack to require 2⁵⁵ possibilities.

2. If the possibilities of data what we are encrypting are limited, it's comparatively easier (not easy).

2.1. Differential cryptanalysis: To break the full 16 rounds, differential cryptanalysis requires 2⁴⁹ chosen plaintexts.

2.2. Linear cryptanalysis: FPGA Implementation of the Linear Cryptanalysis was able to return DES key in 12-15 hrs.

SDLC - At what stage in the cycle do you "bring up" security?

During the development life cycle, it is important to plan for security integration. At what stage in the cycle do you "bring up" security?

SDLC could be taken as system development life cycle (Initiation, Acquisition/development, Implementation, Operation/maintenance, and Disposal) or software development life cycle (Requirements gathering, Design, Development, Testing/Validation, Release/Maintenance in general), since basic needs for computer systems may be different from developing software securely. As long as we are following a structure and nothing is being missed on security side and various steps involved, we are good.

Overall, whether we talk about system development life cycle or software development life cycle, security must be integrated in each and every phase involved.

What is Secure Software Development? 

When security of the application is being on priority while each phase of development and all the possible measures have been taken, keeping in mind Confidentiality availability and integrity of the app right from beginning to end, no matter what model we follow, it's Secure Software Development.

As per Microsoft , "The Security Development Lifecycle (SDL) is a software development process that helps developers build more secure software and address security compliance requirements while reducing development cost"

Phase 1 Training

1. Core Security Training

Phase 2 Requirements

2. Establish Security and Privacy Requirements

3. Create Quality Gates/Bug Bars

4. Perform Security and Privacy Risk Assessments

Phase 3 Design

5. Establish Design Requirements

6. Perform Attack Surface Analysis/ Reduction

7. Use Threat Modeling

Phase 4 Implementation

8. Use Approved Tools

9. Deprecate Unsafe Functions

10. Perform Static Analysis

Phase 5 Verification

11. Perform Static Analysis

12. Perform Fuzz Testing

13. Conduct Attack Surface Review

Phase 6 Release

14. Create an Incident Response Plan

15. Conduct Final Security Review

16. Certify Release and Archive

Phase 7 Response

17. Execute Incident Response Plan

On the similar  lines, Web Application Security Project (OWASP)  talks about many recommendations that could integrate in each phase.


Web Application Security Consortium (WASC) , talks about top attack methods against which application must be safeguard under Secure Software Development.

who is using my Wi-Fi !!!

Wireless Networks are predominantly week. Suppose you are wearing your hacker's hat and want to experiment hacking into a Wireless signal/network, where would you start?

Wireless meant to be any communication without physical connection between source and destination like Wi-Fi, mobile networks, Bluetooth, IrDA, via satellite or anything like that. But in general terms when we talk about wireless, mostly it is Wi-Fi which we target to crack, even though other communication channels may also be victims of fraud.

Long time back, I got suspicious that my Wi-Fi at home is compromised and someone is using my bandwidth, since Comcast sent me a text message that I crossed 300 GB. Even when all the device - laptop, security cameras, smart TV, printer, phones iPad at home were switched off, my cable modem used to blink [the data transfer blue light] continuously when connected to Wi-Fi router, I thought someone is using my Wi-Fi router. My Wi-Fi router, I bought from Craigslist, so I thought its software was compromised, I did a little googling and installed dd-wrt via firmware upgrade, still it blinked. I applied MAC filtering still it did; I hide the SSID and changed password to 41characters long, applied WPA-2 personal, still it did. For one month we survived only on direct connection from cable modem to single device, either TV or laptop when used, no Wi-Fi at home at all. Later I realized the culprit is smart TV and netflix, so ignored the blinking of cable modem henceforth.

And now this discussion makes me think, all measures I took to secure Wi-Fi were not full proof and even the mac address can be spoofed!!! hfff….

To break-in Wi-Fi, I must have a virtual or actual target, if this is a virtual target [created by me], half of the story is worthless, and the moment I am 100% sure about underlying mechanism used to secure a Wi-Fi network, half of the battle is done. Tools like Kismet and NetStumbler [page 728 Shon Harris] could help understand what the Wi-Fi is broadcasted from, what’s the underlying technology used. After that I have tools like AirSnort and WEP-Crack [page 719, 728 Shon Harris]. aircrack-ng included in backTrack, cowpatty or reaver are some other tools that may be used.

But before starting using these tools I must be aware of basic terms and technologies ( like network standards, how Wi-Fi actually works, WEP, WPA2-PSK, WPA2-AES, channels and which channels can be used for rogue access points and so on), what may be the physical tools required ( like Wi-Fi adapters, Attennas or simply a routed mobile device !!), and last but not the least - make sure the tools I am planning to use or downloaded "FREE" are not backdoors to my test machine.

References

• Hacking Wi-Fi is child’s play! 7-year-old shows how easy it is to break into a public network in less than 11 MINUTES
• Radio Attack Lets Hackers Steal 24 Different Car Models
• I got your one time verification code, How?
• Spoof the MAC Address of Bluetooth Keyboard
• Bluetooth hacking tools
• WiFi Hacking

Security: How many $'s per Lbs. ?

I am sure all of you remember Data Theft from Home Depot, Target and OPM. This is just a short list. These organizations have fully mature IT security organizations. What do you think they were doing wrong to allow such intrusions?

We may have "fully mature" security in place, but if leanings and change in the way we tackle cyber-attacks is governed by actual exploits, certainly there is something wrong.

1. Responsibility. Like Home Depot, Target and OPM, we might be able to handover bad name after an incident to a vendor, but actual loss will not be recovered. For example in case of OPM, multiple applications used shared resources, if OPM had proper infrastructure in place, when one system is hacked, it would have stopped there. Same is the case with Home Depot and Target; boundaries of access were not clearly defined. All resources and information must have been given clear category and classification in all the cases.

2. Weakest link in line of defense defines how much secure we are, say in case of OPM, security information and event management partially covered monitoring of the key components. OPM allowed users to gain access without two factor authentication at some places, at others it was implemented.

3. it’s not always possible to build the whole ship in-house and assume that it won't fail.  On the other hand security is not something for which we could pay from Organization's budget, make our own personal benefit and get rid of on papers. We need services from third parties and this must not be the weak link, now to endorse a third party vendor and his services/ products, holistic processes and expertise must be attained by us. Say in case of Target, they are blaming the air conditioner firm, but who brought them in? Was target not concerned at all, they might be vulnerable to attacks.

4. We may not be termed as a secured IT organization, by only putting guidelines and secured architectures on paper, what does matter also, how well they are followed. For example in case of OPM, the vulnerabilities exploited, it was not like, they were never aware of anything at all, many loop holes were present since many years and reported, but no action taken. Reason, mentality of being lazy: the system is still running, will see later, ignore the warnings.

5. Spend Wisely. Gaining a shield against hackers may not be cheaper or one time investments, we must have to constantly involved in penetration testing and be aware of where the technology is moving, opening new secret doors for intruders. It will also need constant expenditure on hiring right talent and spending on upgrading skills of existing employee. Does this means, if we have a budget for security testing and we outsource it to same vendor, who will copy paste what he found during last cycle and we are done and my part of bribe is 100% sure ? No, findings must be given a value in terms of loss that might occur and fixed well in time. To get deeper analysis, we might also rotate third party vendors who do security testing.

6. How about vulnerabilities found by penetration testing vendors getting leaked to hackers, this is one of the nightmares which OPM may have experienced. Here comes the smartness of decision maker, how to tackle it. Involving too less employees in this activity of reviews might mean meager reviews and the right eyes being closed with lid of $'s. Involving too many may itself introduce vulnerabilities and risk to organization as a whole. Well said that 8th layer might be the weakest layer.

7. Fearless and full of doubts. Based on vulnerabilities reports, rebuilding the whole system sometimes might be advisable with some extra expenditure, than to keep on patching old unsecured system.

References

Weakest point of entry: http://www.computerworld.com/article/2487425/cybercrime-hacking/target-breach-happened-because-of-a-basic-network-segmentation-error.html

Zero-day vulnerability: http://www.networkworld.com/article/2845620/microsoft-subnet/home-depot-it-get-hacked-blame-windows-switch-execs-to-macbooks.html

Blame China, I forgot to zip my ass:

http://wapo.st/1XHtMof

vs

http://arstechnica.com/security/2015/06/epic-fail-how-opm-hackers-tapped-the-mother-lode-of-espionage-data/?comments=1