2015-cloud-security-report-q2

akamai’s [state of the internet] / security
Q2 2015 report
[Volume2/Number2]

[state of the internet] / security / Q2 2015
FA S T E R F O R W A R D T O T H E L AT E S T
G L O B A L B R O A D B A N D T R E N D S
Join us at stateoftheinternet.com for a glimpse into the future of connectivity
Download Akamai’s latest
[state of the internet] report
TAP
HERE

3
akamai’s [state of the internet] / security / Q2 2015 / www.stateoftheinternet.com
[LETTER FROM THE EDITOR]
letter from the editor / The q2 2015 State of the
Internet— Security Report builds on the significant changes
we made in last quarter’s report.
With this edition, we’ve continued to combine attack data
previously published in the classic State of the Internet
Report with the data previously published in the quarterly
Prolexic DDoS Attack Report. The two data sources help
form a more holistic view of the Internet and the attacks
that occur on a daily basis.
Each technology collects a distinct data set that represents a
unique view of the Internet. This allows Akamai to compare
and contrast the different indicators of attack activity.
We explore which industries among our customer base
suffered the highest volume of attacks, which attack
techniques and vectors were more common, and where the
attack traffic originated.
We hope you find it valuable.
As always, if you have comments, questions, or suggestions
regarding the State of the Internet Security Report, the
website,orthemobileapplications,connectwithusviaemail
atstateoftheinternet-security@akamai.comoronTwitterat
@State_Internet.
You can also interact with us in the State of the
Internet subspace on the Akamai Community at
https://community.akamai.com.
Akamai Technologies

4
[TABLE OF CONTENTS]
5 [SECTION]1
= ANALYSIS + EMERGING TRENDS
9 1.1 / DDoS Activity
9 1.1A
/ DDoS Attack Bandwidth, Volume and Duration
10 1.1B
/ Mega Attacks
13 1.1C
/ DDoS Attack Vectors
15 1.1D
/ Infrastructure Layer vs. Application Layer DDoS Attacks
19 1.1E
/ Top 10 Source Countries
21 1.1F
/ Target Industries
22 1.1G
/ DDoS Attacks — A Two-year Look back
24 1.2 / Kona Web Application Firewall Activity
26 1.2A
/ Web Application Attack Vectors
27 1.2B
/ Web Application Attacks Over HTTP vs. HTTPS
29 1.2C
/ Top 10 Source Countries
30 1.2D
/ Top 10 Target Countries
31 1.2E
/ Normalized View of Web Application Attacks
35 1.2F
/ Future Web Application Attacks Analysis
35 1.3 / Data Sources
37 [SECTION]2
= MULTI-VECTOR DDoS ATTACKS
38 2.1 / Attack Signatures
40 2.2 / ACK and SYN Behavior in a Distributed Attack
41 2.3 / Source Countries
41 2.4 / Not DDoS-for-Hire
42 2.5 / Summary
43 [SECTION]3
= CASE STUDY: WORDPRESS AND THE
DANGER OF THIRD-PARTY PLUGINS
44 3.1 / General Findings
46 3.2 / Cross-Site Scripting
47 3.3 / Email Header Injection
48 3.4 / Open Proxy Scripts
52 3.5 / Command Injection
54 3.6 / Cleanup
54 3.7 / Mitigation and Best Practices
59 [SECTION]4
= Tor: THE PROS AND CONS
60 4.1 / Tor, the Foes
61 4.2 / Risk Analysis
62 4.3 / Tor Traffic vs. Non-Tor Traffic
64 4.4 / Tor Attacks by Category
65 4.5 / Tor Attack Distribution by Target Industry
65 4.6 / Tor Attack Distribution by Target Country
65 4.7 / Potential Impact on Business
67 4.8 / Summary
68 [SECTION]5
= CLOUD SECURITY RESOURCES
68 5.1 / OurMine Team Attack Exceeds 117 Gbps
69 5.2 / RIPv1 Reflection DDoS Makes a Comeback
71 5.2A
/ Third-Party Plugins Ripe for Attack
73 5.2B
/ The Logjam Vulnerability
73 5.2C
/ DD4BC Escalates Attacks
76 [SECTION]6
= LOOKING FORWARD
78 ENDNOTES

[SECTION]1
ANALYSIS +
EMERGING TRENDS
5
T
he second quarter of 2015 set a record for the number of distributed
denial of service (DDoS) attacks recorded on Akamai’s Prolexic Routed
network — more than double what was reported in q2 2014. The profile
of the typical attack, however, has changed. In q2 last year, high-bandwidth,
short-duration attacks were the norm, driven by the use of server-based botnets.
This quarter, less powerful but longer duration attacks were the norm.

6
In q2 2015, the largest DDoS attack measured more than 240 gigabits per second
(Gbps) and persisted for more than 13 hours. The peak bandwidth is typically
constrained to a one to two hour window.
Of course, bandwidth is not the only measure of attack size. q2 2015 saw one of the
highest packet rate attacks recorded across the Prolexic Routed network, which
peaked at 214 million packets per second (Mpps). That volume is capable of taking
out tier 1 routers, such as those used by Internet service providers (ISPs).
syn and Simple Service Discovery Protocol (ssdp) were the most common DDoS
attack vectors this quarter — each accounting for approximately 16% of DDoS
attack traffic. The proliferation of unsecured home-based, Internet-connected
devices using the Universal Plug and Play (UPnP) Protocol continues to make
[SECTION]1
Compared to q2 2014
• 132.43% increase in total DDoS attacks
• 122.22% increase in application layer (Layer 7) DDoS attacks
• 133.66% increase in infrastructure layer (Layer 3 4) DDoS attacks
• 18.99% increase in the average attack duration: 20.64 vs. 17.35 hours
• 11.47% decrease in average peak bandwidth
• 77.26% decrease in average peak volume
• 100% increase in attacks 100 Gbps: 12 vs. 6
Compared to q1 2015
• 7.13% increase in total DDoS attacks
• 17.65% increase in application layer (Layer 7) DDoS attacks
• 6.04% increase in infrastructure layer (Layer 3 4) DDoS attacks
• 16.85% decrease in the average attack duration: 20.64 vs. 24.82 hours
• 15.46 increase in average peak bandwidth
• 23.98% increase in average peak volume
• 50% increase in attacks 100 Gbps: 12 vs. 8
• As in q1 2015, China is the quarter’s top country producing DDoS attacks

7
them attractive for use as ssdp reflectors. Practically unseen a year ago, ssdp attacks
have been one of the top attack vectors for the past three quarters. syn floods have
continued to be one of the most common vectors in all volumetric attacks, dating
back to the first edition of these security reports in q3 2011.
We’ve also seen significant growth in the number of multi-vector attacks, with half
of all DDoS attacks employing at least two methods in q2 2015. Multi-vector attacks
often leverage attack toolkits from the DDoS-for-hire framework. One specific
combination of vectors has appeared repeatedly in attacks greater than 100 Gbps:
the simultaneous use of syn and udp reflection-based vectors. These attacks are
profiled in more detail in Section 2 of this report.
During q2 2015, the online gaming sector was once again the most frequent
target of DDoS attacks. Online gaming has remained the most targeted industry
since q2 2014.
As has been the case in recent quarters, many DDoS attacks were fueled by malicious
actors such as DD4BC and copycats utilizing similar methodologies. These
actors use DDoS as a means of extortion, to gain media attention and notoriety
from peer groups, or to damage reputations and cause service disruptions in a
number of industries.
When looking at Layer 7 DDoS attack traffic, we track the last hop ip address of
DDoS attacks against the national ip ranges. In the latest analysis, China remained
the top producer of non-spoofed DDoS attack traffic at 37%, compared to 23% last
quarter. The us was the second-largest source of attacks at 17%, with the uk coming
in third with 10% of all attacks. All three countries showed significant growth in the
number of attacks originating from within their borders, with each showing a 50%
increase compared with the previous quarter.
[SECTION]1

8
Last quarter, we began reporting on web application attacks across the Akamai
Edge network for the first time, reporting on seven common attack vectors. For the
second quarter of 2015, we have added two new attack types: cross-site scripting
(xss) and Shellshock. Of the 352.55 million attacks we analyzed, Shellshock, a Bash
bug vulnerability first tracked in September 2014, was leveraged in 49% of the
attacks. However, the majority of the Shellshock attacks targeted a single customer
in the financial services industry.
Other than Shellshock, sql injection (SQLi) and local file include (lfi) attacks
remained the top application attack vectors, as they were in the previous report.
The retail and financial services industries remained the most frequent target of
web application attacks.
Each quarter, we report on emerging threats to provide better insight into the overall
threat landscape. In q1, we explained how malicious actors were exploiting third-
party website plugins for website defacement. This quarter, we took a closer look at
plugin security in general and uncovered 49 previously unreported vulnerabilities
with third-party WordPress plugins. These are detailed in Section 3 of this report.
Additionally, we often receive questions from customers on whether to allow traffic
from Tor exit nodes. Tor provides anonymity for users by routing traffic through
several cooperating nodes before existing to the public Internet in order to mask the
source ip of the user. This cloak of anonymity makes it attractive for people wishing
to avoid surveillance, which of course includes malicious actors. In Section 4,
we analyze how frequently Tor exit nodes were used for malicious purposes and
provide guidance on what factors to consider when deciding whether to allow
traffic from Tor exit nodes.
In q2 2015, Akamai also tracked a number of new attack techniques, vulnerabilities
and criminal operation campaigns that warranted the release of threat advisories.
These are profiled in more detail in Section 5 of the report. They include:
[SECTION]1

9
• An OurMine Team attack exceeding 117 Gbps
• The resurgence of RIPv1 reflection DDoS attacks
• Third-party WordPress plugin vulnerabilities
• The Logjam vulnerability
• Ongoing attacks from DD4BC
1.1 / DDoS Activity / The second quarter of 2015 was marked by a 132% increase
in DDoS attacks compared with the same period last year. This included a 122%
increase in application layer DDoS attacks and a 134% increase in infrastructure
layer DDoS attacks. While the attacks were not quite as large as last year, they lasted
an average of three hours longer and increased in frequency and complexity.
The changes in DDoS activity quarter over quarter are typically more modest. In
q2, we saw a 7% increase in total DDoS attacks compared with q1, and an average
four-hour decrease in attack duration.
While application layer DDoS attacks continued to account for about 10% of all
DDoS attacks, they’re growing much more rapidly than infrastructure attacks, with
an18%increaseinthenumberofattacksoverthepreviousquarter.Theinfrastructure
layer grew at less than half that rate, with a 6% increase.
At 16%, syn traffic surpassed ssdp traffic, but just barely. This was mostly due to a
drop in ssdp traffic, from 21% last quarter to just under 16% this quarter.
1.1A
/ DDoS Attack Bandwidth, Volume and Duration / The number of
DDoS attacks has steadily increased quarter by quarter, though the median peak
attack bandwidth and volume has continued to drop since the third quarter of 2014.
This quarter, average peak attack bandwidth was 7 Gbps, lower than the average
peak of nearly 8 Gbps seen in q2 2014 and slightly up from the 6 Gbps average
in q1 2015.
[SECTION]1

10
[SECTION]1
Packet per second attack volume dropped significantly compared with q2 2014,
when the average peak was a record-setting 12 Mpps. But compared to last
quarter, the average peak attack volume was up slightly, 3 Mpps as compared
to 2 Mpps.
In q2 2015, the average DDoS attack lasted nearly 21 hours. That represents a 19%
increase in attack duration compared with q2 2014, but a 17% decrease in attack
duration compared with q1 2015.
The trends of the past two quarters show that malicious actors are favoring attacks
with lower peak bandwidth, but are launching more frequent and longer attacks
than they did a year ago.
1.1B
/ Mega Attacks / In q2 2015, 12 DDoS attacks registered more than 100 Gbps,
as shown in Figure 1-1. This is up from q1 2015, when there were eight mega attacks,
but still not as many as the record-setting 17 mega attacks of q3 2014.
In q2 2015, the largest DDoS attack measured nearly 250 Gbps, an increase in size
from the largest (170 Gbps) attack in q1 2015. Of the 12 mega attacks, the Internet
and telecom sector received the largest share of attacks, albeit indirectly. The 10
attacks listed as Internet and telecom were actually targeting gaming sites hosted on
the customer network.
In q1 2015, the 170 Gbps attack was generated a multi-vector volumetric attack that
used the same padded syn flood, along with a udp fragment flood and a udp flood
as seen in this quarter’s largest attack.
That is compared with q2 2014, when the most significant attack was measured by
packet per second volume. That attack was a dns amplification attack out of China
that peaked at 110 Mpps.

