OWASP TOP 10 VULNERABILITIES

What are OWASP and the OWASP Top 10?

The Open Web Application Security Project (OWASP) is a non-profit organization dedicated to providing unbiased, practical information about application security. The OWASP Top 10 Web Application Security Risks was updated in 2017 to provide guidance to developers and security professionals on the most critical vulnerabilities that are commonly found in web applications, which are also easy to exploit. These 10 application risks are dangerous because they may allow attackers to plant malware, steal data, or completely take over your computers or web servers.

Meeting OWASP Compliance Standards is the First Step Toward Secure Code

Web application attacks are now the most frequent pattern in confirmed breaches (2018 Verizon Data Breach Investigations Report). Yet many organizations struggle to implement an application security program because they simply don’t know where to start. Setting policies based on eliminating OWASP Top 10 vulnerabilities is an excellent starting point – these vulnerabilities are widely accepted as the most likely to be exploited, and remediating them will greatly decrease your risk of a breach.

Research reveals that applications continue to fail OWASP Top 10 policy (see chart above), even though these security vulnerabilities are easy to find and fix. One reason for this disconnect is that developers are not well trained in cybersecurity and secure coding practices. Security teams also have misconceptions around what application security is, and is not. A one-time scan or pen test of a handful of business-critical apps is not effective application security. A program that continuously assesses the applications an organization builds, buys, or assembles — from inception to production — is effective application security. Find out more about application security misconceptions with our Application Security Fallacies and Realities guide.

As software increases in importance and attackers continue to target the application layer, organizations will need a new approach to security. An application security program that uses a mix of technologies and services to secure the entire application landscape, and each application throughout its lifecycle, is becoming a necessity. This mix should include:

• Tools and processes that enable developers to find and fix vulnerabilities while they are coding
• Software composition analysis
• Dynamic analysis
• Static analysis

OWASP Top 10 Web Application Security Risks

Although the Vera code Platform detects hundreds of software security flaws, we provide a razor focus on finding the problems that are “worth fixing.” The OWASP Top 10 is a list of flaws so prevalent and severe that no web application should be delivered to customers without some evidence that the software does not contain these errors.

The following identifies each of the OWASP Top 10 Web Application Security Risks and offers solutions and best practices to prevent or remediate them.

1. Injection

Injection flaws, such as SQL injection, LDAP injection, and CRLF injection, occur when an attacker sends untrusted data to an interpreter that is executed as a command without proper authorization.

* Application security testing can easily detect injection flaws. Developers should use parameterized queries when coding to prevent injection flaws.

2. Broken Authentication and Session Management

Incorrectly configured user and session authentication could allow attackers to compromise passwords, keys, or session tokens, or take control of users’ accounts to assume their identities.

* Multi-factor authentication, such as FIDO or dedicated apps, reduces the risk of compromised accounts.

3. Sensitive Data Exposure

Applications and APIs that don’t properly protect sensitive data such as financial data, usernames, and passwords, or health information, could enable attackers to access such information to commit fraud or steal identities.

* Encryption of data at rest and in transit can help you comply with data protection regulations.

4. XML External Entity

Poorly configured XML processors evaluate external entity references within XML documents. Attackers can use external entities for attacks including remote code execution, and to disclose internal files and SMB file shares.

* Static application security testing (SAST) can discover this issue by inspecting dependencies and configuration.

5. Broken Access Control

Improperly configured or missing restrictions on authenticated users allow them to access unauthorized functionality or data, such as accessing other users’ accounts, viewing sensitive documents, and modifying data and access rights.

* Penetration testing is essential for detecting non-functional access controls; other testing methods only detect where access controls are missing.

6. Security Misconfiguration

This risk refers to improper implementation of controls intended to keep application data safe, such as misconfiguration of security headers, error messages containing sensitive information (information leakage), and not patching or upgrading systems, frameworks, and components.

* Dynamic application security testing (DAST) can detect misconfigurations, such as leaky APIs.

7. Cross-Site Scripting

Cross-site scripting (XSS) flaws give attackers the capability to inject client-side scripts into the application, for example, to redirect users to malicious websites.

