Thursday, July 21, 2016

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] [A8 - Failure to Restrict URL Access]
  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.
  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
  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.

Wednesday, July 20, 2016


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 255 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 249 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.

Wednesday, July 6, 2016

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.


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.


Blame China, I forgot to zip my ass:

OWASP TOP 10 - A5-Security Misconfiguration

Please focus on A5 -
Explain how you would mitigate.

Identify threat sources
An anonymous user, a user with less privileges entering system intending to perform higher privileged action, or an employee getting benefited without revealing his own identity may try to exploit security misconfigurations
Identify events 
default accounts being used to access, downloading unprotected files dues to misconfiguration, getting content authorized to a user of higher privileges, using a feature available due to misconfiguration, exposure of logs to user since they were configured to be created in wrong place, download code files and reverse engineering them, more detailed error messages be used by hackers, hackers exploiting server technology being exposed in the html source served to client machine and so on. 
Identify Vulnerabilities
presence of default access accounts, presence of unprotected files, leaving misconfiguration which allows lesser privileged user to get more secured content/ function, presence of logs in public library or available outside server/without authentication,  unnecessary ports being kept open/default ports being used, availability of code files to be downloaded, exposing error message in detail to end user, exposing server technology in headers or html rendered and so on. 
Determine Likelihood of Occurrence 
determine how much is the likelihood of exploitation of detected vulnerabilities. 
Determine Magnitude of Impact 
determine, for each exploitation, how much trouble an organization will be in. 
Determine Risk 
Establish risk based on impact and likelihood. 

1. automate the process of installation, configuration and deployments using PowerShell or anything convenient available as per the system to avoid human errors (preventive, technical)
2. keeping test, QA, prod environment same and configured with same automated scripts, but passwords and user name should be different, alsousernames should not be obvious to guess (preventive, technical)
3. All software patches must be deployed, but after rigorous testing. establish robust communication channel from software providers to get alerts (preventive, technical)
4. robust architecture (preventive, technical)
5. Automated scans and penetration testing after every release (detective, technical)
6. Follow the product guidelines for system accounts, it also includes limiting their permission to prescribed level (preventive, technical)
7. make sure unnecessary functions, ports or protocols are disabled and default ports are not used(preventive, technical)
8. password used must be of legitimate strength. (preventive, technical)
9. Monitor application logs by admin and trusted dev (detective, technical)
10. Redo risk analysis triggered by 9.and 5. above.


3. Shon Harris Book Page 1103 (Common software development weakness enumeration list)
4. Shon Harris Book Page 1109 (OWASP)