11
In q2 2015, five attacks peaked at more than 50 Mpps, as shown in Figure 1-2. Attack
campaigns of this volume can exhaust ternary content addressable memory (tcam)
resources in border edge routers, such as those used by Internet service providers
(ISPs). This can result in packet loss, while stressing the cycles of the router’s
central processing unit (cpu). This can then result in collateral damage across the
ISP’s network, which can manage production traffic for hundreds or thousands
of organizations.
260
240
220
200
180
160
140
120
100
80
60
40
20
0
3-Apr
13:12
4-Apr
4:58
8-Apr
5:32
9-Apr
3:40
11-Apr
3:30
18-Apr
4:44
24-Apr
3:25
25-Apr
14:15
30-Apr
6:03
1-May
14:25
4-May
6:51
18-May
20:15
Internet/Telecom Gaming
Gbps
Attacks Date and Starting Time (GMT)
249
144
106 109
144
210
118
157
145
126 121
115
Q2 2015 Attacks 100 Gbps
Figure 1-1: Ten of the mega attacks targeted the Internet and telecom industry
[SECTION]1

12
The 214 Mpps attack on June 12 was one of the three largest DDoS attacks ever
recorded across the Prolexic Routed network. The attack was based on a udp flood
with 1-byte packets — the smallest possible payload — and it generated 70 Gbps of
attack traffic.
The 80 Mpps on May 15 was a little more complex, based on a Christmas tree DDoS
flood, with every tcpflag turned on, targeting two /24 subnets over ports 80 and 443.
As the attack continued, the attacker varied the tcp flag sequence configurations,
while using an average payload size of 14-byte packets.
[SECTION]1
220
200
180
160
140
120
100
80
60
40
20
0
7-Apr
11:54
24-Apr
3:25
15-May
23:10
8-June
4:51
12-June
10:52
Internet/TelecomHigh Tech / Consulting Services Gaming
Mpps
Attack Date and Starting Time (GMT)
63.09 60.46
79.62
52.68
214.35
Q2 2015 Attacks 50 Mpps
Figure 1-2: Several of the Q2 2015 mega attacks specifically targeted the TCAM
limitations in tier 1 ISP routers

13
1.1C
/ DDoS Attack Vectors / In q2 2015, syn floods represented the top overall
infrastructure-based attack (16%), bypassing ssdp by a razor-thin margin. ssdp was
the top attack vector in q1 2015 and q4 2014. In q2, ssdp attacks represented just
under 16% of all attacks. This vector first appeared in q3 2014 and has not been
subject to the same cleanup efforts as ntp and dns, since many ssdp reflection
attacks are leveraging unsecured in-home consumer devices. These attacks have
two victims: the owners of the devices used as reflectors and the actual attack target.
These owners are typically home users who are unlikely to realize that their devices
are participating in attacks. Even if they do notice slowness in their networks, they
may not have the expertise to troubleshoot, mitigate or detect the cause.
Figure 1-3 displays the frequency of observed attack vectors at the DDoS layer.
[SECTION]1

14
Percentage
InfrastructureDDoSLayerApplicationDDoSLayer
0 5 10 15 20
PUSH
HTTP POST
HEAD
HTTP GET
Other
NTP
UDP
FRAGMENT
UDP
FLOODS
SYN
SSDP
RESET
ICMP
DNS
CHARGEN
ACK 2.14%
6.42%
8.74%
2.56%
1.02%
15.86%
16.00%
11.49%
13.63%
9.44%
2.46%
8.74%
0.70%
0.37%
0.42%
FIN FLOODS (0.79%)
RIP (0.09%), XMAS (0.42%)
RP (0.37%), SNMP (0.65%)
SYN PUSH (0.14%)
Application
DDoS Layer
10.23%
Infrastructure
DDoS Layer
89.77%
Figure 1-3: Nearly 90% of DDoS attacks targeted infrastructure layer in Q2 2015,
a trend that has continued for the past year
DDoS Attack Vector Frequency, Q2 2015
[SECTION]1

15
Infrastructure-based attacks accounted for the lion’s share of DDoS activity in the
second quarter. Application layer DDoS attacks accounted for 10% of all activity,
while the infrastructure layer experienced 90% of DDoS attacks, down slightly
from 91% in q1. This trend of mostly infrastructure attacks has continued for more
than one year, as attackers have relied more and more on reflection vectors as the
primary DDoS attack method. Not only do these reflection attacks obscure the true
ip addresses of the attackers, they also require fewer attack resources relative to the
size of the attack.
That said, DDoS attack scripts on the application side have been shifting more
towards the use of non-botnet based resources, such as attack scripts that leverage
open proxies on the Internet. This trend, along with the continued abuse of
WordPress and Joomla-based websites as get flood sources, may pave the way to
a continued increase in application-based reflected DDoS attacks that abuse web
application frameworks.
1.1D
/ Infrastructure Layer vs. Application Layer DDoS Attacks /
ssdp attacks accounted for a little less than 16% of all attacks, while syn floods
accounted for 16% of attacks. As the 100+ Gbps attacks show, the syn flood attack
plays a major role in the larger attacks. udp floods accounted for 11%, while udp
fragments accounted for 14%. As stated in previous reports, the fragments are
sometimes a byproduct of other infrastructure-based attacks. In particular, udp-
based chargen and dns reflection attacks together accounted for just over 15%
of attacks.
By comparison, in q2 2014 the most used infrastructure-based attack vectors were
syn floods (26%), udp fragment (13%), udp floods (11%) and dns attacks (8%).
Additionally that quarter, ntp attacks accounted for 7%, chargen for 5%, icmp for
7%, and ack floods for 5%. ssdp and syn have continued to gain popularity since it
was first observed back in q3 2014.
[SECTION]1

16
At the application layer, httpgetflood attacks came in at 7.5% head, httppostand
push attacks accounted for less than 2% each. Many of the get flood attacks were
based on a combination of the Joomla, WordPress and get flood attacks via proxy.
httpgetfloodshavebeenconsistentlyfavoredbyattackerstargetingtheapplication
layer. The top application-layer DDoS attack in q4 2014 was http get floods, which
was the case as well in q1 2014.
A full comparison of attack vector frequency is shown in Figure 1-4 and Figure 1-5.
[SECTION]1

Figure 1-4: The 10 most common attack vectors over the past five quarters
ACK
4.86%
4.54%
3.92%
5.20%
5.78%
6.42%
8.11%
7.42%
10.51%
5.93%
8.74%
7.46%
8.90%
8.42%
7.47%
8.74%
6.59%
4.18%
8.05%
3.59%
2.56%
7.35%
4.56%
8.15%
6.88%
9.44%
7.31%
14.62%
20.78%
15.86%
25.73%
23.09%
16.91%
15.79%
16.00%
11.24%
15.25%
10.58%
13.25%
11.49%
13.41%
13.88%
13.95%
12.01%
13.63%
3.81%
2.77%
1.99%
2.14%
CHARGEN
DNS
HTTP GET
ICMP
NTP
SSDP
SYN
UDP
FLOODS
UDP
FRAGMENT
0 5 10 15 20 25 30
Q2 2014 Q3 2014 Q4 2014 Q1 2015 Q2 2015
DDoS Attack Vector Frequency by Quarter

FIN FLOODS
FIN PUSH
HEAD
HTTP POST
IGMP
FRAGMENT
PUSH
RESET
RIP
RP
SNMP
SYN PUSH
TCP
FRAGMENT
XMAS
0.0 0.5 1.0 1.5 2.0 2.5 3.0
Figure 1-5: These 13 attack vectors have been seen less frequently during the past
five quarters
DDoS Attack Vector Frequency by Quarter
Q2 2014 Q3 2014 Q4 2014 Q1 2015 Q2 2015
2.05%
2.27%
3.03%
0.43%
0.11%
0.11%
0.76%
1.30%
0.22%
0.11%
0.22%
0.11%
0.42%
0.53%
0.21%
0.11%
0.42%
0.64%
0.64%
0.65%
0.21%
0.27%
1.15%
0.67%
0.27%
0.40%
0.07%
0.07%
0.54%
0.94%
0.20%
0.13%
0.79%
0.37%
0.65%
0.42%
0.37%
0.14%
0.42%
1.02%
0.09%
0.70%
0.75%
0.70%
1.15%
1.15%
0.45%
0.35%
0.05%
0.90%
0.25%
0.15%

19
1.1E
/ Top 10 Source Countries / China remained the top producer of non-
spoofed DDoS attack traffic at 37% compared to 23% last quarter. The us was the
second-largest source of attacks (17%), with the uk coming in third (10%). All three
countries showed significant growth in the number of attacks originating from
within their borders, with each showing a 50% increase over the previous quarter.
There is a considerable gap between the leaders and the rest of the pack with roughly
7% of attack traffic originating from India, while traffic from the Korean Peninsula,
Russia and Germany had a combined 13%, with each region contributing a little
more than 4% respectively. Australia and Taiwan made the top 10 for the first time,
though attack traffic from both countries only registered 4% apiece. Australia’s
appearance on the list is likely due to the increase adoption of high speed internet
access throughout NBN and connectivity of IOT devices in the region.
Taiwan 4%
Australia 4.18%
Germany 4.29%
RussianFederation 4.45%
Korea 4.53%
US
17.88%
China
37.01%
UK
10.21%
India
7.43%
Spain
6.03%
Figure 1- 6: Non-spoofed attacking IP addresses by source country, for DDoS attacks
mitigated during Q2 2015
Top 10 Source Countries for DDoS Attacks, Q2 2015
[SECTION]1

20
akamai’s [state of the internet] security / Q2 2015 / www.stateoftheinternet.com
[SECTION]1
Taiwan
Australia
Germany
Russia
Korea
Spain
India
UK
US
China
Q2
2015
0 10% 20% 30% 40%
Russia
France
UK
Korea
India
Spain
Italy
US
Germany
China
Q1
2015
0 10% 20% 30% 40%
4.00%
4.18%
4.29%
4.45%
4.53%
6.03%
7.43%
10.21%
17.88%
37.01%
5.95%
6.03%
6.17%
6.23%
6.93%
7.29%
8.38%
12.18%
17.39%
23.45%
Thailand
Russia
Turkey
Brazil
India
Mexico
Germany
China
Japan
US
Q2
2014
0 10% 20% 30% 40%
4.44%
4.87%
5.16%
7.94%
8.26%
8.31%
10.30%
12.30%
18.16%
20.26%
Figure 1-7: The US and China typically are among the top three non-spoofed sources
for attacking IPs
Top 10 Source Countries for DDoS Attacks by Quarter

21
[SECTION]1
1.1F
/ Target Industries / The online gaming sector was particularly hard hit
in q2 2015, accounting for more than 35% of all attacks. Gaming was followed by
software and technology, which suffered 28% of all attacks, as shown in Figure 1-8.
Internet and telecom suffered 13% of attacks, followed by financial services (8%),
media and entertainment (9%), education (3%), retail and consumer goods (3%),
and the public sector (1%).
Online gaming / Online gaming has remained the most targeted industry since q2
2014 and remained steady at 35% compared to last quarter. In q4 2014, attacks were
fueled by malicious actors seeking to gain media attention or notoriety from peer
groups, damage reputations and cause disruptions in gaming services. Some of the
largest console gaming networks were openly and extensively attacked in December
2014, when more players were likely to be affected due to the new networked games
launched for the holiday season.
Software and technology / The software and technology industry includes
companies that provide solutions such as Software-as-a-Service (SaaS) and cloud-
based technologies. This industry saw a slight 2% drop in attack rates compared
to last quarter.
Internet and telecom / The Internet and telecom industry includes companies that
offer Internet-related services such as ISPs and dns providers. It was the target of
13% of attacks, a 1% drop over the previous quarter.
Financialservices/Thefinancialindustryincludesmajorfinancialinstitutionssuch
as banks and trading platforms. The financial industry saw a small (less than 1%)
drop in attacks from the previous quarter. While overall there was a slight reduction
in attacks targeting this industry, it’s worth mentioning that they still saw some of
the larger attacks (100+ Gbps) of the quarter.
Media and entertainment / The media industry saw a slight increase in the
percentage of attacks, from 7% in q1 2015 to 9% in q2 2015.