* Developer training complements security testing to help programmers prevent cross-site scripting with best coding best practices, such as encoding data and input validation.

8. Insecure deserialization

Insecure deserialization flaws can enable an attacker to execute code in the application remotely, tamper or delete serialized (written to disk) objects, conduct injection attacks, and elevate privileges.

* Application security tools can detect deserialization flaws but penetration testing is frequently needed to validate the problem.

9. Using Components With Known Vulnerabilities

Developers frequently don’t know which open source and third-party components are in their applications, making it difficult to update components when new vulnerabilities are discovered. Attackers can exploit an insecure component to take over the server or steal sensitive data.

* Software composition analysis conducted at the same time as static analysis can identify insecure versions of components.

10. Insufficient Logging and Monitoring

The time to detect a breach is frequently measured in weeks or months. Insufficient logging and ineffective integration with security incident response systems allow attackers to pivot to other systems and maintain persistent threats.

* Think like an attacker and use pen testing to find out if you have sufficient monitoring; examine your logs after pen-testing.

Clickjacking explained in detail

1. Introduction

This blog post is an aide to improving the security awareness of clickjacking.

The following areas will be addressed:

• Understanding the key principles of clickjacking.
• Understanding the business risk and impact of clickjacking.
• Understanding the technical aspect and testing methodology for clickjacking.
• Understanding the remedial action for clickjacking.

These essential areas should aid technical and non-technical parties in understanding the consequences of clickjacking and how they can prevent web applications from being vulnerable.

2. Understanding the Key Principals of Clickjacking

Clickjacking was first identified in 2008 by Robert Hansen Jeremiah Grossman who were looking for a way in which to circumvent anti-Cross Site Request Forgery (CSRF) nonces and the browser’s same origin policy.

In its simplest form, clickjacking is merely attacking users’ interactive “clicks” via transparent or concealed layers. These layers can be placed over likely attack vectors such as buttons and hyperlinks, potentially deceiving users into interacting with an attacker’s malicious code.

3. Understanding the Business Risks and Impact of Clickjacking

The potential risks exposed by clickjacking and its inherent impact render it a medium risk issue in most sensitive applications, such as financial or sensitive data handling apps. The reason why it is a medium risk and not a high risk issue is down to the delivery method of attack and its execution vectors. This vulnerability requires user interaction and an element of social engineering as victims (generally the more technologically naive) have to voluntarily interact with the malicious page.

There are other factors to account for, such as the application environment and its exposure to specific user types. In addition, the type of data that can be “obtained” or “manipulated” need to be considered when rating the risk as it will be specific to the targeted business.

The overall risk may only be a medium rating; however, the impact is high. This vulnerability can be linked to a multitude of attacks including keylogging and stealing user credentials.

An example of an attack on a financial application could consist of sending out emails to authenticated users of the application. This would require either some amount of inside knowledge or the use of social engineering techniques to target specific users. Alternatively, mass emails could be sent out in the hope one user logged in to the application responds. The email would contain an “interesting” link which directs the victim to a landing page displaying an advert.

On the landing page is a “skip this ad” link that has a transparent iframe located over it (placed by the attacker). When the victim then clicks on the link, they will interact with the attacker’s malicious code and thus send a static request to transfer £1000 from the victim’s current account to the attacker’s listed account.

Further examples of clickjacking attacks can be seen occurring in the past on social media sites where victims are enticed into clicking links which spam their contacts as reported by the BBC News – http://www.bbc.co.uk/news/10224434.

4. Understanding the Technical Aspect and Testing Methodology for Clickacking

To begin with, specific attack pages within the application need to be enumerated. What is meant by this is that certain web pages may post data that an attacker would want to manipulate. As stated above, this interesting page could be a “transfer funds” form that contains the originating and destination account, along with the transfer amount.

Now you have your business risk for the application, you need to test that clickjacking is indeed possible. This can be quickly tested by loading the interesting web page within an iframe as shown below:

This was done using the following HTML code:

<pre lang="JavaScript" line="1">

<html>

<head>

