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