22
1.1G
/ DDoS Attacks — A Two-Year Look Back / Figure 1-9 shows DDoS attack
size as a function of time. A box and whiskers plot is used to show the measure
of central tendency. The dark line in the box shows the median attack size. Fifty
percent of the observed attacks were larger than the median and 50% of the observed
attacks were smaller than the median. The box shows the interquartile range (iqr):
Both boxes together encompass 50% of all attacks, with 25% of the attacks situated
above the box and 25% of the attacks represented below the box. Each attack that
took place during a given quarter is displayed as a dot so we can observe the size of
individual attacks.
[SECTION]1
Education
Financial Services
Gaming
Hotel Travel
Internet Telecom
Media Entertainment
Public Sector
Retail Consumer Goods
Software Technology
0% 5% 10% 15% 20% 25% 30% 35% 40%
Q2 2015Q1 2015
4.93%
2.50%
8.40%
0.87%
13.77%
12.90%
7.45%
9.41%
1.82%
1.05%
2.25%
2.60%
25.19%
27.74%
0.41%
35.32%
35.20%
8.19%
DDoS Attack Frequency by Industry
Figure 1- 8: The gaming industry remains a top target for malicious actors

23
Before we dive into the shape of the data, here are a few quick points to be aware of.
1. We’re making a conscious choice to use the median to describe an average
attack rather than the mean. The median is much more resilient to the presence
of outliers because it represents the point where 50% of all attacks are larger or
50% are smaller.
2. The set of observed DDoS attacks include an enormous number of small attacks
and a few large ones. For legibility purposes, we’re choosing to use a logarithmic
scale, which each interval representing a 10-fold increase.
3. There is a notch in each of the boxes centered on the median. The notches
showconfidenceintervalsforthemedian.Ifthenotchesfortwoconsecutiveboxes
overlap,thenthereisnotastatisticallysignificantdifferenceinthemedianattack
size, as is exemplified by the fourth quarter of 2014 through the current quarter.
Looking at the time series, a few patterns stand out. First, a significant increase in
attack size occurred in q1 2014. The first four quarters we tracked (q1 – q4 2013)
look similar to one another. The upper boundary of the iqr is roughly the same and
three of the four medians are statistically similar.
However, things changed between q4 2013 and q1 2014. The upper bound of the
iqr increased dramatically (recall, this is a logarithmic scale), as has the median
attack size. In q4 2014, things change once again. This time we see a statistically
significant drop in the upper bound of the iqr, however, the median attack size
remained unchanged. The size of the large attacks appears to be clumping closer
to the median.
[SECTION]1

24
1.2 / Kona Web Application Firewall Activity / For the q2 2015 report, we
concentrated our analysis on nine common web application attack vectors. They
represent a cross section of many of the most common categories seen in industry
vulnerability lists. Akamai’s goal was not to validate any one of the vulnerability
lists, but instead to look at some of the characteristics of these attacks as they transit
a large network. As with all sensors, the data sources used by Akamai have different
levels of confidence; for this report, we focused on traffic where Akamai has a high
confidence in the low false-positive rate of its sensors. Other web application attack
vectors are excluded from this section of the report.
SQLi / sql injection is an attack where adversary-supplied content is inserted
directly into a sql statement before parsing, rather than being safely conveyed post-
parse via a parameterized query.
LFI / Local file inclusion is an attack where a malicious user is able to gain
unauthorized read access to local files on the web server.
[SECTION]1
DDoS Size as a Function of Time
100 Gbps
10 Gbps
1 Gbps
100 Mbps
10 Mbps
1 Mbps
100 Kbps
Q1
2013
Q2
2013
Q3
2013
Q4
2013
Q1
2014
Q2
2014
Q3
2014
Q4
2014
Q1
2015
Q2
2015
Figure 1-9: The IQR chart is on a logarithmic scale and shows significant shifts in DDoS
attack size and frequency over the past 10 quarters

25
RFI / Remote file inclusion is an attack where a malicious user abuses the dynamic
file include mechanism, which is available in many web frameworks, and loads
remote malicious code into the victim web application.
PHPi / php injection is an attack where a malicious user is able to inject php code
from the request itself into a data stream, which gets executed by the php interpreter,
such as by use of the eval() function.
CMDi / Command injection is an attack that leverages application vulnerabilities
to allow a malicious user to execute arbitrary shell commands on the
target system.
JAVAi / Java injection is an attack where a malicious user injects Java code, such
as by abusing the Object Graph Navigation Language (ognl), a Java expression
language. This kind of attack became very popular due to recent flaws in the
Java-based Struts Framework, which uses ognl extensively in cookie and query
parameter processing.
MFU / Malicious file upload (or unrestricted file upload) is a type of attack where a
malicious user uploads unauthorized files to the target application. These potentially
malicious files can later be used to gain full control over the system.
XSS / Cross-site scripting is an attack that allows malicious actor to inject client-
side code into web pages viewed by other. When an attacker gets a user’s browser to
execute his/her code, the code will run within the security context (or zone) of the
hosting web site. With this level of privilege, the code has the ability to read, modify
and transmit any sensitive data accessible by the browser.
Shellshock / Disclosed in September 2014, Shellshock (CVE-2014-6271) is a
vulnerability in the Bash shell (the default shell for Linux and mac os x) that allows
for arbitrary command execution by a remote attacker. The vulnerability had existed
in Bash since 1989, and the ubiquitous presence of Bash makes the vulnerability a
tempting target.
[SECTION]1

26
1.2A
/ Web Application Attack Vectors / This quarter, we added two new
data points to the web application attacks we are reporting on: xss and Shellshock.
Including events based on Shellshock nearly doubled the number of attack events we
analyzed this quarter, with 173 million Shellshock attacks against Akamai customers
in this quarter alone. Shellshock also significantly shifted the balance of attacks over
http vs. https, in large part because these attacks happen 20 times more often over
https than they do over unencrypted channels. Luckily, Shellshock exploitation
attempts appear to be declining. Where Shellshock accounted for nearly 95% of
all events over https in April, by the end of July, it accounted for slightly more
than 5% of all events. Overall, Shellshock accounted for 49% of web application
attacks in q2 2015.
Looking closely at the Shellshock attack data, we noticed that approximately 95%
of the Shellshock attacks were related to a single worldwide campaign against a
large financial services customer. The attack was highly distributed and the top
source countries were China (78.4%), Taiwan (5.09%), us (2.86%), Brazil (2.53%),
and Indonesia (1.01%).
SQLi attacks came in a distant second, accounting for 26% of all attacks. If Shellshock
is discounted from the numbers, SQLi would have been 55% of attacks, with more
than 92 million attacks in the quarter. This represents a greater than 75% increase in
SQLi alerts in the second quarter alone.
In contrast, lfi attacks dropped significantly this quarter. In the last week of q1, we
saw nearly 75 million lfi alerts due to an attack on a pair of large retail customers,
while in all of q2 we only saw 63 million alerts. lfi accounted for 18% of all alerts if
we include the new categories, but for 38% of attacks if Shellshock and xss attacks
are not included.
[SECTION]1

Shellshock, SQLi and lfi attacks combined accounted for 93% of all web application
attacks in the second quarter, with the remaining six categories accounting for 7%
in total. Protecting your organization against these three attack types should be
heavily considered.
1.2B
/ Web Application Attacks Over HTTP vs. HTTPS / Among the web
application attacks analyzed for the q2 2015 report, 156 million were sent over
(unencrypted) http. This represented 44% of the application attacks.
Given that a large percentage of websites either do not use https for all of their
web traffic, or use it only for safeguarding certain sensitive transactions (such as
login requests), the comparison between http vs. https should be used only for
understanding attack trends between the two communication channels.
That said, encrypted connections (over https) do not provide any additional attack
protection for applications. There is no reason to believe that the attackers would
not have followed a shift of the vulnerable applications to https. There were 196
million attacks over https observed during the quarter, making up 56% of the
attacks. Figure 1-10 shows the ratio between https and http attacks.
[SECTION]1
44% 56%
HTTP HTTPS
Figure 1-10: The majority of web application attacks were sent over HTTPS in Q2
Total Attacks, HTTP vs. HTTPS, Q2 2015
27

28
Of the 196 million attacks over https, the most prevalent attack vectors were
Shellshock (49%), and SQLi (26%). https-based lfi attacks accounted for 18% while
PHPi attacks accounted for 1.5%. CMDi, JAVAi, rfi and mfu attacks accounted for
less than 1% each. The weekly breakdown of attack vectors is shown in Figure 1-11
and Figure 1-12.
Week 13
Week 14
Week 15
Week 16
Week 17
Week 18
Week 19
Week 20
Week 21
Week 22
Week 23
Week 24
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
SQLi LFI RFI PHPi CMDi JAVAi MFU XSS Shellshock
Web Application Attack Vectors (HTTPS), Q2 2015
Figure 1-11: Shellshock was a heavily favored attack vector over HTTPS in Q2 2015
[SECTION]1

29
When comparing https-based attacks in each category, against the total in each
category we can see that Shellshock alerts are almost 96% https traffic and only 4%
unencrypted. By contrast, SQLi attacks are carried out over https only 10% of the
time, with 90% of the attacks taking place in plain http traffic. rfi is also heavily
http-based, with only 25% of the alerts from traffic over https.
1.2C
/ Top 10 Source Countries / For the web application attacks analyzed in this
section, China was the top source country of attacking IPs (51%), followed by the us
(15%), Brazil (11%), Germany (7%), Russia (6%), Taiwan (3%) and the Netherlands,
Ukraine and Indonesia (2% each). Ireland is at the bottom with 1% of attacks. Due
to the use of tools to mask the actual location, the creator of the attack traffic may
not have been located in the country detected. These IPs represent the last hop seen.
[SECTION]1
Week 13
Week 14
Week 15
Week 16
Week 17
Week 18
Week 19
Week 20
Week 21
Week 22
Week 23
Week 24
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
SQLi LFI RFI PHPi CMDi JAVAi MFU XSS Shellshock
Web Application Attack Vectors (HTTP), Q2 2015
Figure 1-12: SQLi and LFI were the most prevalent attack vectors over HTTP in Q2 2015

30
The web application attacks analyzed here occur after a tcp session is established.
Therefore, the geographic origins of the attack traffic can be stated with high
confidence. Countries with a higher population and higher internet connectivity
are often seen to be the source of attack traffic.
1.2D
/ Top 10 Target Countries / us-based websites were by far the most
targeted for web application attacks in q2 2015, receiving about 80% of all attacks.
Brazilian-based websites came in a distant second with 7% of attack traffic. Chinese
websites were the third most targeted at 4%, followed by Spanish sites at 2%. Sweden,
Canada, Australia, uk, India and Germany-based websites were each targeted in 1%
of attacks, as shown in Figure 1-14.
[SECTION]1
Figure 1- 13: The top three source countries combined were responsible for 77% of
attacking IPs
Top 10 Source Countries for Web Application Attacks,
Q2 2015
Ireland 1%
Indonesia 2%
Ukraine 2%
Netherlands 2%
Taiwan 3%
Russian Federation 6%
Germany 7%
US
15%
China
51%Brazil
11%