<title>Pen Test Partners ClickJacking PoC</title>

</head>

Pen Test Partners ClickJacking PoC

<h2>Your Web Application Can be Mounted within an iFrame and is vulnerable to ClickJacking!</h2>

<iframe src="http://192.168.0.135/WackoPicko/guestbook.php" height="450" width="1000"></iframe>

</body>

</html>

</pre>

The above was a basic example to show a proof of concept; however, full attacks are much more technically advanced in nature and can be conducted, not just simple social engineering style attacks. A great blog post detailing this, specifically how to exploit clickjacking to obtain a shell on the victim’s machine, was written by OWASP’s New Zealand chapter and can be found on securityassessment.com.

5. Understanding the Remedial Action for Clickjacking

Clickjacking can be prevented using a host of client side browser plugins such as
• NoScript – http://noscript.net
• Web Protection Suite – http://www.comitari.com/Web_Protection_Suite
These plugins are recommended for daily browsing and can also protect users against additional client side attacks, such as XSS (Cross Site Scripting).
The above plugins are client side prevention techniques that should be taught to all application users; however, steps must also be taken from the developer’s end.

The following techniques can be used to aid in the prevention of clickjacking:

5.1. X-Frame-Options

The simplest of all the techniques that only requires a simple configuration setting; for example, this can be done within Apache using the following line:

<pre lang="JavaScript" line="1">Header always append X-Frame-Options DENY</pre>

5.2. FrameBusting JavaScript

This method utilizes JavaScript to “bust” iframes. This is done by checking if the current web page is the top web page (not within a frame) and if the web page is currently not the top page, then it becomes the top page.

The following example segment of code can be used to demonstrate this:

<pre lang="JavaScript" line="1">if (top.location.hostname != self.location.hostname){
top.location.href = self.location.href;
}</pre>

It should be noted that recent techniques have found to be able to bypass this clickjacking prevention technique as seen in the whitepaper by web application security researcher Collin Jackson – http://www.collinjackson.com/research/xssauditor.pdf.

5.3.Unique URL request

Similar to a CSRF nonce, this can be employed so attackers cannot deliver the attack URL easily.

5.4. CAPTCHAs

Similar to the way it prevents attackers from spamming a web form, this can be used as an additional layer of verification on each transaction.

5.5. Element Randomization

Generally it is possible to clickjack due to buttons and links being in a static area of the web page, allowing attackers to place invisible frames over them. A technique to prevent this from occurring is to randomize the links or buttons on load, thus preventing attackers from hard coding static iframes.

McAfee SIEM - FAQ

GENERAL

Q: What is the difference between SIEM and ESM?

A: SIEM, Security Incident and Event Management is a product category, just like Intrusion Prevention Systems or antivirus are product categories. ESM (Enterprise Security Manager) is the name of the main component of the McAfee SIEM solution.

Q: What models of SIEM exist?

A: The McAfee SIEM components all come in hardware or virtual appliances. All SIEM components can be standalone, using their own dedicated appliance. Some components are combined together on some appliance models, in what we call a combo appliance. The following combinations exist:

•    All in one: ESM + Event Receiver + Log Manger

•    Event Receiver + Log Manager

Q: What are the components that make up the McAfee SIEM solution?

A:  The following are the key components of McAfee SIEM:

ESM (Enterprise Security Manager) :

This is the SIEM central console and includes the enterprise database. Nearly all configuration, management, reporting and workflows are done here.

ERC (Event Receiver) :

Receivers collect events, flows and logs from data sources (McAfee and 3rd party products). Receivers also normalize, aggregate, enrich and can also perform rules-based event correlation.

ACE (Advanced Correlation Engine):

The ACE performs rules-based correlation, but it also performs the important task of relieving Receivers from having to do correlation. ACEs also perform risk, deviation, and historical correlation.

ELM (Enterprise Log Manager) :

ELMs collect and store raw logs for compliance purposes and raw log search. ELMs can also perform full text indexing of stored logs. ELMs also provide a forensically sound audit trail of logs.

ADM (Application Data Monitor) :

