Web Breach Incident Analysis and Countermeasures

 

MONITORAPP’s Business Division Pilyong Yoon- Deputy Manager

Due to smartphones, internet access is now easier than ever and with the internet, the web, shopping, delivery, and banking are easily accessible. However, with this convenience comes the risk of hacking. This article will look at how to analyze web incidents and how to deal with them.  

 - Contents -

Summary

Analysis

Action plan

1. Summary Web servers have to provide public services so it’s delivered through HTTP and HTTPS protocols using 80 and 443 ports. Hence, it is a common practice to install a firewall on top of the network security infrastructure and set its inbound policies to only allow 80 and 443. Because the web service ports are open to the public, hackers started to attack vulnerabilities on the web. Hacker’s targets have changed throughout history. At the beginning of 2000, when the internet was less popular, hackers simply attacked to show off their skills but recently hackers have been targeting personal information and planting ransomware for financial gain.  Below are some of the well-known hacking incidents. *Note that these incidents happened in South Korea.

• Auction site hacking incident (August 2008)
  • Damages: More than 10 million personal information leaks
  • Hacked the DB server through the web
• Nate (SK coms) hacking incident (July 2011)
  • Damages: Over 35 million personal information leaks
  • Internal PC was infected through a file compressor software update -> Accessed the DB server through the infected internal PC
• EBS hacking incident (May 2012)
  • Damages: Over 2 million personal information leaks
  • Server hacking (web shell upload) using the web community board vulnerability
• 20 cyber terrorism (March 2013)
  • Damages: Internal system destruction of a major financial/media companies using malicious codes
  • Gained access to primary and secondary C&C (command control) servers using the web community board vulnerability -> Infected internal PCs using malware -> Spread malware to collect internal information using the C&C server -> Infected and destroyed the updated management server by distributing malicious codes to the internal corporate system.

The cases above are all incidents involving the web. To combat such incidents, the financial supervisory service has revised the personal information protection act so that criminal penalties can be imposed when these standards are violated. The official booklet (*note that the excerpts are from Korean official booklet), revised in 2012, directly mentions web firewalls and emphasizes the need for intrusion prevention/detection systems. Below are the relevant excerpts. There are many types of breach incidents on the web but we will just look into two types, which are web shell upload and malicious code insertion. The web firewall mentioned in this paper is based on the AIWAF, a MONITORAPP’s product.

2. Analysis Procedure

  In the event of a breach, it is important to collect the relevant data and analyze it to find the cause of the breach. When and how did the breach happen?

• Information/data collection
• Collect relevant data through the help of the related parties such as the clients and the admins
  • Collection of the breached files
  • Breached server info (IP/OS/Application)
  • Breached domain and URL info (www.monitorapp.com, index.html)
  • Whether similar incidents happened in the past
  • Weblog
  • OS event log

• WAF information collection
  • Collect a month worth of logs from the breach date
  • Export a list of protected web servers
  • Check SW/HW bypass information in the audit log
  • Collect system logs during the breach using GUI
• Check the time stamp on the webserver and the WAF

Analysis based on the collected data In the case of no suspicious activities in the WAF/weblog

• Was the breach actually through the web?
  • There are no logs, no suspicion.
  • Did they delete the log? WAF log as well?
• Breach incidents can have many points of entry so guidance is needed for clients and admins to check for various possible breach points.

1. ex) Infected developer’s PC / FTP service/ file sharing services, etc.

• Verify if the breach is through the web and if there is a possibility of another attack
  • Temporarily build a packet dump server through tap switch or S/W mirroring on the network above the WAF
  • Strengthen WAF security policies and weblogging

3. Action Plan

  First, you must distinguish between the parts that can be blocked by the WAF and the vulnerabilities in the application. Below is an example of a site with a parameter verification vulnerability. In this case, even an unauthorized user can delete other people’s posts by simply changing some values. From the security equipment’s perspective, this is a normal request, so this request reaches the web application without resistance. Hence, this vulnerability can be secured by authentication secure coding in the web application and not by reconfiguring the security equipment. We will learn how to deal with some of the well-known attack types in the web server and WAF in the following section.

• A1:2017-Injection

By inserting SQL statements into the web application, data from the internal database can be leaked/altered and administrator authentication can be bypassed. First, the attacker finds the agent that delivers web applications to the database. The attacker cautiously inserts SQL command into the agent so that the web application delivers the malicious query to the database. This attack is not hard to implement and there are many tools being developed (and already available) to find such vulnerabilities.

• Application countermeasures
  • You can prevent malicious queries from being inserted by validating query values on the web server or the web application. You can prevent malicious syntax insertion by configuring the web application so that it only has the privileges needed to perform its function.
  • The internal application must be configured so the query is not visible in the parameter.
• WAF countermeasures
  • When it comes to SQL injection policies, keep exception handling to a minimum, and operate as a block mode.
  • Make sure you use the latest pattern update.

• A3:2017-Sensitive Data Exposure

Many web applications and API’s do not properly protect important information such as financial and personal information. Hackers can steal or alter vulnerable data for identity fraud, credit card theft, and selling personal information for profit. When saving or transmitting sensitive data if methods like encryption or other protective measures aren’t taken, data can be intercepted and exploited.

• Application countermeasures
  • If you discover a personal information leak (social security number, credit card number, EIN, business license number, phone number, email, bank account number, address, etc.), block the whole page, or block out the sensitive information in the output. You must be cautious when using personal information in any case.
  • With stricter personal information laws, encryption is required when it comes to personal info.
• WAF countermeasures
  • If for some inevitable reason, some personal information must be displayed, then you must configure the setting so that certain digits are not displayed.
  • When implementing SSL, the decryption function is automatically supported so this can help prevent the exposure of personal info.

• A5:2017-Broken Access Control

You need to grant appropriate authorization to the users depending on the function. If the authorization is not properly set up, the hacker will exploit this vulnerability and breach into other user’s accounts, look into a sensitive file, alter data, and alter authorization.

• Application countermeasures
  • Except for public sources, “block” should be the default policy.
  • Instead of granting authorization to certain users, only give authorization to the owner.
  • Disable directory listing function on the webserver and make sure important data or backup data are not on the web route.
  • If access control fails, then logging in should be required, and if repeated failed attempts occur, an alarm should be sent to the administrator.
• WAF countermeasures
  • Set the method to only use GET and POST. When using WebDAV, only allow a minimum amount of access to the domain in question.
  • Configure the WAF to block directory access and listing attempts.
  • Configure to block unnecessary request attempts by setting positive/negative policies regarding web extension.