31
[SECTION]1
1.2E
/ A Normalized View of Web Application Attacks by Industry /
Akamai has long tracked DDoS attacks at both the application and network layer,
and DDoS attack statistics are typically the most commented on, reprinted, and
discussed stats that we produce. Over the years, customers have asked for a similar
view into the stealthy application layer attacks that plague enterprises, governments
and others; the attacks that hard-working organizations such as the Open Web
Application Security Project (owasp) have typically tracked and ranked according
to prevalence and danger.
But figuring out how to give our customers a view of what we see has been a long
and arduous challenge. Although Akamai has visibility into 15 – 30% of the world’s
web traffic, the challenge in meeting this goal has been threefold: how to store the
data we see, how to query it, and finally, how to report on it meaningfully.
Methodology / In the past two years, we’ve made great progress in tackling the first
two challenges. Storage, for example, has been largely met by the creation of the
Cloud Security Intelligence (csi) platform, which stores more than 2 petabytes (pb)
Germany 1%
India 1%
UK 1%
Australia 1%
Canada 1%
Sweden 1%
Spain 2%
China 4%
US
81%Brazil
7%
Figure 1- 14: The US is consistently one of the top targets for malicious actors
Top 10 Target Countries for Web Application Attacks,
Q2 2015

32
of threat intelligence data (the equivalent of 2,000 terabytes). This allows Akamai to
store more than 10 tb of attack data every day, which gives us roughly 30 – 45 days
of application layer attack data at any given moment in time. Querying the data has
taken a bit more finesse. During the past two years, we’ve hired a number of data
scientists, analysts and researchers. Today, those researchers make up the Akamai
Threat Research team, a team that has set up dozens of heuristics that automatically
query the stored data on an hourly basis. The insight they extract from the data,
feeds improvements to our Kona Site Defender application protections and our
Client Reputation product. The final challenge is reporting on the data.
Our reporting methodology undertook the following assumptions. We divided all
Akamaicustomersintoeightverticals.(Note:Theverticalswetrackedforapplication
layer attacks are slightly different than they are for network layer attacks. This is
because the integration of the Prolexic and Akamai customer tracking systems is
a work in progress.) For each of the customers in these eight verticals, we tracked
the number of malicious requests across the nine categories of attacks featured in
this report during a 12-week period. The frequency of these attack vectors and the
accuracy of the signatures detecting each of the categories, were both given weight
in the selection of categories.
In order to normalize samples, we removed every sample that accrued more than
5% of total attacks in a week in any single attack vector. Doing so helped smooth
out spikes and what we consider to be anomalies in the data. After adding up all
attacks per vertical and type, we divided the number of attacks in each vertical by
the number of customers in every given vertical. By doing so, we get the average
number of attacks per customer in each vertical.
Since 95% of the q2 2015 Shellshock attacks targeted a single customer, Shellshock
is not included in the normalized view of the data.
[SECTION]1

33
Observations / In q2 2015, the industries that were subjected to the greatest
number of malicious requests were the retail and financial services verticals, as
shown in Figure 1-15. That is in contrast to q1 2015 when the retail and media and
entertainment sectors were the most popular targets.
[SECTION]1
30%
25%
20%
15%
10%
5%
0
B2B
Goods/
Services
B2C
Goods/
Services
Financial
Services
High
Technology
Hotel
Travel
Media
Entertainment
Public
Sector
Retail
Normalized View of Web Application Attacks
by Industry, Q2 2015
Figure 1-15: Distribution of the eight analyzed web application attack vectors
(excluding Shellshock) across the most commonly targeted industries
In the normalized data, the most common attack vector, SQLi, takes advantage of
improper coding of Web applications that allows attackers to inject sql statements
into predefined back-end sql statements such as those used by a login form. This
may in turn allow the attacker to gain access to the data held within your database
or perform other malicious actions such as those described in last quarter’s State
of the Internet Security Report, in the Cruel (sql) Intentions section. SQLi and
lfi attacks were attempted against Akamai customers more than any other attack
vector, and companies in the retail and financial services spaces were the most
commonly attacked.

lfi attacks consist of including local files and resources on the web server via direct
user input (e.g. parameter or cookie). This attack is possible when a web application
includes a local file based on the path received as part of the http request. If
the resource include is not properly sanitized or whitelisted, it can allow certain
manipulations such as directory traversal techniques. The lfi attack will attempt
to read sensitive files on the server that were not intended to be publicly available,
such as password or configuration information. lfi attacks were the second most
common attack vector in q2 2015, most frequently targeting retail and financial
services sites.
The retail sector saw the most SQLi attacks in q2, although the company that was
attacked more than any other company was a financial services customer. That
specific site was particularly hard hit, with 2.5 times as many SQLi attempts as the
next most attacked site.
[SECTION]1
250,000
200,000
150,000
100,000
50,000
0
SQLi Attacks LFI Attacks
B2B
Goods/
Services
B2C
Goods/
Services
Financial
Services
High
Technology
Hotel
Travel
Media
Entertainment
Public
Sector
Retail
Figure 1-16: Retail and financial services were the most popular targets of SQLi and LFI
attacks in Q2 2015
Normalized SQLi and LFI Attacks by Industry, Q2 2015
34

35
xss was the third most common attack vector, with more than 10.78 million attacks,
primarily targeting the retail and financial services sectors.
rfi was the fourth most commonly employed attack vector in q2 2015
(2.83 million attacks), with financial services and hotel and travel as the industries
most targeted in q2 2015.
Close behind rfi, mfu attacks were the fifth most commonly used attack vector
(2.45 million attacks). mfu attempts overwhelmingly targeted the hotel and
travel industry.
The PHPi attack vector was sixth (1.93 million attacks), with the most common
targets in retail and the public sector.
In q2 2015, CMDi attacks (1.07 million) most frequently targeted the financial
services, retail and hotel and travel industries, while JAVAi attacks (39,100) were
mostly directed at the financial services sector.
1.2F
/ Future Web Application Attacks Analysis / As csi and the capabilities of our
Threat Research team grow, we look forward to continuing to report on data such
as that included here, as well as new trends as they develop. Please engage us and let
us know which types of data you’d like to see in the next report. As long as we can
guarantee the anonymity of our customers, we’ll continue to share as much as we
can in the most useful way possible.
1.3 / Data Sources / The Akamai platform consists of more than 200,000 servers
in more than 100 countries around the globe and regularly transmits between
15 – 30% of all Internet traffic. In February 2014, Akamai added the Prolexic network
to its portfolio, a resource specifically designed to fight DDoS attacks. This report
draws its data from the two platforms in order to provide information about current
attacks and traffic patterns around the globe.
[SECTION]1

36
The Akamai platform provides protection by being massively distributed, protected
by the use of the Kona waf and the ability to absorb attack traffic closest to where
it originates. In contrast, the Prolexic DDoS solution protects by routing traffic to
scrubbing centers where experienced incident responders use a variety of tools
to remove malicious traffic before passing it to the origin servers. The two types
of technology are complementary and provide two lenses through which we can
examine traffic on the Internet.
[SECTION]1

[SECTION]2
MULTI-VECTOR
DDoS ATTACKS
A
bout half of all DDoS attack campaigns mitigated by Akamai use two or
more attack vectors. One specific combination of vectors has appeared
repeatedly in attacks greater than 100 Gbps: the use of synand udpvectors
with extra data padding. An extremely large attack of syn and udp vectors was used
again in Q2 2015 — this time with the addition of an ack flood.
37

38
The q2 attack described here reached a peak bandwidth of 245 Gbps and a peak
packet per second rate of 46 Mpps. The padding of the udp data appeared to be
the same as in earlier attacks. The syn flood appeared to contain data referring to a
particular torrent file.
Large attacks of this sort take on a unique characteristic that sets them apart.
Typically, attacks from the DDoS-for-hire market depend on reflection-based
techniques. However, this attack appears to be a bot-based attack similar to Spike
and IptabLes/IptabLex, which have produced similar padded payloads.
2.1 / Attack Signatures / During the DDoS attack campaign, the following
observations were made about the signatures shown in Figure 2-1:
• Each attack vector targets destination port 80, while source ports are random
• udp payloads are all at least 1,000 bytes in length
• The majority of the syn flood traffic contained 896-byte payloads, as shown
in the syn payload size chart in Figure 2-2. The syn flood was combined with
other tcp flags.
• The ack flood was composed of 0-byte payloads and had a fixed ack number
• Both syn and ack set a window size of 65535
tcp port 80 is the default http port for web servers, but malicious actors don’t
exclusively target port 80 over tcp. When attacking a web site, the actor will typically
set each vector to target port 80. The udp traffic may not even reach the target ip.
Nonetheless, the 1,000+ byte udp packets do pack a punch. The overhead reduction
enabled by udp, as compared to tcp, allows for faster throughput from the attack
source. The burden placed on the target infrastructure is still a factor.
[SECTION]2
= DDoS ATTACK SPOTLIGHT

39
Figure 2-1: DDoS attack signatures used during this attack campaign. The SYN flood
contains a torrent reference
UDP Flood
13:27:07.819278 IP 192.118.76.164.40573 Y.Y.Y.Y.80: UDP, length 1000
....E.....@.7.V..vL.z
b..}.P..]AEz....@....+.vL.z
b.....|.................................................................................
........................................................................................
............................................................................snip....
ACK Flood
14:07:31.645185 IP 105.63.70.211.56103 Y.Y.Y.Y.80: Flags [.], ack 16777216, win 65535,
length 0
14:08:25.968210 IP 214.14.45.252.38788 Y.Y.Y.Y.80: Flags [.], ack 16777216, win 65535,
length 0
SYN Flood
13:35:29.463579 IP 84.236.124.125.58234 Y.Y.Y.Y.80: Flags [S], seq
3816467470:3816468366, win 65535, length 896
....E....z..{..sT.|}..5..z.P.z......P.....................5.k.........
0.p.
l.........
1.To
m...”.....
2.00
.2.iso.75 Tourer - MG ZR ZT ZTT ZS MG TF - All Manuals.iso..............................
.........snip......
13:27:36.920623 IP 211.142.30.46.38176 Y.Y.Y.Y.80: Flags [SW], seq
2501915743:2501916639, win 65535, length 896
13:27:36.920626 IP 112.5.230.168.43734 Y.Y.Y.Y.80: Flags [SEW], seq
2866162251:2866163147, win 65535, length 896
13:27:36.920798 IP 211.142.30.46.41162 Y.Y.Y.Y.80: Flags [SE], seq
2697634830:2697635726, win 65535, length 896
The syn flood also contains large data payloads — mostly 896 bytes per packet.
The method used for padding data appeared to have picked up some artifacts from
the attack source, possibly loaded from memory. The expanded syn payload shown
in Figure 2-1 contains references to a file likely obtained via torrent. Although the
actual data within the payloads didn’t affect the attack behavior, it added unique
attributes that can aid mitigation and investigation.
[SECTION]2

40
2.2 / ACK and SYN Behavior in a Distributed Attack / ack floods are
intended to tie up server resources. Since the ack flood requests do not correspond
to active tcp sessions, the server responds with a reset to the source of the request.
This type of request is less likely to make it past a firewall that keeps track of session
state. syn flood requests can make it through stateful firewalls, because syn requests
are used to form tcp sessions. Servers will respond with a syn-ack, which can also
tie up server resources.
That being said, these requests are part of a distributed denial of service attack,
which is the key when talking about syn floods and other attacks in the context
of DDoS. It simply doesn’t matter what is or isn’t supposed to happen with these
requests when they are sent at a rate of 46 million per second.
74.8%20.9%
896
bytes
6
bytes
0
bytes
20
bytes
970
bytes
2.8%
0.8%
0.7%
Top SYN Payload Size
Figure 2-2: Most SYN payloads contained exactly 896 bytes, not including IP or
TCP headers
[SECTION]2