ADM analyzes layer 7 traffic flows, providing rich information on risks at the application level.

DEM (Database Event Monitor) :

DEM monitors database transactions from the network, removing the need to install a component on databases to monitor them. It adds the ability to see local/internal database events as well as prevent unwanted database activity.

Storage :

McAfee Direct Attached Storage provides high performance storage array for ESM and/or ELM, redundant architecture with RAID controller, mirrored cache, and IO multi-pathing.

GTI (Global Threat Intelligence) :

This adds McAfee's GTI Reputation information to help assess event risk. This is a license-based component that does not require any additional hardware.

Q: How many consoles do I need to manage all those components?

A: The Security Manager provides a single central unified web-based console to manage all SIEM components (Security Manager, Log Manager, Receiver, Reputation feed, reporting, creations of custom parsers, and application monitoring).

Q: What happens if my EPS (Events per Second) rate exceeds what I’m licensed for?

A: Unlike some other SIEM products, we do not drop events and there's no license violation.  All events will be queued on the receiver and processed when possible.

The licensing is done per appliance unit regardless the number of:

o    Data sources that you have

o    Sources of vulnerability information  you use

o    Events per second

o    Admin users

o    Parsers* required for to collect data

o    Compliance templates like SOX,GLBA,NERC-CIP , ISO-27002 and others

To recap this important point, the McAfee SIEM solution does not drop events or disable some features in case the number of events exceeds the nominal processing capacity of the appliance so you don’t lose events or visibility of events during incidents, which is usually a time when events would spike.

*See “what is a parser” for more information

Q: Is the communication between the components safe?

A: All data between the McAfee SIEM components is encrypted using AES encryption. Components will only communicate with a device that they share a key with.

Q: When and how do the SIEM components talk to each other?

A: The data source (product generating event, flows and logs) generates events. Some data sources, such as many firewalls, IDS, and similar sources, will send events to the receiver as they occur, via syslog. On some other type of data sources, such as McAfee ePO , the receiver will pull the data at a configurable interval.

Events that are collected by the Receiver are parsed, normalized, aggregated, and then queued for a short time.  The ESM then pulls those queued events from the Receiver at a configurable interval. The “Get Event and Flows” icon of the ESM console allows  you to force the ESM to pull events from the receiver right away.

Q: Where can I find SIEM resources?

A: Here is list of useful SIEM resources:

McAfee SIEM product page and sales contacts: http://www.mcafee.com/us/products/siem/index.aspx

McAfee SIEM community (discussions, blogs, how to’s…): https://community.mcafee.com/community/business/siem/content

MCAFEE SIEM INTEGRATION

Q: What products are currently integrated with the McAfee SIEM and how are they integrated?

A: First, the McAfee SIEM can receive events from third parties and McAfee solutions. For a complete list of supported products, please refer to the following document:

http://www.mcafee.com/us/resources/data-sheets/ds-siem-supported-devices.pdf

This list is updated on a weekly basis. And support for new products and new versions is automatically updated on a regular basis with rules updates.

Second, the McAfee SIEM comes with pre-built connectivity to many McAfee technologies, such as the ability to directly ask the McAfee IPS system to blacklist malicious IP addresses, or to tell McAfee ePO to apply specific tags to endpoints. The McAfee also provides, via existing APIs, an open interface that allows orchestrating action with other technologies from third parties.

Q: What is a parser? And what data source formats are supported?

A parser is a component that allows the Receiver to makes sense of the events, logs and flows, it receives. The parser analyzes and identifies the parts of the information coming from a specific data source (product you are collecting events from) to understand their structure, and then map those parts to a common SIEM syntax. A parser is required for   each type of data source. The McAfee SIEM comes with over 250 different parsers, as well as support for those common formats: Syslog (both UDP and TCP), WMI, McAfee SIEM Collector (Agent), MEF (McAfee Event Format), Netflow (generic Netflow, sFlow, IPFIX, JFlow) and CEF (Common Event Format) and SEF (Standard Event Format).

Q: Can you create custom parsers for new or unsupported data sources?

