SESSION ID: GPS1-F04
Web Defacements and Data
Leakages - Twin Towers website
threats
Wong Onn Chee
MD, Infotect Security
#RSAC
#RSAC
Web Defacements in ASEAN Govt Websites
Confirmed Web Defacements
25000
19,491
19,338
20000
15000
10000
5000
0
0
81
Brunei (gov.bn)
14 247
Cambodia
(gov.kh)
1,250
Indonesia
(go.id)
2,468
2,325
17 103
Laos (gov.la)
124
18 86
Malaysia
(gov.my)
Myammar
(gov.mm)
2016 (ytd)
Total
2
61
Philippines
(gov.ph)
0
38
Singapore
(gov.sg)
736
Thailand (go.th)
1,927
142
Vietnam
(gov.vn)
Web Defacements in ASEAN Govt Websites
Source: Zone-H (www.zone-h.com)
For Indonesia, the quantity of confirmed defacement for 2016
exceeded the maximum displayable quantity, hence the actual
count may be more than 1250 for 2016 YTD.
For Brunei and Vietnam, Zone-H only started to have confirmed
defacement from 2013. There is no confirmed defacement
before 2013.
3
#RSAC
#RSAC
Data Leakage From US Entities
No. of Personal Records Leaked ('000)
350,000
313,378
300,000
255,283
250,000
200,000
150,000
120,605
100,000
59,348
58,602
50,000
-
2,361448 1928,383
Business (Others)
9
342
FSI
0
12,748
65 1 1,042
3
Retail
2016 (ytd)
Education
2015
4
2014
28,201
101
1,691
Government
Total (from 2005)
19,507
8,639
4,565
2,511
Medical
0
0 55 293
NGO
Data Leakage From US Entities
Source: PrivacyRights ClearingHouse (www.privacyrights.org)
Search criteria:
Unintended disclosure
Hacking or malware
Unknown or others
5
#RSAC
Data Leakage From US Entities
Excluded:
Payment card fraud, e.g. skimming of payment cards
Insider
Physical loss
Portable devices
Stationary devices
6
#RSAC
#RSAC
Web Defacements Unsolicited "Free Web Design" Services
#RSAC
Types of Web Defacements
Existing
Content
Reflected
Conditional
8
New
Content
Upload
#RSAC
Note
All proposed defences are based on the assumption that the
defacement has already occurred, not before.
Refer to OWASP Top 10, Secure Coding Practices, ASVS and
Testing Guide for industry best practices for securing web sites
to avoid defacements.
(Disclosure: I am OWASP Singapore chapter lead)
9
Existing Content Defacement
Oldest type of defacement.
Unauthorised, persistent modification of existing content.
Visible to every visitor, especially damaging if home page is
affected.
Modification can occur at the web server level or database
level if Content Management System (CMS) is present.
Usually caused by weak authentication controls, application
vulnerabilities and insufficient system/CMS hardening.
10
#RSAC
Existing Content Defacement
11
#RSAC
Existing Content Defacement
#RSAC
A check of the cached page reveals more
information. “Your site’s security is good
but not enough to stop #Muster BD. We
didn’t harm your site! Just deface (sic),”
a message reads. It was accompanied by a
logo that read "BD_Level_7 Team:
Bangladesh_Level_Seven Hackers".
12
Existing Content Defacement
13
#RSAC
#RSAC
Possible Defences
File integrity tools if CMS is not used.
If website is not regularly updated, consider the use of nonrecordable storage media such as CD-ROM or DVD-ROM as a
preventive measure.
SOC monitoring services to alert when website is defaced.
Outbound protection for web servers to provide true real-time
protection against display of defaced content.
14
Conditional Content Defacement
#RSAC
Not well known, as it is a form of targeted defacement.
Visible only to visitors who fit certain criteria, such as search
engines, referred from search engines or from certain
geographical regions.
Not detectable by dynamic scanners, SOC monitoring and etc.
Usually caused by weak authentication controls, application
vulnerabilities and insufficient system/CMS hardening.
15
Conditional Content Defacement
Google Search Results
Poisoning
16
#RSAC
Conditional Content Defacement
#RSAC
“The links are not visible in the source code
of pages on the site when viewing them
normally through a web browser.
However, when spoofing the user-agent of the
browser to masquerade as the web crawler that
Google uses to build its search engine index,
the links can be easily viewed in the source
code of the
current versions of a number of pages on the
ICAC website.
17
#RSAC
Possible Defences
File integrity tools to monitor for changes to the web apps.
May not be useful if conditional logic is injected into content
stored in DB.
Outbound protection for web servers to provide true real-time
protection against display of defaced content.
18
Reflected Content Defacement
Becoming more popular, as it is easy to bypass monitoring and
hence the defacement is likely to persist longer.
Non-persistent modification of existing content. Visible only to
visitors who accessed the affected URLs.
Impact is made higher due to popularity of social media. For
instance, affected URLs can be posted on Facebook, Twitter,
Instagram and etc for wider coverage, instead of relying on email.
Not detectable by dynamic scanners, SOC monitoring and etc, as
affected URLs are not persistent.
Usually caused by application vulnerability or misconfiguration.
19
#RSAC
Reflected Content Defacement
20
#RSAC
Reflected Content Defacement
21
#RSAC
Reflected Content Defacement
22
#RSAC
Reflected Content Defacement
23
#RSAC
#RSAC
Possible Defences
Outbound protection for web servers to provide true real-time
protection against display of defaced content.
24
Defacement via New Content Upload
No 1. type of defacements in Zone-H.
Persistent upload of defacement in the form of new files.
As these are usually not linked from existing pages, they are only
visible to visitors who accessed the affected URLs directly.
Impact is made higher due to popularity of social media.
Not detectable by dynamic scanners, SOC monitoring (until it is
published on Zone-H) and etc, as affected URLs are not linked from
existing pages and do not belong to existing pages.
Usually caused by weak authentication controls, application
vulnerabilities and insufficient system/CMS hardening.
25
#RSAC
Defacement via New Content Upload
64% = New
file uploads.
Undetected
by scanners
26
#RSAC
Defacement via New Content Upload
27
#RSAC
#RSAC
Possible Defences
Folder integrity tools to monitor unauthorised changes to
folders.
If website is not regularly updated, consider the use of nonrecordable storage media such as CD-ROM or DVD-ROM as a
preventive measure.
Outbound protection for web servers to provide true real-time
protection against display of defaced content.
28
#RSAC
Best Practices when responding to Web
Defacement
My $0.02 on responses to web
defacements
#RSAC
Take the defaced website offline and isolate immediately.
Show last good copy or show a user-friendly maintenance
page. (Remember the ASEAN Haze case if there is no real-time
display of the maintenance or good page)
In the event there is none, put up a simple HTML maintenance
web page, on a separate web server, and redirect traffic to this
new web server asap.
30
My $0.02 on responses to web
defacements
Clone the offline affected server and perform forensics
analysis.
Analyse the network and web server access logs.
Harden network perimeter defenses to block further attacks.
Remove any identified backdoor or vulnerability from any
other similar servers.
31
#RSAC
My $0.02 on responses to web
defacements
Submit forensics evidence to the police for their follow-up
action.
Identify the last good copy backup of the website content.
Restore the last good backup onto new web and database
servers.
Remove any identified backdoor or vulnerability from the
restored copy and apply patches if new ones are available.
32
#RSAC
My $0.02 on responses to web
defacements
#RSAC
Harden the web application server and its host OS.
Perform vulnerability assessment or penetration testing of the
restored website.
Ensure any new settings on the network defenses are properly
configured.
Go live with restored website.
33
#RSAC
Data Leakage from Web Servers The forgotten child of DLP
Existing DLP is too focused on leakage from
users
#RSAC
Most Data Leakage Protection (DLP) solutions focus on end
users, e.g. mobile devices, file servers, outbound email, users'
web surfing.
One of the reasons is that endpoint-focused DLP solutions can
severely impact the performance of your web portals.
Most network-based solutions function in a forward proxy
mode to provide DLP against end users, hence they cannot
protect data leakage from web servers at the same time, as it
will require a reverse proxy mode.
35
#RSAC
Possible Causes
Negligence is the No. 1 culprit.
Insecure CMS configuration.
Application vulnerabilities, such as insecure direct object
references.
36
Examples of Data Leakage from Web Servers
K Box Entertainment
Group...the personal
data of 317,000
members.
37
#RSAC
Examples of Data Leakage from Web Servers
...personal information
of about
4,000 people on its
online mailing list
was compromised.
38
#RSAC
Examples of Data Leakage from Web Servers
... included the NRIC
number of Health
Minister Khaw Boon
Wan...
39
#RSAC
Examples of Data Leakage from Web Servers
URL:
.....attachmentCd=1008
84
40
#RSAC
Examples of Data Leakage from Web Servers
URL:
.....attachmentCd=1008
85
41
#RSAC
#RSAC
Possible Defences
Configure your DLP solution to function in a reverse proxy
mode in front of your web servers.
Outbound protection for web servers to provide true real-time
protection against display of defaced content.
42
#RSAC
Best Practices when responding to Web
Data Leakages
My $0.02 on responses to web data leakages
#RSAC
Remove leaking file immediately.
OR take the affected website offline and isolate immediately.
Show last good copy or show a user-friendly maintenance
page. (Remember the ASEAN Haze case if there is no real-time
display of the maintenance or good page)
In the event there is none, put up a simple HTML maintenance
web page hosted on a separate web server and redirect traffic
to this new web server asap.
44
My $0.02 on responses to web data leakages
Clone the offline affected server and perform forensics
analysis.
Analyse the network and web server access logs.
Monitor search engines, public forums (especially hacker
forums), social media and P2P file sharing networks for any
public sharing of leaked data.
45
#RSAC
My $0.02 on responses to web data leakages
Assess the privacy impact of the leakage and inform the
persons affected by the leakage.
Submit forensics evidence to the police.
Identify the last good copy backup of the website content.
Restore the last good backup onto new web and database
servers.
Remove any identified backdoor or vulnerability from the
restored copy and apply patches if new ones are available.
46
#RSAC
My $0.02 on responses to web data leakages
#RSAC
Harden the web application server and its host OS.
Perform vulnerability assessment or penetration testing of the
restored website.
Ensure any new settings on the network defenses are properly
configured.
Go live with restored website.
Implement tighter content upload procedures, e.g. 4-eyes
principle for all content upload.
47
Apply What You Have Learned Today
#RSAC
Next week you should:
Assess effectivesness of your current defences against the major types of web defacement and
major causes of data leakage from web servers.
In the first three months following this presentation you should:
Assess the residual risks facing your websites.
Identify appropriate anti-defacement and anti-leakage controls for your critical websites.
Within six months you should:
Select a security system which allows real-time protection for all your organisation's websites.
Drive an implementation project to protect all your organisation's websites.
48
#RSAC
The End
Thank You
49