41
In addition to the high packet rate, the extra payload data on syn requests observed
during the attack doesn’t change the way they are treated by end devices. The
payloads are added to create higher bandwidth and attacks this large will exceed
the throughput limits of network devices. Even if the requests don’t make it to the
end server, the bandwidth at the target network may not be adequate to withstand
an attack this large while continuing to serve typical traffic. Usually, support from a
dedicatedDDoSmitigationproviderisrequiredtoblocktheDDoSattackinthecloud.
2.3 / Source Countries / Attack traffic was sourced mostly by the United States
and also came from China, Japan, South Korea and the uk as show in Figure 2-3.
2.4 / Not DDoS-for-Hire / Attacks sourced from the DDoS-for-hire market
are popular, as demonstrated by the high percentage of reflection-based attacks
observed each quarter. This attack does not appear to have been sourced from the
DDoS-for-hiremarket.Instead,itappearstooriginatefromamoretraditionalmethod:
[SECTION]2
64.2%
16.3%
7.5%
6.4%
5.6%
US China Japan Republic
of Korea
UK
Top Source Countries for 950-Byte SYN Payload
Figure 2-3: Top five source countries for the SYN payload

42
bot-based attacks. Tools such as Spike and IptabLes/IptabLex have produced similar
padded payloads. However, differences in the signatures may indicate a different
threat or modifications to one of those tools.
2.5 / Summary / Multi-vector syn and udp attacks continue to produce some of
the largest bandwidth DDoS attacks. Regardless of how syn and ack are handled
by a server or a firewall, these distributed attacks are likely to overwhelm the
target network.
udp attacks in particular, require less overhead to launch and can produce high
bandwidth or high packet rates; one udp attack this quarter peaked at more than
200 Mpps. Yet the udp payloads in this attack contained 1-byte payloads.
Bot-based attacks pose difficulties for attackers, as it is difficult to maintain an army
of infected hosts. Administrators will eventually notice their server is consuming
an inordinate amount of outbound bandwidth. Once discovered, the administrator
can rebuild the server or eliminate the threat. The infection methods used by DDoS
malware also allow administrators to take proactive measures to ensure their servers
aren’t affected. Once the word gets out about a malware threat spreading — and how
it spreads, new mitigation tactics can be applied. After that, there won’t be much
room left for the malware to spread and infect new hosts.
DDoS-for-hire tools are often more difficult to combat since many are based on
methods of reflection. ssdp and dns reflection attacks will likely be around for some
time, while new vectors like RIPv1 lend flexibility to the attacker’s arsenal.
[SECTION]2

[SECTION]3
CASE STUDY:
WORDPRESS
AND THE
DANGER OF
THIRD-PARTY
PLUGINS
W
ordPress is the world’s most popular website and blogging platform.
Its ever-growing popularity makes it an attractive target for attackers
whoaimtoexploithundredsofknownvulnerabilitiestobuildbotnets,
spread malware and launch DDoS campaigns.
WordPress itself isn’t poorly written or shortsighted. The general security practices
and features of the core are well-intentioned and well-implemented, and generally
benefit from a lot of scrutiny by the core WordPress team, as well as hundreds of
open source software contributors.
43

44
However, many of its security issues come from third-party plugins and themes.
These third-party components are written by developers with various skill levels and
experience. They offer features as simple as customizing text input boxes to complex
shopping cart and payment processing frameworks. These plugins can be downloaded
from third-party directories, developers’ websites, and from WordPress.org
official listings. These plugins go through very little, if any, code vetting.
Getting a plugin or theme listed on WordPress.org is a fairly strict process, as it
requires review and approval on initial submission and must adhere to WordPress’
long list of guidelines.
After this initial submission, review and approval, however, future changes go
through a less-stringent vetting process. This means your secure plugin of today
could be your attacker’s plugin of choice when the plugin is updated in six months.
Given this thriving ecosystem, we reviewed some of the most popular plugins and
themes on WordPress.org to determine the general security posture of third-party
plugins and what vulnerabilities we could discover.
3.1 / General Findings / We used WordPress.org’s listing and sorting features
and downloaded the most popular plugins and themes for a number of pages. This
led to a total of 600 plugins and 722 themes, with popularity ranging from a few
thousand to a few hundred thousand active installs, according to WordPress.org’s
download statistics.
We utilized a slightly modified version of the php static analysis tool rips, along
with manual code review and dynamic testing on a standard WordPress installation
to weed out and confirm exploitation potential. After testing 1,322 collective plugins
and themes, we identified 25 individual plugins and themes that had at least one
vulnerability — and in some cases, multiple vulnerabilities — totaling 49 potential
exploits. These are listed in Section 3.6 of this report.
[SECTION]3
= CASE STUDY

45
Themostcommonvulnerabilitieswerecross-sitescripting(xss),whichwasexpected.
Conversely, there were some surprising discoveries, such as few local file inclusion
(lfi) and path transversal (pt) exploits among the plugins and themes analyzed.
lfi and pt were at the top of our watch list due to their ability to leak very sensitive
information and the lack of standards when coping with them (whitelisting,
blacklisting, regular expressions, extension enforcement, etc.). However, most
developers appear to be aware of the potential for abuse and have taken steps
to successfully prevent lfi and pt exploits. There were a few dangerous lfi
vulnerabilities, including one that would require the end user to modify a constant
in the source code.
The most surprising discoveries were the number of email header injection
vulnerabilities found in the themes, along with two instances of a site-wide DoS
technique that could be leveraged against some open proxy scripts.
Many of the third party developers followed general guidelines and best practices
by including files to prevent directory listings, checking script access to prevent
direct execution, and using is_admin(), as well as other measures to ensure users
couldn’t (easily) abuse things they shouldn’t access.
In general, most developers used the tools provided by php and WordPress and
appeared to stick to best practices when it came to limiting direct access to scripts,
enforcing user privileges, preventing directory listings, and using prepared sql
statements. This is likely in part due to WordPress’ own review process. In our
lab environment, this was quite successful in preventing would-be attackers from
succeeding with our potentially vulnerable discoveries. However, there were cases
where developers used either the wrong tool or an improper implementation that
would allow attackers to successfully exploit a flaw that appeared at first glance
to be secure. Instances of this included a cross-site request forgery (csrf) and a
subsequent xss attack into an admin’s session due to improper usage.
[SECTION]3
= CASE STUDY

46
In the next section, we’ll review some of our discoveries, including cases of xss,
csrf, and a DoS technique capable of crippling the underlying php parser and
taking down an entire site with a single request.
3.2 / Cross-Site Scripting / Unsurprisingly, xss was the most common
vulnerability we observed. xss is a common oversight in web applications and
plugins. While most developers did a good job of utilizing the WordPress functions
(esc_html, esc_attr, esc_textarea, esc_js, etc.) to sanitize output, some
used them incorrectly or not at all. Some of the instances of xss were common,
usually failing to properly sanitize search text or contact form input.
Others relied on using http referrer headers. Abusing http referrer headers in
this manner only requires an attacker to redirect the user from a crafted url into
the injectable page. There were several instances that seem as though developers
didn’t consider the contents of http headers and thus $_SERVER would be subject
to adversarial control, as shown in Figure 3-1.
Figure 3-1: An example showing abuse of an HTTP referrer header via XSS, in the
lab environment
[SECTION]3
= CASE STUDY

47
Another case involved a marketing plugin. While the developers had taken steps
to prevent abuse by using wpnonce for csrf prevention, they had implemented the
verification process incorrectly. In the lab environment, this allowed us to modify
settings of the plugin from a third-party site. The developers did not sanitize output
of their settings page, which made a stored xss attack feasible. In our lab, we were
able to craft a page that would infect the settings page with a xss payload over csrf,
and then redirect the admin to the now-poisoned page and execute the code, as
shown in Figure 3-2. This allowed researchers to side-jack the administrator’s active
session and gain access to the admin section of the WordPress installation. What’s
more, because the payload and the rendering are sent in two different requests,
this attack works in modern browsers such as Chrome, which under normal
circumstances implement very effective anti-xss measures by default.
3.3 / Email Header Injection / Themes are little more than a skin and graphics
for a WordPress installation. Our initial assumption was that primarily we would
discover xss holes without many avenues for backend abuse. However, we identified
multiple themes that were vulnerable to email header injection. This was mostly
due to themes including a contact page equipped with a form and form handling
logic, with little or no input sanitization, as shown in Figure 3-3.
[SECTION]3
= CASE STUDY
Figure 3-2: An example of CSRF exploitation

48
3.4 / Open Proxy Scripts / Many lfi vulnerabilities were successfully mitigated
in the plugins due to processes implemented by the developers. These processes
would scrub or test the input before it made it into functions such as file_get_
contents() and readfile(). One concern was the failure to limit the scope of
these file inclusion calls.
The developers’ processes often ensured proper extensions were part of the request,
and path transversal attempts were either blocked outright or effectively killed
by input sanitization. However, most of them did not check or enforce protocols
or domains, leaving malicious actors the opportunity to use php wrappers or to
abuse the scripts as open-proxies. While open-proxies may not seem exceedingly
dangerous, we’ve seen the rise in popularity of tools such as davoset UFOnet
using open-proxy scripts for DDoS campaigns. Similarly, we have seen the Joomla
Attack tool on multiple DDoS-for-hire sites, following the discovery of an open-
proxy script in a popular Google Maps plugin for Joomla.
Figure 3-3: An example WordPress theme contact form vulnerable to email
header injection
?php get_header(); ?
?php
/*-----------------------------------------------------------
Form
-----------------------------------------------------------*/
$nameError = ’’;
emailError = ’’;
$commentEroor = ’’;
//If the form is submitted
if(isset($_POST[‘submitted’])) {
$name = trim($_POST[’contactName’]);
$email = trim($_POST[’email’]);
$phone = trim($_POST[’phone’]);
$comments = trim($_POST[’comments’]);
if(!isset($hasError)) {
$emailTo = esc_html(ot_get_option(’charitas_contact_form_email’));
if (!isset($emailTo) || ($emailTo == ’’) ){
$emailTo = esc_html(get_option(’admin_email’));
}
$subject = ’New message From’.$name;
$body = “My name is: $name nnMy Email is: $email nnMy phone number is: $phone nnMy comments: $comments”;
$headers = ’From: ’.$name.’ ’.$email.’’ . “rn” . ‘Reply-To: ’ . $email;
mail($emailTo, $subject, $body, $headers);
$emailSent = true;
}
}
//end form
[SECTION]3
= CASE STUDY

49
In our testing, we identified two instances of plugins shipping with proxying scripts
of this type. We discovered that calls to file_get_contents() and readfile()
in php respect http 300 codes and will attempt to follow redirects in search of the
requested content. With this discovery, researchers in the lab environment were
able to take a site down for multiple minutes with a single request by using a small
shell script that would issue one request every .5 seconds. The site was taken down
quickly, but more importantly, it remained down for more than an hour after we
had stopped actively sending the malicious requests.
This style of DoS doesn’t overwhelm the network or web server (in our case nginx)
with massive amounts of traffic. In fact, in our initial lab testing, the loads on the
server were so low we initially thought the attack wasn’t working. Rather, the attack
overwhelms the php parser by fetching a script we control, which causes it to fetch
itself, recursively, until exhaustion. This is possible because it follows http redirects
within the affected functions.
One of the open proxy scripts ships with the wp Mobile Edition (wpme) plugin,
which has more than 7,000 actives installations, according to WordPress.org
statistics. There is also an open proxy script that ships with the Gmedia Gallery
plugin, with more than 10,000 active installations, per WordPress.org. These two
plugins represent more than 17,000 potential targets, assuming WordPress.org’s
stats are accurate and up to date. Approximately 1,200 of these targets could be
identified with Google dorking.
The script we targeted is used within the wpme plugin for loading, compressing,
and caching css files. The script is technically part of a third party theme called
mTheme-Unus that appears to be a universal mobile theme. Upon our discovery
and subsequent research into it, we found it has had some issues in its past.
[SECTION]3
= CASE STUDY

50
The script we tested resides deep within the wp-content directory structure. In
the lab, we targeted the script directly and told it to fetch what appears to be a css
file from a server we control. The request must appear to fetch a css file due to
extension checking within the script as part of its own lfi prevention. This request
to our server was caught by a single line php file that redirected the request back to
the proxy script, telling it to fetch itself, fetching us. This acts like a fork bomb or
infinite loop, with each request into the proxy fetching a redirect into the proxy that
fetches a redirect into the proxy yet again, until the php parser kills the thread due
to memory or execution time limits, as shown in Figures 3-4 through 3-8.
Figure 3-4: In the lab, an attack shell script successfully redirected the CSS file request
to a server under researcher’s control
Figure 3-5: The CSS file then redirected the request back to the proxy script
Figure 3-6: The nginx error logs show the failed responses to the proxy script
[SECTION]3
= CASE STUDY