A: Yes, McAfee SIEM allows users to create custom parsers for data sources that McAfee SIEM doesn't support out of the box. SIEM users will generally use regex to parse the various message formats, and then create normalization mappings.  See next question for more details.

Q: What should you do if a parser for a product that I need to integrate with the McAfee SIEM does not exist?

A: First, you can create your own custom parser. Please refer to the following document to learn how to write a custom parser.

https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/ 24000/PD24926/en_US/How%20to%20write%20a%20McAfee%20ESM%20Custom%20Parser%20and% 20troubleshoot%20a%20data%20source.pdf

If you are writing you own parser, you might also find the following Regular Expressions resources useful:

http://gskinner.com/RegExr/

http://www.hongkiat.com/blog/regular-expression-tools-resources/

Second, you can submit a PER (Product Enhancement Request) for a new parser.

Please follow the instruction in the following document to submit a PER: https://kc.mcafee.com/corporate/index?page=content&id=KB60021

Parser update requests: https://mcafee.acceptondemand.com/

If you submit a PER, remember to provide as much data and log samples as you can. The variety and quality of log samples provided will directly affect the quality and event coverage of the parser.

Q: Can I receive events through a Syslog-NG relay?

A: Yes, McAfee SIEM can correctly handle traffic that has been relayed through a Syslog-NG server. When creating or editing the Syslog-NG data source in the ESM console, select Syslog-NG under the Syslog Relay drop down.  Then define data sources for each individual data source that is being relayed.

Q: Can I receive events from a Splunk server?

A: Yes, McAfee SIEM can correctly handle traffic that has been relayed through a Splunk server. When creating or editing the Splunk relay data source in the ESM console, select Splunk under the Syslog Relay drop down. Then define data sources for each individual data source that is being relayed.

Q: Can I receive events from an Arcsight server?

A: Yes, McAfee SIEM can handle traffic that has been relayed through an Arcsight server in CEF format. When creating or editing the ArcSight data source select CEF as the data format. Then define data sources for each individual data source that is being relayed.

Q: What actions can the McAfee SIEM take?

•    Send email Notifications

•    Run Script: You can write scripts in any scripting language that is supported on the Scripting Host, and then run scripts on a designated Scripting Host or launch them via SSH.

•    Launch URL

•    Execute Report

•    Display Popup Notification

•    Play Sound

•    Actions with other technologies from third parties via open interface APIs.

•    Apply ePO tags

•    Blacklist IPs from McAfee IPS

FEATURES

Q: What are baselines and why should I use them?

A: Baselines allow you to see what is normal, and what’s not at a glance. That way, you can identify anomalies with a high degree of accuracy. You can for example easily spot unusual user behavior patterns, suspicious deviations in network activity  or anomalous communication patterns, while not being distracted by spikes in activity that occur on a regular basis and are a normal part of your environment, such as scheduled vulnerability scans.

Q:  How do I enable baselines?

A:  Everything that comes into the SIEM is baselined on the fly. Bowtie icons, red/blue split show where a baseline is (bowtie) and what's over it (red). This view takes into account day of week, with days being defined as midnight to the second before midnight. Baselining calculations look over the last 5 periods (e.g. looking at 3 days, look at last 5 periods of 3 days). All of this is calculated on the fly and can therefore impact console performance, so some customers some turn it off selectively (users can do this per View components).

Q: What is Geolocation and why should I use it?

A: Geolocation tells you which countries and cities of the world the systems in your environment are communicating with. This help you identify if abnormal communication (such as with a country you do not do business with) are taking place, and it will in identifying the physical location of a threat.

Q:  How do I view geolocation data for my existing events?

A:  Geolocation has to be turned on, on the receiver, and if you use those, on the  ACE ADM and DEM. Geolocation must be enabled  at the time the event is parsed in order for the Geolocation data to be parsed out and viewable. To enable Geolocation, go to the Device Properties>Events, Flows, And Logs>Click the Geolocation button and choose the desired Geolocation settings. This is the same path you would take to configure ASN settings.

Note: You are either parsing Geolocation data or ASN data, you cannot do both at the same time.

