web defacements and data leakages - twin towers website · web defacements and data leakages - twin...

SESSION ID:

#RSAC

Wong Onn Chee

Web Defacements and Data Leakages - Twin Towers website threats

GPS1-F04

MD, Infotect Security

#RSAC

Web Defacements in ASEAN Govt Websites

0 14 1,250

17 124 18 61 0 736 142 81 247

19,338

103

2,325

86

2,468

38

19,491

1,927

0

5000

10000

15000

20000

25000

Brunei (gov.bn) Cambodia(gov.kh)

Indonesia(go.id)

Laos (gov.la) Malaysia(gov.my)

Myammar(gov.mm)

Philippines(gov.ph)

Singapore(gov.sg)

Thailand (go.th) Vietnam(gov.vn)

Confirmed Web Defacements

2016 (ytd) Total

2

#RSAC

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.

Web Defacements in ASEAN Govt Websites

3

#RSAC

Data Leakage From US Entities

2,361 9 0 65 101 2,511 0 448

120,605

3 1

28,201 8,639 0 192 342

59,348

1,042 1,691 4,565 55 8,383

313,378

255,283

12,748

58,602

19,507 293

-

50,000

100,000

150,000

200,000

250,000

300,000

350,000

Business (Others) FSI Retail Education Government Medical NGO

No. of Personal Records Leaked ('000)

2016 (ytd) 2015 2014 Total (from 2005)

4

#RSAC

Source: PrivacyRights ClearingHouse (www.privacyrights.org)

Search criteria: Unintended disclosure

Hacking or malware

Unknown or others


5

#RSAC


Excluded:

Payment card fraud, e.g. skimming of payment cards

Insider

Physical loss

Portable devices

Stationary devices

6

#RSAC

Web Defacements -Unsolicited "Free Web Design" Services

#RSAC

Types of Web Defacements

Existing Content

Conditional ReflectedNew Content Upload

8

#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

#RSAC

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


11

#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

#RSAC


13

#RSAC

Possible Defences

File integrity tools if CMS is not used. If website is not regularly updated, consider the use of non-recordable 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

#RSAC

Conditional Content Defacement

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

#RSAC


Google Search Results Poisoning

16

#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.


18

#RSAC

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


20

#RSAC


21

#RSAC


22

#RSAC


23

#RSAC

Possible Defences


24

#RSAC

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


64% = New file uploads. Undetected by scanners

26

#RSAC


27

#RSAC

Possible Defences

Folder integrity tools to monitor unauthorised changes to folders.

If website is not regularly updated, consider the use of non-recordable storage media such as CD-ROM or DVD-ROM as a preventive measure.


28

#RSAC

Best Practices when responding to Web Defacement

#RSACMy $0.02 on responses to web defacements

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


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


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


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

#RSACExisting DLP is too focused on leakage from users

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

#RSAC

Examples of Data Leakage from Web Servers

K Box Entertainment Group...the personal data of 317,000members.

37

#RSAC


...personal information of about 4,000 people on its online mailing list was compromised.

38

#RSAC


... included the NRIC number of Health Minister Khaw Boon Wan...

39

#RSAC


URL:.....attachmentCd=100884

40

#RSAC


URL:.....attachmentCd=100885

41

#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

#RSAC

My $0.02 on responses to web data leakages

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

#RSAC


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


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


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

#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.

Apply What You Have Learned Today

48

#RSAC

The End

Thank You

49

web defacements and data leakages - twin towers website · web defacements and data leakages - twin...

Documents