The access and error logs illustrate what is happening with more detail: php-fpm
has exhausted its allotted resources for child processes. Even with nginx and
php-fpm tuning measures in place — such as increasing max_children to more
than 9,000 and limiting max_requests to 500 — php-fpm stopped responding
after a few minutes of two requests per second, effectively taking the site offline, as
shown in Figure 3-9.
Figure 3-7: The PHP-FPM logs display multiple warning errors as the script continues its
requests back to the host and exhausts its resources
[29-May-2015 22:40:39]WARNING:[pool www]seems busy(you may need to increase pm.start_servers,
or pm.min/max_spare_servers),spawning 32 children, there are 0 idle, and 602 total children
Figure 3-8: The nginx access logs show the server’s repeated calls back to itself
Figure 3-9: The error message displayed when nginx failed to communicate with the
exhausted PHP-FPM
An error occurred.
Sorry, the page you are looking for is currently unavailable.
Please try again later.
If you are the system administrator of this resource then you should check the
error log for details.
Faithfully yours, nginx.
51
[SECTION]3
= CASE STUDY

52
3.5 / Command Injection / Among the WordPress plugins we tested, XCloner
stood out due to its underlying system level functionality and its history of security
issues. XCloner is a backup and restore component designed for php/MySQL
websites and can work as a native plugin for WordPress and Joomla.
This plugin has multiple known and published vulnerabilities; we discovered even
more. The combination of vulnerabilities we identified in our research could allow
an attacker to use a web shell to gain remote access to critical functions, using just
a little Google dorking. With more than 1 million downloads, this has potential to
be a severe vulnerability.
Thefirstvulnerabilityinvolvescommandinjection.Thecontentsof$excluded_cmd
(line 1129) are passed to the exec() function on line 1205 of cloner.functions.php,
as shown in Figure 3-10.
Using the backup comments feature, we can create a file with a list of executable
commands, under administrator/backups/.comments. This file could include
whatever the attacker wants, such as ;id/tmp/w00t;. The attacker can then change
the configuration to a manual backup and perform a backup to gain control of the
site, as shown in Figure 3-11.
Figure 3-10: Command injection vulnerabilities in the cloner.functions.php script
1129 $excluded_cmd = “”;
1130 if ($fp = @fopen($_REQUEST[‘excl_manual’], “r”)) {
1131 while (!feof($fp))
1132 $excluded_cmd .= fread($fp, 1024);
1133
1134 fclose($fp);
1135 }
Line 1205: If configured for manual mode the contents of $excluded_cmd are passed to
exec();
1205 exec($_CONFIG[tarpath] . “ $excluded_cmd “
. $_CONFIG[‘tarcompress’] .
“vf $backup_file update $file”);
[SECTION]3
= CASE STUDY

53
The $excluded_cmd can be used for xss, as shown in Figure 3-12.
Figure 3-13: XCloner vulnerabilities include the ability to edit language files (Italian in
this case) to inject a PHP script
An attacker could also modify the language files to inject arbitrary php scripts as
shown in Figure 3-13 and Figure 3-14.
[SECTION]3
= CASE STUDY
Figure 3-11: An example command injection using the backup comments feature
Figure 3-12: Example abuse of the $excluded_cmd for XSS in XCloner