To see Geolocation data, you can select Event Views>Geolocation Map. To see geolocation information for an individual event, select the event then go to the pancake menu, hover over Event Drilldown, and select Events. Then highlight an event on the list and click the Geolocation tab.

Q: What are watchlists and why should I use them?

A: Watchlists allow the McAfee SIEM to maintain state about the world around it.  For example, watchlist are an “economical” and efficient way for you to detect “Low and Slow” attacks, tracking state over long time periods.

Imagine somebody who scans the network on a given Monday. They don’t do anything more until the next Tuesday, 8 days hence, when they maliciously probe some open services. Using a correlation rule to detect such an attack would consume a huge amount of memory because it would need to track this over such a long time. But the watchlist feature allows you to automatically put the user/IP probing the network on a watchlist after the reconnaissance is detected, and then associate the Tuesday probing with the reconnaissance that took place the week before. Another real world example includes credit card thefts where criminals don’t use stolen card right away. They knew the credit cards would be on a list distributed to merchants that got updated every week or two. They waited until the stolen cards dropped off the list and then abused them. In this scenario, a watchlist is the ideal tool for keeping lists of cancelled credit card numbers or fraudulent IBANs.

Q: How do I keep my watchlists current?

If they’re to remain useful, watchlists must be regularly updated.  You have a wide range of techniques at your disposal to support this, such as automated file import (CIFS, FTP, NFS, SCP, SFTP), Database queries (Hadoop, MS SQL, MySQL, Oracle), LDAP queries, Pull values from incoming events, Watchlist API, Automatic ageing (watchlists can have an optional timeout, if you want to age out entries after X hours or days).

Watchlists can have up 1 million entries

install ASA 8.4 on Gns3

How to add or install ASA 8.4 on Gns3 1.1 windows 8.1

This article is related to installation and configuration of ASA on Gns3 1.1 and also include some tips for older versions of Gns3.

How to configure / use Cisco ASA on Gns3 1.1:

You can add ASA in Gns3 1.1 by following steps:

• Open Edit \ Preferences \ Qemu \Qemu VMs

• Click on New button
• this will start a wizard for ASA, Type it’s name and select it’s type ASA and click next

• Set a suitable memory for ASA

• Now browse the initrd.gz & kernel files for ASA and click finish.

• Now you may need for flash, yo can create it easily. Open the “C:\Program Files\GNS3\qemu” directory by cmd (command prompt) using command cd C:\Program Files\GNS3\qemu . For flash type the command “qemu-img create FLASH 512M” and press enter.

• this will create a file flash in this directory.

• now again go to Edit \ Preferences \ Qemu \Qemu VMs & edit the ASA.

• In HDD tab define the path for flash.

In Advanced Settings, on kernel command line replace with following code:

-append ide_generic.probe_mask=0x01 ide_core.chs=0.0:980,16,32 auto nousb console=ttyS0,9600 bigphysarea=65536 ide1=noprobe no-hlt -net nic

On options: Replace the content with -vnc none -vga none -m 1024 -icount auto -hdachs 980,16,32

Click on apply.

note: It will take some time for first boot

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

Emulate ASA in older versions of  gns3:

Please carefully follow these step to configure ASA in older gns3 on windows 7 or XP.

• Download ASA IOS
• Configure ASA in gns3 
• Start the ASA
• Open the console 

 Step-1 Download ASA IOS and how to solved ASA console hangs Problem: 

First you need two file for ASA one is ".kernel" and other is ".initrd.gz". In my case these are "asa802-k8.kernel" and asa802-k8.initrd.gz. You can download these files from following link:

Download ASA IOS for GNS3

Add ASA in gns3:

Now run the gns3 open the Preferences from edit/preferences, and in qemu/ASA tab define the name for ASA and these two file i.e. "asa802-k8.kernel" and "asa802-k8.initrd.gz" in respective fileld.




Start the ASA:

 Start the ASA and a qemu console window is open don't close this window. 

 

Open the console:

Now open the ASA console by rigth clicking on it and after some time you received a message that  copy these two commands and press enter, do this.

and then you received the welcome message of ASA.