Web Application Attacks and Recommendations

In this era technology has grown rapidly, now every person knows the importance of DATA. In this time almost every physical business is shifted to an online platform (To Succeed in their business we've been started using digital marketing and we also use online payment method). To do so one of the most popular ways is to have a web application for your business. The primary reason behind use of web application is that, the internet serves as an inexpensive, easiest, and the fastest medium to communicate and share information.

Let's try to understand exactly how web application works. A web application is a client-server computer program which uses web browsers and web technology to allow its visitors to store and retrieve data to/from the database over the internet. We can see different applications running in different websites, it all depends on the network architecture and usability of the server.

Web application attacks are seen frequently from different parts of the world. Many companies are having their special team to lookup on these threats and issues. Attackers use different tools to launch web application attack, which contains multiple pattern of signatures that can compromise the web server.

Let’s try to understand how web application attacks happens. Web applications can be dynamic and static in nature, which decides whether a web application require server-side processing or not. Generally, a web application requires a web server for handling client requests, an application server to process the tasks commanded by the user, and a database to store the user data.

There are multiple ways through which this attack can be successful. Here we can see few ways through which the attacker will try to compromise the server. (They are commonly)

1. Injection

2. Broken Authentication and Session Management

3. Cross-Site Scripting

4. Insecure Direct Object References

5. Security Misconfiguration

6. Sensitive Data Exposure

7. Missing Function Level Access Control

8. Cross-Site Request Forgery

9. Using Components With Known Vulnerabilities

10. Unvalidated Redirects and Forwards

11. Application Attacks

The application layer is the hardest to defend. The vulnerabilities encountered here often rely on complex user input scenarios that are hard to define with an intrusion detection signature. This layer is also the most accessible and the most exposed to the outside world. For the application to function, it must be accessible over Port 80 (HTTP) or Port 443 (HTTPS).

Most vulnerabilities found in the proprietary code of Web applications are unknown to security defense systems; these are called zero-day vulnerabilities. This is because these vulnerabilities are specific to each application and have never been known before. A skilled attacker can easily find these vulnerabilities and exploit the issue without being detected.

The best defense against these attacks is to develop secure applications. Developers must be aware of how application attacks work and build software defenses right into their applications.

The IBM Security Ethical Hacking Team shares this goal. With this in mind, we put together a video series that demonstrates attacks from each category from OWASP’s list. Each video includes information on how to prevent these attacks and how to use automated tools to test whether attacks are possible. These videos were initially intended for internal use but have now recently been made publicly available.

These are all the different types of signatures used in attacker, which I have observed in one of the web application attack from an external bad reputed IP.

Signature
SCAN OpenVAS User-Agent Inbound
WEB_SERVER cmd.exe In URI - Possible Command Execution Attempt
WEB_SERVER /system32/ in Uri - Possible Protected Directory Access Attempt
WEB_SERVER Script tag in URI, Possible Cross Site Scripting Attempt
WEB_SERVER Possible SQL Injection Attempt UNION SELECT
WEB_SERVER Possible XXE SYSTEM ENTITY in POST BODY.
WEB_SERVER Possible SQL Injection Attempt SELECT FROM
WEB_SERVER SELECT USER SQL Injection Attempt in URI
WEB_SERVER MYSQL SELECT CONCAT SQL Injection Attempt
POLICY Suspicious inbound to MSSQL port 1433
WEB_SERVER IIS 8.3 Filename With Wildcard (Possible File/Dir Bruteforce)
WEB_SPECIFIC_APPS Opencadastre soustab.php script Local File Inclusion Vulnerability
WEB_SERVER PHP tags in HTTP POST
WEB_SPECIFIC_APPS Zen Cart loader_file Paramer Local File Inclusion Attempt
WEB_SPECIFIC_APPS PithCMS oldnews_reader.php lang Paramer Local File Inclusion Attempt
WEB_SPECIFIC_APPS PsychoStats XSS Attempt -- login.php
WEB_SPECIFIC_APPS WHMCompleSolution templatefile Paramer Local File Inclusion Attempt
WEB_SPECIFIC_APPS iWare Professional SQL Injection Attempt -- index.php D UNION SELECT
WEB_SPECIFIC_APPS axdcms aXconf Paramer Local File Inclusion Attempt
WEB_SPECIFIC_APPS iWare Professional SQL Injection Attempt -- index.php D SELECT
WEB_SERVER PHP.//Input in HTTP POST
EXPLOIT Possible Pure-FTPd CVE-2014-6271 attempt
WEB_SERVER suhosin.simulation PHP config option in uri
WEB_SERVER allow_url_include PHP config option in uri
WEB_SERVER Onmouseover= in URI - Likely Cross Site Scripting Attempt
WEB_SERVER safe_mode PHP config option in uri
WEB_SERVER disable_functions PHP config option in uri
WEB_SPECIFIC_APPS Horde Web Mail Help Access
WEB_SPECIFIC_APPS WBBlog SQL Injection Attempt -- index.php e_id SELECT
WEB_SPECIFIC_APPS Demium CMS urheber.php name Paramer Local File Inclusion
WEB_SPECIFIC_APPS PHP-CGI query string paramer vulnerability
WEB_SPECIFIC_APPS CultBooking lang paramer Local File Inclusion Attempt
WEB_SERVER open_basedir PHP config option in uri
WEB_SPECIFIC_APPS PHP Booking Calendar page_info_message paramer Cross-Site Scripting Vulnerability
WEB_SPECIFIC_APPS Open Source Support Tick System module.php Local File Inclusion Attempt
WEB_SPECIFIC_APPS BLOG CMS nsextt paramer Cross Site Scripting Vulnerability
WEB_SPECIFIC_APPS WikyBlog which Paramer Cross Site Scripting Attempt
WEB_SPECIFIC_APPS Noname Media Photo Galerie Standard SQL Injection Attempt -- view.php id SELECT
WEB_SPECIFIC_APPS PNphpBB2 SQL Injection Attempt -- index.php c SELECT
WEB_SPECIFIC_APPS Beerwins PHPLinkAdmin edlink.php linkid Paramer SQL Injection
WEB_SPECIFIC_APPS AjaxPortal ajaxp_backend.php page Paramer SQL Injection
POLICY Proxy TRACE Request - inbound
WEB_SPECIFIC_APPS AlstraSoft AskMe que_id Paramer SELECT FROM SQL Injection Attempt
WEB_SPECIFIC_APPS Noname Media Photo Galerie Standard SQL Injection Attempt -- view.php id UNION SELECT
WEB_SPECIFIC_APPS PozScripts Business Directory Script cid paramer SQL Injection
WEB_SPECIFIC_APPS Business Objects Crystal Reports Web Form Viewer Directory Traversal Attempt
WEB_SPECIFIC_APPS SFS EZ Hotscripts-like Site showcategory.php cid Paramer SQL Injection
WEB_SPECIFIC_APPS Community CMS view.php article_id Paramer SQL Injection
WEB_SPECIFIC_APPS Turnkeyforms Software Directory showcategory.php cid paramer SQL Injection
WEB_SPECIFIC_APPS SFS EZ Hotscripts-like Site software-description.php id Paramer SQL Injection
WEB_SERVER ColdFusion administrator access
TROJAN HackerDefender Root Kit Remote Connection Attempt Dected
WEB_SPECIFIC_APPS JobHut browse.php pk Paramer SQL Injection
WEB_SERVER DD-WRT Information Disclosure Attempt
WEB_SPECIFIC_APPS Fork-CMS js.php module paramer Local File Inclusion Attempt
POLICY Incoming Basic Auth Base64 HTTP Password dected unencrypted
WEB_SPECIFIC_APPS Jelsoft vBullin XSS Attempt -- calendar.php
SCAN SFTP/FTP Password Exposure via sftp-config.json
WEB_SPECIFIC_APPS BaconMap updatelist.php filepath Local File Inclusion Attempt
WEB_SERVER Possible IIS Integer Overflow DoS (CVE-2015-1635)
WEB_SERVER WEB-PHP phpinfo access
WEB_SERVER PHP SERVER SuperGlobal in URI
WEB_SPECIFIC_APPS IBSng str Paramer Cross Site Scripting Attempt
WEB_SPECIFIC_APPS Athena Web Registration Remote Command Execution Attempt

As the attacker uses multiple tools to carry on the attack, the whole attack will be completed with in a short period of time. As in the above case, over all duration of the attack was over 12 min.

Let’s look how the attacker will carry on the Web Application Attack. Let’s go through with Cyber kill Chain Stages.

1.       Reconnaissance:

The observation stage: attackers typically assess the situation from the outside-in, in order to identify both targets and tactics for the attack. There is nothing that can be done about this stage

2.       Weaponization:

Based on what the attackers discovered in the reconnaissance phase, they’re able to get into your systems: often leveraging malware or security vulnerabilities. In Web Application attack, attacker will use vulnerability tools to exploit the application running on the server.

If we observer the above signatures, we can see that the tool used by the attacker tried to exploit many applications on the server. Few are SQL, php etc. (SQL-WEB_SERVER Possible SQL Injection Attempt UNION SELECT, etc. PHP- WEB_SERVER WEB-PHP phpinfo access, etc.)

3.       Delivery:

Transmission of the attack to the intended victim(s). For example, this would be sending the actual phishing email or distributing the infected USB drives at a local coffee shop or cafe. While there is an entire technical industry dedicated to stopping this stage, people also play a critical role.

4.       Exploitation:

The act of exploiting vulnerabilities, and delivering malicious code onto the system, in order to get a better foothold.

In web application attack the attacker will try to find what are all the applications running on the server and then attacker will send particular signatures to check exact version of the application. Once the attacker catches hold of the version, they will try to exploit the vulnerability in application by sending signatures which can exploit the vulnerability. (Once the attacker is having information of application version it will be easy to find out the vulnerabilities existing in the version by the help of google)

5.       Installation:

Attacker installs malware on the victim. Not all attacks require malware, such as a CEO fraud attack or harvesting login credentials. However, just like exploitation when malware is involved, a trained and secure workforce can help ensure they are using secure devices that are updated, current, and have anti-virus enabled, which would stop many malware installation attempts. In addition, this is where we begin to go beyond just the “human firewall” and leverage the “human sensor”.

To explain this stage in Web Application attack, lets investigate on SQL application used in server.

Once the attacker exploits the vulnerability, attacker will send SQL Queries to fetch or modify data in the Data Base, by doing this attacker can get access to target environment.

6.       Command and Control:

In this stage the system will be compromised and infected, system will try to contact the attacker. Once the attacker gain control over the system, they will start giving command to system to execute with out the user knowledge. 

7.       Actions:

Once the cyber attacker establishes access to the organization, they can then execute actions to achieve their objectives.

How we can identify, and remediate web application attack?

Through network device logs and firewall logs we can identify/detect the attack, if attack has happened multiple signatures requests will be there from a suspicious external IP and if IDS/IPS detects multiple patterns from the IP. From those we can get destination address where the attacker is trying to reach. As the destination address is known for us, we can find out the application running in the web server by running plugin wappalyzer. We can identify weather the attack was successful or not by analyzing web server logs (IIS logs), which is explained as below.

Below are the few steps that are followed during analysis too, check if the attack is true positive are not.

1.       Identify the versions of applications and open ports/Services running on web server.

2.       Once we get hands on web server logs, try to look for traffic status code. From status code we can easily identify what had happened to that traffic (Attack was successful or not). If URL is present in the payload/traffic, check the reputation of the URL.

3.       Correlation (If we have source IP, Local systems and external systems details) can be carried on as below :

As a security analyst, we can identify the attack after Weaponization stage. If the attack is happening in that movement or it had happened before, then we can follow few recommendations mentioned below:

• Block the IP if there are no business requirements, if in case of business requirement block the IP based on port.
• Enable Geo-location blocking in the firewall.
• Close all the ports except 443. (Open the known ports, if there are any business requirements only)
• Install the latest version of your web server and ensure that all patches have been applied time to time.
• Checking the browser and system infection and running the Anti-Virus scans.
• Hardening and updating Proxy and firewall with the IOCs.
• kindly disable the server if you are not having any business requirement. (Some Companies will still keep these severs, even if they are not having business with it)

The Web Application Attacks can lead to a greater loss to the company. To prevent this attack, we can follow some best practices to protect Web server from the attackers:

Ø  Close unnecessary ports.

Ø  Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.

Ø  Implement server-side input validation, filtering, or sanitization.

Ø  Please ensure that encoding is enabled for user input fields included in a page.

Ø  Implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks.

Ø  The web application and its components should be running under strict permissions that do not allow operating system command execution.

Ø  Using strong hashes with salts for passwords.

Ø  Restrict Access to a Specific Network or IP.

Ø  Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record.

Ø  Run vulnerability scan and patch at regular interval.

Ø  Remove unnecessary applications from web server.

Ø  Please ensure that the security patches are up to date.

Ø  Disable Trace HTTP Request

Ø  Disable Signature

Ø  Disable Banner

Ø  Use only TLS 1.2 or newer version, Disable SSLv2, SSLv3

Ø  Disable Null and Weak Ciphers on all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

Ø  Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.

Reference: Link, Link2


By:
Dhanush S V
Information Security Analyst
+91-7975973204