54
The default template has an error with the LM_LOGIN_TEXT field, which the
researcher needs to clean to prevent a syntax error when trying to execute.
Figure 3-14: The LM_LOGIN_TEXT field had to be cleared, as shown on the right
Figure 3-15: The resulting lines 1-3 of the injected code in italian.php
1 ?php
2 define(“LM_FRONT_CHOOSE_PACKAGE”,”foo”);phpinfo();define(“foo”,”fo”);
3 define(“LM_FRONT_CHOOSE_PACKAGE_SUB”,”smallSi prega di selezionare la vers ione di
Wordpress che si desidera installare/small”);
Adding foo”);phpinfo();define(“foo to the Translation LM_FRONT_*
field and then browsing to language/italian.php executes the malicious
phpinfo(); script.
This command injection vulnerability, combined with cve-2014-8605, could easily
result in a compromised website. An adversary could download your WordPress
database via a predictable storage path in the web root. The database will contain the
WordPress password hashes for all accounts, including the administrator account.
Once this hash has been cracked, the attacker can then use the remote command
injection vulnerability to run shell commands and compromise the entire server.
3.6 / Cleanup / During this research, we encountered several good developers
who were quick to address the issues and push patches. The challenge is tracking
down what code belongs to what developer. On WordPress.org, finding contact
information for authors of plugins and themes can be a challenge. There should be
a standardized way to contact them from the WordPress.org site privately. While
there is a support forum, it’s public. Ideally, there would be a way to share private
posts directed just to the author.
[SECTION]3
= CASE STUDY

Figure 3-16 includes a list of the plugins we reviewed, the vulnerabilities found in
each, and the cve designations associated with them.
A number of authors were very proactive in getting these issues addressed and
updates pushed live. Others were not responsive.
Plugin/Theme Name Vulnerabilities Found CFE Associated
XCloner XSS, Cmd Inj
CVE-2015-4336
CVE-2015-4337
CVE-2015-4338
AdSense Click-Fraud Monitoring XSS CVE-2015-3998
Wow Moodboard Lite Open Redirect CVE-2015-4070
Gmedia Gallery XSS, LFI, Open Proxy, DoS
CVE-2015-4339
CVE-2015-4340
WP Mobile Edition XSS, LFI, Open Proxy, DoS, Email Inj.
CVE-2015-4560
CVE-2015-4561
CVE-2015-4562
Lightbox Bank XSS CVE-2015-4563
WP Fastest Cache XSS CVE-2015-4564
Leaflet Maps Marker XSS CVE-2015-4565
WordPress Landing Pages XSS CVE-2015-4566
AVH Extended Categories Widgets SQLi CVE-2015-4567
Huge-IT Gallery XSS CVE-2015-4568
Huge-IT Video Gallery XSS CVE-2015-4568
Easy Google Fonts XSS CVE-2015-4569
WordPress Calls to Action CSRF, XSS CVE-2015-4570
Constant Contact for WordPress XSS CVE-2015-4571
Zerif Lite Theme XSS CVE-2015-4572
Colorway Theme XSS, Email Inj.
CVE-2015-4573
CVE-2015-4574
Charitas Lite Theme Email Inj. CVE-2015-4575
Ariwoo Theme XSS, Email Inj.
CVE-2015-4576
CVE-2015-4577
Kage Green Theme XSS CVE-2015-4578
Intuition Theme XSS CVE-2015-4579
iMag Mag Theme XSS CVE-2015-4580
FastNews Lite Theme XSS pending
Business Directory Theme XSS CVE-2015-4581
Boot Store Theme XSS CVE-2015-4582
SE HTML Album Audio Player LFI CVE-2015-4414
Aviary Image Editor Add-on for Gravity Forms Pre Auth File Upload CVE-2015-4455
Easy2Map Easy2Map-Photos SQLi
CVE-2015-4614
CVE-2015-4615
CVE-2015-4616
CVE-2015-4617
Zip Attachments LFI CVE-2015-4694
WP-Instance-Rename LFI CVE-2015-4703
Figure 3-16: WordPress plugin and theme vulnerabilities reviewed for this report
[SECTION]3
= CASE STUDY

56
Overall, we were encouraged by the speed and general appreciation shown by the
developers we were able to successfully contact. In cloud security research, it can be a
frustrating experience exposing vulnerabilities to a software provider. With smaller
developers, however, many were very happy to be informed of vulnerabilities and
serious about fixing them. In some cases, they updated versions and pushed fixes
live within hours of the initial disclosure.
One concern was how frustrating it was when it came time to disclose our findings
to the respective authors. WordPress.org acts as a central hub for these plugins,
themes, users, and authors, but seems to lack a proper standard for contacting
them. There is no requirement to list contact information or even a website on
the plugin developer profiles. For themes, tracking this information down can be
even more frustrating, depending on what the author has included as their Theme
Homepage link. In most cases, contacting an author involved a series of clicks and/
or some detective work, usually resulting in landing on a contact form of a website
we hoped belonged to the right person. One of the affected plugins we identified
is still orphaned; the company named within the documentation continues to say,
“It’s not ours.”
WordPress.org does offer a public support forum for every plugin and theme hosted
there. This is nice for letting users and authors interact and address general issues,
but due to the sensitive nature of some security issues, this option is not ideal. In
some cases, where we weren’t able to find contact information, a simple request for
the author to contact us via email was made, and eventually some of those authors
did reach out to us in private.
Going forward, we hope to see WordPress.org standardize and vet contact
information for plugin and theme authors. At the very least, they should offer an
option to create a private thread within the respective support forums to allow only
the author and initial poster to read and respond.
[SECTION]3
= CASE STUDY

57
3.7 / Mitigation and Best Practices /In general, best practices should be
applied when deploying any third party software on your servers and sites. Each
new moving piece has the potential to become an attacker’s next weapon. Think of
your security as a chain; it’s only as strong as its weakest link.
Do some research into the plugins you consider before installing them, look at the
author’s history, and see if they have a history of CVEs or other security concerns
in their past. If you can comprehend code, run the software through a free static
analysis tool such as rips or a commercial solution to identify potentially vulnerable
pieces of code and functionality.
If you’re currently running any of the plugins or themes mentioned here, you should
update them when the authors have published patches, addressing the issues in the
plugin’s change logs. If they haven’t addressed the issues, you can manually patch
the code yourself to properly sanitize inputs and/or outputs in the WordPress plugin
editor interface, find an alternative plugin, or uninstall the affected plugin if it isn’t
necessary for operations.
Of all the vulnerabilities we discovered, the majority of them could be mitigated
using the default Kona Rule Set (krs 1.0) provided by Akamai’s web application
firewall (waf). Akamai’s Kona Site Defender protects against the owasp top 10 web
vulnerabilities and may be used to mitigate the newly disclosed vulnerabilities (see
Figure 3-16) using our ruleset.
Kona Site Defender, by default, provides generic attack detection for:
• xss, SQLi, lfi, rfi, CMDi and pt
• Custom rules can also be implemented for other platform/application
specific attacks
In some cases, default rules exist, but custom rules could be developed to mitigate
risk before a patch has become available from the vendor.
[SECTION]3
= CASE STUDY

58
To harden your WordPress installs, there are a handful of software and configuration
options that will help protect you against potential vulnerabilities in the wild
now and in the future. Some general tips would be to look into hardened php
implementations such as Suhosin and consider a system like phpids to help
identify potential weaknesses and attacks and prevent them from being successfully
exploited. There are configuration options at the server level for performance tuning
and security hardening, such as ModSecurity, that will aid in mitigating attacks
before they begin, making exploitation more difficult, if not impossible.
In our research, we came across multiple security-oriented WordPress plugins,
most of which appeared to be well-secured themselves from a programming and
vulnerability standpoint, as well as helpful in enabling best practice protections for
a wide array of potential vulnerabilities. Some of the plugins that stood out, not only
from a quality standpoint, but also by virtue of popularity and good reviews, were
Wordfence, iThemes Security, and All In One Security Firewall. These plugins
help identify weaknesses within your existing installation and offer information,
advice, modifications and features that should help prevent some of the most
common attacks leveraged against WordPress installations.
Criminalsareincreasinglytargetingwebapplicationvulnerabilitiesasameansfordata
exfiltration, malware distribution and Botnet development. Web application firewalls
and due diligence are quickly becoming a requirement for any individual or company
who relies on a website and wants to ensure security and reliability for their users.
[SECTION]3
= CASE STUDY

[SECTION]4
Tor: THE PROS
AND CONS
T
he Onion Router (Tor) concept was a Defense Advanced Research
Projects Agency (darpa) project that was originally created to enable us
Navy personnel to conduct Open Source Intelligence (osint) operations
without disclosing their source ip addresses, and potentially their location. A few
years afterwards, a group of computer scientists implemented it, and the us Naval
Research Laboratory released it as open source software.
59

60
The Tor project uses a concept called onion routing, which ensures the entry node
to the network is not the same as the exit node. This process creates anonymity for
the client when interacting with the destination system. By hopping among internal
nodes, it could theoretically be impossible to detect the origin of the request.
However, a number of cyberattacks have attempted to unmask Tor users, using
network analysis, metasploit and relay early cells.
Due to the promise of anonymity, Tor became popular among diverse
groups including:
• People under censorship who seek access to information
• People who care about their privacy and do not want to be tracked
• Malicious actors who want to hide their location from law enforcement
The benefit of anonymity for Tor users is obvious; however, its value is not the
same for website owners. There are many industries, such as financial services,
that employ user-profiling techniques to help prevent fraud. The Tor network
complicates this process. On the other hand, many ecommerce sites don’t place
importance on where users originate as long as they provide valid credit card data
when purchasing their products.
The question becomes, should you allow connections from Tor to your website? As
outlined above, it is highly dependent upon your business model and risk tolerance.
In the next section, we provide analysis that shows the overall risk of malicious
traffic emanating from Tor vs. non-Tor traffic.
4.1 / Tor, the Foes / Attackers use Tor to perform anonymous attacks by hopping
from node to node, thus making forensic analysis and origin traceback a nightmare
for law enforcement. There are many guides on the Internet on how to configure Tor
as a local socks proxy for any application that provides socks proxy support.
[SECTION]4
= Tor THE PROS AND CONS

61
Moreover, many attack tools
include easy-to-configure
Tor capabilities. A notable
example is the common sql
Injection tool, sqlmap, which
includes a command line
argument to enable Tor.
There is even a check-tor
command line switch that verifies Tor is configured properly before staging an attack.2
4.2 / Risk Analysis / In order to assess the risks involved with allowing Tor
traffic to websites, we observed web traffic across the Kona security customer base
during a seven-day period. During that time, we collected relevant traffic data from
thousands of web applications for approximately 3,000 Akamai customers.
Denial of Service (DoS) and Rate Control triggers were not considered for this
research. The nature of the Tor network severely limits available bandwidth. It is
not feasible to conduct volumetric DoS attacks via Tor. Instead, we concentrated on
high-profile web application layer attacks from the following categories:
Defendant LOVE and the other
Co-Conspirators further used the Tor
network, which was an anonymizing
proxy service, to hide their activities.
— Indictment for US vs. Lauri Love. Love was charged with
hacking into thousands of computer systems, including
those of the US Army and NASA, in an alleged attempt
to steal confidential data.1
[SECTION]4
Figure 4-1: The check_tor switch is enabled, causing the tool to add time to stage the
attack as it hops between nodes
,
,

62
Command Injection (CMDi) - Command injection attacks allow malicious actors
to execute arbitrary shell commands on the target system. For this report, CMDi
includes the following subcategories:
• php code injection (PHPi)
• Java code injection (JAVAi)
• Command injection through remote file inclusion (rfi)
Local File Inclusion/Path Traversal (lfi/pt) — Using lfi attacks, malicious actors
gain unauthorized read access to local files on the web server.
Web vulnerability scanning — Web vulnerability scanners search websites for
known application vulnerabilities. Vulnerability scanners are used by attackers to
perform reconnaissance prior to launching attacks.
sql Injection (SQLi) — SQLi attacks allow attackers to pass content to a backend
sql server without proper validation or sanitization.
Cross-Site Scripting (xss) — xss attacks inject attacker-supplied content or script
into the end user’s http response, which is then rendered on the visited website.
4.3 / Tor Traffic vs. Non-Tor Traffic / Because Tor provides a way to
overcome censorship, perform osint and to protect an individual’s privacy, traffic
coming out of Tor will not necessarily be malicious.
However, Tor also provides a layer of anonymity that malicious actors may exploit.
Many Akamai customers ask, “If my site accepts traffic from Tor exit nodes, what are
the risks involved?” Or, “What are the odds that an http request coming out of a Tor
exit node will be malicious?”
To answer these questions, we started by comparing the total non-attack http
requests coming out of Tor exit nodes vs. non-Tor IPs, as shown in Figure 4-2.
[SECTION]4

63
It should be noted that the requests counted in this research represent only client
requests that eventually reached the target site and do not include requests to static
media files such as JavaScript, css, images, movies and sounds clips.
Global Rank Legitimate HTTP Requests Frequency
Non-Tor IPs 534,999,725,930 99.96%
Tor exit nodes 228,436,820 00.04%
Figure 4-2: Of the legitimate HTTP requests, excluding static media files, less than 1% were
from Tor exit notes
Source Legitimate HTTP Requests Frequency
Non-Tor IPs 46,530,841 98.74%
Tor exit nodes 596,042 1.26%
Figure 4-3: Of the malicious HTTP requests, 1.26% were from Tor exit notes
Source Ratio Between Malicious Legitimate Traffic Frequency
Non-Tor IPs 0.00008697% malicious traffic ~1:11,500
Tor exit nodes 0.00260922% malicious traffic ~1:380
Figure 4-4: Though the traffic levels are much smaller, Tor exit nodes were much more likely
to contain malicious requests
[SECTION]4
We then counted (and verified) the attack http requests, based on the categories
mentioned earlier, as shown in Figure 4-3.
We then set to compare the ratios of malicious and legitimate traffic for each.
Using the information collected in our sample period for the attack categories
studied, we concluded that approximately 1 in 380 http requests coming out of Tor
is verified to be malicious, while only 1 in 11,500 http requests coming out of a non-
Tor ip were verified to be malicious. In essence, an http request from a Tor ip is 30
times more likely to be a malicious attack than one that comes from a non-Tor ip.

64
4.4 / Tor Attacks by Category / It is no surprise that we have a similar
distribution of attack types between Tor exits nodes and non-Tor IPs for our
analyzed categories, as shown in Figure 4-5.
40
35
30
25
20
15
10
5
0
PTScanners
Vulnerability
Scanners
SQLi
XSS
CMDi
Tor Exit Nodes Non-Tor IPs
Figure 4-5: As with Tor exit nodes, PT and SQLi attacks were the most common attack
vectors from non-Tor IPs
Tor Web Application Attacks by Category
[SECTION]4

65
4.5 / Tor Attack Distribution by Target Industry / The most common
target for Tor attacks was the retail industry, followed by financial services and
high technology.
[SECTION]4
Industry Number of Attacks Frequency
Retail 212,189 35.60%
Financial Services 156,760 26.30%
High Technology 123,442 20.71%
Media Entertainment 49,834 8.36%
Public Sector 34,800 5.84%
Hotel Travel 5,919 0.99%
Business Services 5,241 0.88%
Automotive 3,942 0.66%
Consumer Goods 2,767 0.46%
Gaming 813 0.14%
Miscellaneous 335 0.06%
Figure 4-6: During the study period, Tor-based attacks targeted the retail industry
most frequently
4.6 / Tor Attack Distribution by Target Country / Figure 4-7 identifies the
targetcountryoftheTorattacksduringthestudyperiod,basedonAkamaibillingdata.
An interesting fact about the difference in attacks on us-based sites and the rest of
the world is that us-site attacks were distributed across many Akamai customers,
while the attacks against the rest of the world were distributed among only a handful
of Akamai customers in each geographic area.
For example, the Tor attacks on Swiss-based sites targeted a single digital property.
Similarly, the Tor attacks in the uk targeted just two customers.
4.7 / Potential Impact on Business / Another useful metric to understand the
risks of allowing or disallowing Tor traffic is the index of conversion. We measured
all the requests on a given day, both from Tor and non-Tor exit nodes.

66
We then measured the number of requests to key commerce-related application
pages such as checkout and payment pages (limited to post requests) on the given
day from Tor exit nodes, vs. the same pages from non-Tor IPs.
Country Number of Attacks Frequency
US 239,953 40.26%
Switzerland 210,601 35.33%
UK 125,167 21.00%
Canada 7,676 1.29%
Israel 5,485 0.92%
Austria 2,686 0.45%
Spain 888 0.15%
Germany 831 0.14%
Netherlands 702 0.12%
France 515 0.09%
Brazil 478 0.08%
Japan 243 0.04%
Greece 239 0.04%
Australia 231 0.04%
China 211 0.04%
Korea 79 0.01%
India 25 0.004%
Taiwan 19 0.003%
Bermuda 12 0.002%
Sweden 1 0.0002%
Figure 4-7: Targets in the US, Switzerland and UK accounted for more than 96% of Tor
attacks during the study period
[SECTION]4
Source Legitimate HTTP Requests
Non-Tor IPs 79,255,900,946
Tor exit nodes 35,560,027
Figure 4-8: Legitimate HTTP requests for one day of the study period
As can be seen from the conversion rates in Figure 4-9, while the Tor network
presentsveryhighrisktowebsitesfromasecurityperspective,italsoyieldspotential
business benefits to some industries.

67
Retailandfinancialservicestypicallyemploypowerfulfraudanalysisandprevention
methods. Web applications in these industries will most likely profile individual
users and the web transactions they generate, whether or not traffic arrived from
Tor. In most cases, it is just another indicator for the overall risk calculation, and at
the end of the day, Tor traffic is allowed through.
4.8 / Summary / As can be expected from any anonymizing tool, the Tor network
can be considered a double-edged sword. While it provides a blanket of anonymity
and helps Internet users anonymize themselves from prying eyes, it also provides a
safe haven for malicious actors who want to exploit anonymity in order to perform
illegitimate actions against web applications.
Many research papers and news articles have proven that the Tor network brings
a wide range of risks, but at the same time, most of them completely avoid the
fact that there is also business potential to allowing Tor users to browse revenue-
generating websites.
For some sites, the risks that come with allowing Tor traffic are much higher than
the benefit, a risk many organizations fail to consider. Regardless, it is highly
recommended that traffic coming out of Tor either be heavily scrutinized by security
protections (such as those provided by Akamai Kona Site Defender) or completely
blocked if the risk outweighs the benefits to the business. Akamai provides a
constantly-updated Tor exit node shared network list, which Kona customers can
use to alert or block as part of their site’s protection.
Source
Legitimate HTTP Requests to
Commerce-Related Application Pages
Conversion Rate
Non-Tor IPs 95,017,641 (1:834)
Tor exit nodes 39,703 (1:895)
Figure 4-9: Requests from Tor exit nodes remain valuable, as the conversion rates show
[SECTION]4

[SECTION]5
CLOUD SECURITY
RESOURCES
A
kamai released five threat advisories in q2 2015, as summarized here.
5.1 / OurMine Team Attack Exceeds 117 Gbps / Akamai’s PLXsert
and csirt are tracking the activities of a malicious hacking team that
calls itself the OurMine Team. The group claims to be responsible for DDoS attacks
against a number of financial institutions, and claims to have access to a financial
organization’s accounts worth US $500,000 that they intend to give to the poor.
68

69
This is a relatively new group, which started its Twitter account March 31, 2015.
Before it started targeting the financial sector, the group generally discussed and
conducted DDoS attacks against gaming services.
Akamai validated several DDoS attacks across the financial sector, though no
outages have been reported from the major institutions across our customer base.
The largest attack peaked at 117 Gbps.
While this group is self-aggrandizing and entices Twitter followers with offers of
free online gaming accounts or gaming coins (such as fifa Ultimate Team and
Minecraft) for reaching milestones in its follower base, this does not diminish its
credibility. OurMine typically does not announce target lists in advance, but instead
announces when an attack is underway or has been completed.
OurMinemayhavecolleagueswithinthehackingcommunity,basedonvariousposts
identified via Twitter and other osint resources. However, it appears that the group’s
core competency was gleaned within the gaming community. Though the group
has demonstrated some skill, it appears to be relatively inexperienced in hacking.
The public requests for assistance in the targeting of video games, coupled with
their schemes to gain Twitter followers, would suggest that this actor set is
unskilled. However, their success with a number of sizeable DDoS attacks seemingly
contradicts that notion.
5.2 / RIPv1 Reflection DDoS Makes a Comeback / Late in the quarter, Akamai
observed an uptick in a DDoS reflection vector that was thought to be mostly
abandoned. This attack vector involves the use of an outdated Routing Information
Protocol (rip), RIPv1. This first surfaced in active campaigns on May 16, after being
dormant for more than a year. The attacks made use of only a small number of
available RIPv1 source devices.
[SECTION]5

70
RIPv1 was first introduced in 1988 under RFC1058, which is now listed as a historic
documentinRFC1923.Thehistoricdesignationmeanstheoriginalrfcisdeprecated.
One reason for this is that RIPv1 only supports classful networks. If the network
advertised by RIPv1 happens to be a class A network, such as 10.1.2.0/24, this will
be sent in an advertisement as 10.0.0.0/8. The small number or available addresses
(128) limits the usefulness for RIPv1 as a viable option for business networks,
much less the Internet. However, RIPv1 is considered to be a quick and easy way to
dynamically share route information in a smaller, multi-router network.
A typical router communication would appear as shown in the table below. Here,
a request is sent by a router running rip when it is first configured or powered on.
Any other device listening for the requests will respond to this request with a list of
routes. Updates are also sent periodically as broadcasts.
To leverage the behavior of RIPv1 for DDoS reflection, a malicious actor crafts the
same request query type as shown in Figure 5-1, which is normally broadcast, and
spoofs the ip address source to match the intended attack target. The destination
would match an ip from a list of known RIPv1 routers on the Internet. Based on
recent attacks, attackers prefer routers that seem to have a suspiciously large amount
of routes in their RIPv1 routing table.
This query results in multiple 504-byte payloads sent to a target ip per a single
request. The multiple responses are also a result of the 25-route max that can be
contained in a rip packet.
Figure 5-1: Normal router communications for RIPv1
Router initial request for routes (sent as broadcast):
15:53:50.015995 IP 192.168.5.2.520 255.255.255.255.520: RIPv1, Request, length: 24
Listening router response for routes (sent as a unicast reply to request IP):
15:53:50.036024 IP 192.168.5.1.520 192.168.5.2.520: RIPv1, Response, length: 24
Regular periodic update sent every 30 seconds by default (broadcast):
15:54:26.448383 IP 192.168.5.1.520 255.255.255.255.520: RIPv1, Response, length: 24
[SECTION]5

71
There are several ways to avoid becoming a victim of this attack method:
• If RIPv1 is required, assess the need to expose rip on your wan interface. If
it’s not needed, the wan interface should be marked as a passive interface
(where supported).
• Switch to RIPv2 or later and enable authentication.
• Restrict access to rip via acl, to only allow known neighbor routers.
• For targets of a RIPv1 reflected DDoS attack, use acl to restrict udp source
port 520 from the Internet.
• If the attack is too large, seek assistance from a DDoS mitigation provider such
as Akamai Technologies.
5.2A
/ Third-Party Plugins Ripe for Attack / In Section 3 of this report, we described
how WordPress users can be vulnerable to attacks via the third-party plugins they
use. But the threat goes beyond WordPress users.
Most high-profile websites have a strong security profile. But many of them also
use third-party content providers whose security may be less than ideal. Instead of
targetinghigh-trafficwebsitesdirectly,attackersaretargetingthird-partyadvertising
companies, as well as content networks used by these sites. Such exploits require
little technical skill and are highly effective.
Akamai csirt Manager Mike Kun described the problem in this podcast recently.
“Bad actors are looking at what services the website is using,” Kun said. “A simple
one is dns. If the attacker can compromise the registrar a site is hosted with, they
can easily change the ip address mapping and point that at some other site.”
[SECTION]5

72
The method of attack against the third party may be through domain hijacking,
phishing, application-layer attacks or any of the various methods to compromise
a provider. Once that provider is compromised, there isn’t anything more the
attacker needs to do in order for their target to be attacked. The third-party provider
unwittingly does it for them.
Attackers will also look at what content is being dynamically included in a site, and
try to compromise one of those providers. If the target site blindly trusts the content
being sent from a provider, the attacker knows the site can be compromised with
malicious content sent by the provider.
The attack code will frequently be a form of malware viewers unwittingly load onto
the site. If the targeted site gets millions of views per day, a significant botnet can be
created in a short amount of time.
Those who manage a major website put a lot of effort into fortifying the front
entrance. But using third-party content without proper security is like leaving open
windows in the back of the building.
The best defense in this situation is proper planning.
What happens to the site when a plugin will not load? Will the rest of the page load
around it correctly? Or does the whole site wait for the plugin code to be delivered,
effectively creating a DoS condition for the site?
Consider what to do if the plugin is compromised. What is the plan to eliminate the
plugin but keep the site running? One possibility is to have a static version of the
site ready to go, so no dynamic code is pulled in that could continue to compromise
the site or customers or both.
Obviously,thebestscenarioisoneinwhichthesethingsdon’thappeninthefirstplace.
[SECTION]5

73
To that end, we recommend site owners research the plugins they want to use before
deploying them. Ask third-party providers what they use for security measures.
If their response is less than ideal, find another provider that will address the
concerns more clearly.
5.2B
/ The Logjam Vulnerability / In May, Akamai responded to concerns over the
Logjamvulnerabilityasdiscussedinthisdisclosure.Akamaianalyzeditsproduction
servers to determine if it supported the relevant Diffie-Hellman ciphers that would
leave customers vulnerable to Logjam.
Akamai determined that hosts on its Free Flow and Secure Content Delivery
Networks were not vulnerable. Akamai did recommend people read this OpenSSL
postonchangesrelatedtoLogjamandfreak.Akamaialsorecommendedcustomers
check their origin and advised anyone using a web browser, running a server or
developing relevant software read the What should I do? section of this advisory.
5.2C
/ DD4BC Escalates Attacks / q2 2015 was dominated by attacks launched by
the group DD4BC.
DD4BC, a malicious group responsible for several Bitcoin extortion campaigns in
2014, expanded its extortion and DDoS campaigns during April and May. Akamai
had to protect a growing number of customers from these attacks.
Over the course of one week, several customers received ransom emails in which
DD4BC warned they’d launch a DDoS attack of 400-500 Gbps against them. To date,
however,DD4BCattacksmitigatedbyAkamaihaven’tmeasuredmorethan50Gbps.
[SECTION]5

74
Based on these attacks and the correlating ip addresses, Akamai researchers
identified more than 1,400 IPs that were likely coming from booter-stresser sites.
The growing number of industries under threat include:
• Payment processing
• Banking credit unions
• Gaming
• Oil gas
• E-commerce
• High tech consulting/services
Customers should:
• Review your playbook with it and security staff to ensure you are prepared
and know what to do in the event of an attack.
• Ensure all contact numbers and email addresses for key staff have been updated
and are correct.
• Ensure all critical staff are available. If staff members are on vacation or absent
due to sickness, make sure their responsibilities are covered by others.
• Stay in close contact with the Akamai soc and check the Akamai Community
Security page for updates.
Companies were also advised to:
• Make security incident preparation a corporate-wide initiative.
• Keep it management in the loop about potentially controversial corporate
dealings or policies with social justice or political overtones.
[SECTION]5

75
• Stay informed about security vulnerabilities and DDoS attack trends.
• Validate mitigation services.
• Create and test security playbooks.
• Monitor social media.
• Monitor corporate-sponsored social media pages, blogs and message boards
for inflammatory postings by customers and employees.
• Alert it and security services providers when the company becomes a live
target and take defensive action.
• Pay attention to threatening emails and phone calls.
• Alert law enforcement.
[SECTION]5

[SECTION]6
LOOKING FORWARD
W
e expect to see a continued upward trend of long-duration DDoS
attacks. While this quarter saw one attack that measured more than
240 Gbps and lasted more than 13 hours, we expect to see future
attacks surpass those levels.
Malicious actors such as DD4BC and the OurMine Team continue to be persistent
and creative. While Akamai will continue to protect customers from their assaults,
they have had enough success elsewhere that they will continue to push forward.
Their numbers and array of attack tools will likely increase going forward, making
bigger attacks inevitable.
76

77
We also expect the syn and ssdp vectors to remain popular. The proliferation of
unsecured home-based, Internet-connected devices using the Universal Plug and
Play (UPnP) protocol will ensure that they remain attractive for use as ssdp reflectors.
Expect the heavy barrage of attacks in the gaming industry to continue, as players
keep looking for an edge over competitors, and security vulnerabilities in gaming
platforms continue to attract attackers looking for low-hanging fruit. Financial
services will also remain a top target given the myriad opportunities the bad guys
have to extract and monetize sensitive data.
us-based websites will likely remain the most targeted for web application attacks
given the sheer number of devices, users and vulnerabilities.
We will also continue to see malware in ads and third-party service attacks as
attackers continue to find security holes in the many widgets and plug-ins used
across myriad platforms.
Collaboration continues to be an imperative for the software and hardware
development industry, application and platform service providers, and the
security industry in order to break the cycle of mass exploitation, botnet building
and monetization.
[SECTION]6
= LOOKING FORWARD

78
1 http://www.justice.gov/sites/default/files/usao-nj/legacy/2013/11/29/Love,%20Lauri%20Indictment.pdf
2 https://github.com/sqlmapproject/sqlmap/wiki/Usage
[END NOTES]

About Prolexic Security Engineering Research Team
(PLXsert)
PLXsert monitors malicious cyber threats globally and analyzes these
attacks using proprietary techniques and equipment. Through research,
digital forensics and post-event analysis, PLXsert is able to build a global
view of security threats, vulnerabilities and trends, which is shared with
customers and the security community. By identifying the sources and
associated attributes of individual attacks, along with best practices to
identify and mitigate security threats and vulnerabilities, PLXsert helps
organizations make more informed, proactive decisions.
About Threat Research Team
The Threat Research Team is responsible for the security content and
protection logic of Akamai’s cloud security products. The team performs
cutting edge research to make sure that Akamai’s cloud security products
are best of breed, and can protect against the latest application layer threats.
About Customer Security Incident Response Team (csirt)
The Akamai Customer Security Incident Response Team (csirt)
researches attack techniques and tools used to target our customers and
develops the appropriate response — protecting customers from a wide
variety of attacks ranging from login abuse to scrapers to data breaches to
Dns hijacking to distributed denial of service. It’s ultimate mission: keep
customers safe. As part of that mission, Akamai Csirt maintains close
contact with peer organizations around the world, trains Akamai’s PS and
CCare to recognize and counter attacks from a wide range of adversaries,
and keeps customers informed by issuing advisories, publishing threat
intelligence and conducting briefings.
Contact
Twitter: @State_Internet
Email: stateoftheinternet-security@akamai.com
©2015 Akamai Technologies, Inc. All Rights Reserved. Reproduction in whole or in part in any form or medium without express written permission is prohibited. Akamai and the Akamai
wave logo are registered trademarks. Other trademarks contained herein are the property of their respective owners. Akamai believes that the information in this publication is accurate as of its
publication date; such information is subject to change without notice. Published 08/15.
Akamai is headquartered in Cambridge, Massachusetts in the United States with operations in more than 57 offices around the world. Our services and renowned customer care are
designed to enable businesses to provide an unparalleled Internet experience for their customers worldwide. Addresses, phone numbers and contact information for all locations are listed
on www.akamai.com/locations.
As the global leader in Content Delivery Network (cdn) services, Akamai makes the Internet fast, reliable and secure for its customers. The company’s advanced web performance, mobile
performance, cloud security and media delivery solutions are revolutionizing how businesses optimize consumer, enterprise and entertainment experiences for any device, anywhere. To learn
how Akamai solutions and its team of Internet experts are helping businesses move faster forward, please visit www.akamai.com or blogs.akamai.com, and follow @Akamai on Twitter.

2015-cloud-security-report-q2

More Related Content

What's hot (17)

Viewers also liked (11)

Similar to 2015-cloud-security-report-q2 (20)

More from Gaurav Ahluwalia (11)

2015-cloud-security-report-q2