# data[].attributes.body
Hacking of pacemakers via their Internet-connectivity, like you may have seen in popular TV shows, has not yet been proven possible. However, there has been no independent research looking closely into this published, so as a patient I am expected to trust the vendors when they claim to have strengthened the security of their devices so that they are no longer vulnerable against the published security concerns. That’s not enough for me.

https://www.wired.com/2016/03/go-ahead-hackers-break-heart/

# data[].attributes.body
It has a near-field interface to facilitate adjusting the configuration settings and another wireless interface for remote monitoring purposes. This means that the pacemaker can connect to a server at the vendor via an access point to transmit my device logs and patient information. I realized that my heart was now wired into the medical Internet of Things, and this was done without informing me or asking for my consent. I was alarmed. I recognized right away that this remote monitoring capability is very beneficial to a lot of patients who require frequent check-ups, but with connectivity comes vulnerability. As a security researcher I see this as an increased attack surface.

https://www.wired.com/2016/03/go-ahead-hackers-break-heart/

# data[].attributes.attachment_link.readable_text
My life depends on the functioning of a medical device: a pacemaker that generates each and every beat of my heart. I know how it feels to have my body controlled by a machine that is not working correctly, and this is why I encourage fellow security researchers to delve into these medical devices and find ways to make them more secure.

WIRED Opinion

About

Marie Moe is a security researcher with SINTEF.

Four years ago, I woke up lying on the floor, but I had no idea how I'd gotten there or for how long I'd been out. Stunned, I went to the emergency room at the local hospital. It turned out I had fallen because my heart had taken a break-long enough to cause unconsciousness. Luckily, it started beating again by itself, but the resulting pulse was very low and irregular. To keep my pulse up and stop my heart from taking pauses I needed to get a medical device implanted in my chest that would monitor each heartbeat and send a small electrical signal directly to my heart via an electrode to keep it beating.

The Medical Internet of Things

I am a security researcher, and at the time that I got this medical implant my day job was protecting the national critical infrastructure in Norway from cyber-attacks. When I got the pacemaker it was an emergency procedure. I needed the device to stay alive, so there really was no option to not get the implant. There was, however, time to ask questions. Unlike most patients-and to the surprise of my doctors-I began asking about the potential security vulnerabilities in the software running on the pacemaker and the possibilities of hacking this life-critical device. The answers were unsatisfying, and they were beside the point. I needed the pacemaker, and so I got it.

I realized that my heart was now wired into the medical Internet of Things, and this was done without informing me or asking for my consent.

After the surgery, I started to search for more information. I found and studied the technical manual for my pacemaker. I was quite surprised when I discovered that it has built-in functionality for wireless communication. It has a near-field interface to facilitate adjusting the configuration settings and another wireless interface for remote monitoring purposes. This means that the pacemaker can connect to a server at the vendor via an access point to transmit my device logs and patient information. I realized that my heart was now wired into the medical Internet of Things, and this was done without informing me or asking for my consent. I was alarmed. I recognized right away that this remote monitoring capability is very beneficial to a lot of patients who require frequent check-ups, but with connectivity comes vulnerability. As a security researcher I see this as an increased attack surface.

Debugging Me

After the pacemaker was implanted under my skin it needed to be configured. It has a sensor system that needs fine-tuning so that it will work seamlessly with my body to create a heart rhythm that is sufficient to put enough oxygen in my blood. When it's working correctly, the pacemaker should recognize when I go for a run, for instance, and make my heart rhythm faster.

Since I'm younger than most pacemaker patients, the default configuration settings were not suitable for me. It took a few months of trial-and-error tweaking before the doctors could get the tuning right, and this was complicated by a software bug in the programming device that they used to adjust the settings of the pacemaker. The bug caused the actual settings of my device to differ from the those displayed on the screen at the hospital that the pacemaker technician was seeing.

The consequence of this greatly affected my well being. If I tried to run after the bus or climb up stairs I would suddenly get out of breath. The pacemaker was detecting my pulse to be outside the upper heart rate limit, which was erroneously configured to 160 beats per minute. When I reached this heart rate, the pacemaker would suddenly cut my pulse in half to 80 beats per minute due to a safety mechanism. This was a very uncomfortable feeling. All of a sudden my body could not get enough oxygen. I compare it to that feeling you get running uphill as fast as you can until you reach the point of exhaustion, except it happened instantaneously, without any warning. Like hitting a wall.

No Access to the Code

Part of the problem with doing security research in this field is that the medical devices appear as black boxes. How can I trust the machine inside my body when it is running on proprietary code and there is no transparency?

How can I trust the machine inside my body when it is running on proprietary code and there is no transparency?

My fellow patient advocates Karen Sandler, Jay Radcliffe, and Hugo Campos have been fighting for their rights to get access to the proprietary software and the data that their devices are collecting, without getting this from the medical device vendors. A significant battle was, however, won when the DMCA exemptions for medical device security research were granted in October of last year. I really hope that this paves the way for more research.

Pacemakers Are Vulnerable

It is already established that pacemakers can be vulnerable to hacking. In 2008 a group of researchers, led by Dr. Kevin Fu of Archimedes Center for Medical Device Security at University of Michigan, published an article showing that it is possible to extract sensitive personal information from a pacemaker or even to threaten the patient's life by turning off or changing the pacing behavior. Fortunately, such an attack required close proximity to the patient, and could not be carried out remotely.

A more threatening attack scenario was developed by the hacker Barnaby Jack, who was planning to give a lecture at the Blackhat conference in 2013 about the possibility of remotely controlling pacemakers via wireless communications at 15 meters distance. Sadly, he died just days before the conference, and his research has not been pursued.

Hacking of pacemakers via their Internet-connectivity, like you may have seen in popular TV shows, has not yet been proven possible. However, there has been no independent research looking closely into this published, so as a patient I am expected to trust the vendors when they claim to have strengthened the security of their devices so that they are no longer vulnerable against the published security concerns. That's not enough for me.

As a security researcher, I want to figure out how things actually work myself, and this is why I started a hacking project together with my friend Éireann Leverett, to look at the security of the wireless interfaces of my pacemaker. Since I started to promote this research I have gotten several offers to help with my project, and two more security researchers, Gunnar Alendal and Tony Naggs, have also joined my team, working on my project in their spare time. I have also gotten funding from my employer SINTEF to carry out this research in my day job. I am not tinkering with my own implanted device in this project-of course. Instead, we have purchased devices to hack on eBay and have also been donated used pacemakers.

Hack to Save Lives

I encourage more security research of medical implants simply because I do not believe that proprietary "security through obscurity" will make the devices safer for patients.

The medical device industry got a wake-up call last year when researcher Billy Rios demonstrated that drug infusion pumps had vulnerabilities that would allow unauthorized firmware updates that could give patients lethal medication dosages. This led to the FDA (US Food and Drug Administration) issuing the first-ever recall of medical devices due to cyber security vulnerabilities. This was also a very rare example of a recall by the FDA without any patients being killed due to the vulnerability. Usually drugs and medical equipment are not withdrawn from the market without evidence of harm.

The decision to implant a medical device is also a risky one. In my case the benefit of having the device clearly outweighs the risk, since I would probably not be living without the pacemaker. No patients have, as far as I know, been killed due to a hacked pacemaker, but patients have been killed due to malfunction of their medical devices, configuration errors and software bugs. This means that security research in the form of pre-emptive hacking, followed by coordinated vulnerability disclosure and vendor fixes, can help save human lives.

# data[].attributes.attachment_link.description
My life depends on the functioning of a medical device: a pacemaker that generates each and every beat of my heart. I know how it feels to have my body controlled by a machine that is not working correctly, and this is why I encourage fellow security researchers to delve into these medical devices and find ways to make them more secure.

# data[].attributes.body
First blog post

# data[].attributes.attachment_link.readable_text
On Tuesday evening, KrebsOnSecurity.com was the target of an extremely large and unusual distributed denial-of-service (DDoS) attack designed to knock the site offline. The attack did not succeed thanks to the hard work of the engineers at Akamai, the company that protects my site from such digital sieges. But according to Akamai, it was nearly double the size of the largest attack they'd seen previously, and was among the biggest assaults the Internet has ever witnessed.

The attack began around 8 p.m. ET on Sept. 20, and initial reports put it at approximately 665 Gigabits of traffic per second. Additional analysis on the attack traffic suggests the assault was closer to 620 Gbps in size, but in any case this is many orders of magnitude more traffic than is typically needed to knock most sites offline.

Martin McKeay, Akamai's senior security advocate, said the largest attack the company had seen previously clocked in earlier this year at 363 Gbps. But he said there was a major difference between last night's DDoS and the previous record holder: The 363 Gpbs attack is thought to have been generated by a botnet of compromised systems using well-known techniques allowing them to "amplify" a relatively small attack into a much larger one.
In contrast, the huge assault this week on my site appears to have been launched almost exclusively by a very large botnet of hacked devices.
The largest DDoS attacks on record tend to be the result of a tried-and-true method known as a DNS reflection attack. In such assaults, the perpetrators are able to leverage unmanaged DNS servers on the Web to create huge traffic floods.

Ideally, DNS servers only provide services to machines within a trusted domain. But DNS reflection attacks rely on consumer and business routers and other devices equipped with DNS servers that are (mis)configured to accept queries from anywhere on the Web. Attackers can send spoofed DNS queries to these so-called "open recursive" DNS servers, forging the request so that it appears to come from the target's network. That way, when the DNS servers respond, they reply to the spoofed (target) address.

The bad guys also can amplify a reflective attack by crafting DNS queries so that the responses are much bigger than the requests. They do this by taking advantage of an extension to the DNS protocol that enables large DNS messages. For example, an attacker could compose a DNS request of less than 100 bytes, prompting a response that is 60-70 times as large. This "amplification" effect is especially pronounced if the perpetrators query dozens of DNS servers with these spoofed requests simultaneously.

But according to Akamai, none of the attack methods employed in Tuesday night's assault on KrebsOnSecurity relied on amplification or reflection. Rather, many were garbage Web attack methods that require a legitimate connection between the attacking host and the target, including SYN, GET and POST floods.

That is, with the exception of one attack method: Preliminary analysis of the attack traffic suggests that perhaps the biggest chunk of the attack came in the form of traffic designed to look like it was generic routing encapsulation (GRE) data packets, a communication protocol used to establish a direct, point-to-point connection between network nodes. GRE lets two peers share data they wouldn't be able to share over the public network itself.

"Seeing that much attack coming from GRE is really unusual," Akamai's McKeay said. "We've only started seeing that recently, but seeing it at this volume is very new."

McKeay explained that the source of GRE traffic can't be spoofed or faked the same way DDoS attackers can spoof DNS traffic. Nor can junk Web-based DDoS attacks like those mentioned above. That suggests the attackers behind this record assault launched it from quite a large collection of hacked systems - possibly hundreds of thousands of systems.

"Someone has a botnet with capabilities we haven't seen before," McKeay said. "We looked at the traffic coming from the attacking systems, and they weren't just from one region of the world or from a small subset of networks - they were everywhere."

There are some indications that this attack was launched with the help of a botnet that has enslaved a large number of hacked so-called "Internet of Things," (IoT) devices - routers, IP cameras and digital video recorders (DVRs) that are exposed to the Internet and protected with weak or hard-coded passwords.

As noted in a recent report from Flashpoint and Level 3 Threat Research Labs, the threat from IoT-based botnets is powered by malware that goes by many names, including "Lizkebab," "BASHLITE," "Torlus" and "gafgyt." According to that report, the source code for this malware was leaked in early 2015 and has been spun off into more than a dozen variants.

"Each botnet spreads to new hosts by scanning for vulnerable devices in order to install the malware," the report notes. "Two primary models for scanning exist. The first instructs bots to port scan for telnet servers and attempts to brute force the username and password to gain access to the device."

Their analysis continues:

"The other model, which is becoming increasingly common, uses external scanners to find and harvest new bots, in some cases scanning from the [botnet control] servers themselves. The latter model adds a wide variety of infection methods, including brute forcing login credentials on SSH servers and exploiting known security weaknesses in other services."

I'll address some of the challenges of minimizing the threat from large-scale DDoS attacks in a future post. But for now it seems likely that we can expect such monster attacks to soon become the new norm.

Many readers have been asking whether this attack was in retaliation for my recent series on the takedown of the DDoS-for-hire service vDOS, which coincided with the arrests of two young men named in my original report as founders of the service.

I can't say for sure, but it seems likely related: Some of the POST request attacks that came in last night as part of this 620 Gbps attack included the string "freeapplej4ck," a reference to the nickname used by one of the vDOS co-owners.

Update Sept. 22, 8:33 a.m. ET: Corrected the maximum previous DDoS seen by Akamai. It was 363, not 336 as stated earlier.

Tags: Akamai, applej4ck, BASHLITE, botnet, DDoS, DNS, dns amplification attack, dns reflection attack, Flashpoint, gafgyt, generic routing encapsulation, GRE, GRE DDoS, IoT botnets, Level 3 Threat Research Labs, Lizkebab, Martin McKeay, Prolexic, Torlus, vDos

# data[].attributes.attachment_link.description
On Tuesday evening, KrebsOnSecurity.com was the target of an extremely large and unusual distributed denial-of-service (DDoS) attack designed to knock the site offline. The attack did not succeed thanks to the hard work of the engineers at Akamai, the company that protects my site from such digital sieges.

# data[].attributes.body
Infected systems can be cleaned up by simply rebooting them — thus wiping the malicious code from memory. But experts say there is so much constant scanning going on for vulnerable systems that vulnerable IoT devices can be re-infected within minutes of a reboot. Only changing the default password protects them from rapidly being reinfected on reboot.

https://krebsonsecurity.com/2016/10/source-code-for-iot-botnet-mirai-released/

# data[].attributes.body
Second blog post

# data[].attributes.attachment_link.readable_text
The source code that powers the "Internet of Things" (IoT) botnet responsible for launching the historically large distributed denial-of-service (DDoS) attack against KrebsOnSecurity last month has been publicly released, virtually guaranteeing that the Internet will soon be flooded with attacks from many new botnets powered by insecure routers, IP cameras, digital video recorders and other easily hackable devices.

The leak of the source code was announced Friday on the English-language hacking community Hackforums. The malware, dubbed " Mirai," spreads to vulnerable devices by continuously scanning the Internet for IoT systems protected by factory default or hard-coded usernames and passwords.

Vulnerable devices are then seeded with malicious software that turns them into "bots," forcing them to report to a central control server that can be used as a staging ground for launching powerful DDoS attacks designed to knock Web sites offline.

The Hackforums user who released the code, using the nickname " Anna-senpai," told forum members the source code was being released in response to increased scrutiny from the security industry.

"When I first go in DDoS industry, I wasn't planning on staying in it long," Anna-senpai wrote. "I made my money, there's lots of eyes looking at IOT now, so it's time to GTFO [link added]. So today, I have an amazing release for you. With Mirai, I usually pull max 380k bots from telnet alone. However, after the Kreb [sic] DDoS, ISPs been slowly shutting down and cleaning up their act. Today, max pull is about 300k bots, and dropping."

Sources tell KrebsOnSecurity that Mirai is one of at least two malware families that are currently being used to quickly assemble very large IoT-based DDoS armies. The other dominant strain of IoT malware, dubbed " Bashlight," functions similarly to Mirai in that it also infects systems via default usernames and passwords on IoT devices.

According to research from security firm Level3 Communications, the Bashlight botnet currently is responsible for enslaving nearly a million IoT devices and is in direct competition with botnets based on Mirai.

"Both [are] going after the same IoT device exposure and, in a lot of cases, the same devices," said Dale Drew, Level3's chief security officer.

Infected systems can be cleaned up by simply rebooting them - thus wiping the malicious code from memory. But experts say there is so much constant scanning going on for vulnerable systems that vulnerable IoT devices can be re-infected within minutes of a reboot. Only changing the default password protects them from rapidly being reinfected on reboot.

In the days since the record 620 Gbps DDoS on KrebsOnSecurity.com, this author has been able to confirm that the attack was launched by a Mirai botnet. As I wrote last month, preliminary analysis of the attack traffic suggested that perhaps the biggest chunk of the attack came in the form of traffic designed to look like it was generic routing encapsulation (GRE) data packets, a communication protocol used to establish a direct, point-to-point connection between network nodes. GRE lets two peers share data they wouldn't be able to share over the public network itself.

One security expert who asked to remain anonymous said he examined the Mirai source code following its publication online and confirmed that it includes a section responsible for coordinating GRE attacks.

It's an open question why anna-senpai released the source code for Mirai, but it's unlikely to have been an altruistic gesture: Miscreants who develop malicious software often dump their source code publicly when law enforcement investigators and security firms start sniffing around a little too close to home. Publishing the code online for all to see and download ensures that the code's original authors aren't the only ones found possessing it if and when the authorities come knocking with search warrants.

My guess is that (if it's not already happening) there will soon be many Internet users complaining to their ISPs about slow Internet speeds as a result of hacked IoT devices on their network hogging all the bandwidth. On the bright side, if that happens it may help to lessen the number of vulnerable systems.

On the not-so-cheerful side, there are plenty of new, default-insecure IoT devices being plugged into the Internet each day. Gartner Inc. forecasts that 6.4 billion connected things will be in use worldwide in 2016, up 30 percent from 2015, and will reach 20.8 billion by 2020. In 2016, 5.5 million new things will get connected each day, Gartner estimates.

For more on what we can and must do about the dawning IoT nightmare, see the second half of this week's story, The Democratization of Censorship. In the meantime, this post from Sucuri Inc. points to some of the hardware makers whose default-insecure products are powering this IoT mess.

# data[].attributes.attachment_link.title
Source Code for IoT Botnet 'Mirai' Released

# data[].attributes.attachment_link.description
The source code that powers the "Internet of Things" (IoT) botnet responsible for launching the historically large distributed denial-of-service (DDoS) attack against KrebsOnSecurity last month has been publicly released, virtually guaranteeing that the Internet will soon be flooded with attacks from many new botnets powered by insecure routers, IP cameras, digital video recorders and other easily hackable devices.

# data[].attributes.body
Article

# data[].attributes.attachment_link.readable_text
Last week, we wrote about a DDoS attack on well-known investigative cybercrime journalist Brian Krebs.

To explain.

A DDoS attack is an aggressive sort of DoS attack, where DoS is short for denial of service.

A DoS is a bit like getting into the queue at the station to buy a ticket for the next train, only to have a time-waster squeeze in front of you and slow you down.

By the time the miscreant has asked, innocently enough, about the different sorts of ticket available, and whether it costs extra to take a bicycle, and how much longer it would take if he were to change trains in Manchester, only to walk off without buying a ticket at all...

...you've watched your train arrive, load up with passengers, and depart without you.

A DDoS attack is worse: it's short for distributed denial of service attack, and it's much the same thing as a DoS, except that the trouble-stirrer doesn't show up on his own.

Instead, he brings along a big posse of innocent-looking accomplices to flood the whole station with time-wasters.

Genuine customers who are mixed in with the trouble-makers end up waiting far longer than usual - a problem that usually gets more and more frustrating as the backlog grows.

In the attack on Krebs's site the crooks were able to generate an astonishing combined total of over 600 gigabits per second of time-wasting network traffic.

That's equivalent to about 60,000 fast home networks all turning their entire bandwith onto Krebs at the same time, or a whopping 600,000 regular ADSL connections at once (assuming a one megabit per second upload speed).

If we assume that even a voracious reader of Krebs's articles would use at most 10% of a home ADSL connection's bandwidth when browsing the site, then the cost of neutralising this level of attack is the same as supporting at least six million concurrent legitimate users.

The perpetrators in the mega-DDoS haven't been identified, but the attack happened not long after Krebs outed a DDoS-for-hire service called vDOS, leading to the arrest of two young hackers in Israel.

(Sophos experts Chester Wisniewski and John Shier discuss this attack, and the story behind it, in this week's Chet Chat security podcast. [Starts at 1'08".])

The reason we mentioned home networks above, by the way, is that's exactly where this attack seems to have originated.

Not from malicious bot or zombie software on regular computers, as might have been the case a few years ago, but from so-called Internet of Things (IoT) devices such as routers, web cameras and perhaps even printers.

If you're surprised to hear that, don't be.

Although a typical router or webcam has just a fraction of the computing power of your laptop, it's more than capable of filling a typical home network with outbound traffic.

(After all, your powerful new laptop relies on your router to handle all that outbound traffic, so if your laptop can fill up the network connection, that's only possible because the router can fill it on your laptop's behalf.)

Sadly, in the aftermath of the assault on Krebs, the source code of the malware used in the attack was openly published.

It's been removed from the hacking forum on which it was originally outed, but it still widely available "for research purposes" to anyone willing to look.

Mirai, as the malware is known, is badly programmed and unfinished, but that doesn't matter.

It works, and it's effective primarily because of bad programming in the very IoT devices it uses to do its dirty work.

The Mirai malware package

The Mirai bot, called simply bot in the source code, is written in C, and has three main components:

A call-home system that connects to a command-and-control server (which could be another insecure IoT device) to download details of whom to attack, and how.

A set of attack routines that can generate a range of legitimate-looking but purposeless streams of network traffic to eat away at the victim's network capacity.

A network scanner that searches randomly across the internet and tries to login in various ways to build and report a list of insecure IoT devices for the next wave of attacks.

The Mirai source code package also includes a command-and-control tool, called cnc, written in Go.

Cross-platform support is one of Go's strong points: the compiler directly supports seven different computer architecures, including the 32-bit and 64-bit Intel chips in most modern laptops and servers, and the AMD and MIPS chips common in price-sensitive home IoT devices.

In other words, both the attack bot and the control server can be built to run on regular computers as well as many commonly-used hardware devices.

There's a list of just over 60 built-in usernames and passwords that the Mirai bot uses to scan for other vulnerable devices; by all accounts, even this modest password dictionary is enough to find hundreds of thousands of easily-owned devices at a time.

How to steal 600 Gbit/sec

As we suggested above, between 60,000 and 600,000 home networks connecting simultaneously is, indeed, enough for a monster-sized attack of 600 gigabits per second.

We're disappointed, but not at all surprised, to hear that malware like Mirai has things so easy.

After all, when SophosLabs researchers recently looked into a strain of malware called Mal/Miner-C, they noticed that it was widely found on network attached storage (NAS) devices from a well-known vendor.

In this research, SophosLabs quickly found 7000 NAS devices that were publicly writable via the internet, using the FTP protocol, with no password at all.

Of these, 5000 (more than 70%) already contained a copy of the Mal/Miner-C malware, deliberately left behind by the crooks for future malware distribution campaigns.

When investigating the Miner-C malware, our researchers focused their investigation carefully. They looked only at NAS devices, only for public FTP servers with no password, and only for the presence of Mal/Miner-C. Malware such as Mirai has no such scruples when it goes looking for vulnerable devices, which is why it can quickly find hundreds of thousands of devices to abuse.

Following the attack on Krebs, and his fascinating reports on what happened, he wrote that:

Many readers [...] asked for more information about which devices and hardware makers were [targeted by Mirai]. As it happens, this is fairly easy to tell just from looking at the list of usernames and passwords included in the Mirai source code.

As you can see directly from the list above, and from a few tries with your favourite search engine, Krebs is right.

Some of the entries don't even need a search engine: username/password pairs such as root/realtek, root/dreambox and ubnt/ubnt speak for themselves.

But even obscure-looking credentials such as root/7ujMko0vizxv are easily traced.

And that's just the problem with hardwired "backdoor" passwords, as we've pointed out many times before.

Security through obscurity lasts only until someone penetrates that obscurity and shares the necessary secret, after which anyone can search for it, and so everyone knows it.

What to do?

If you're a device vendor, this list is for you:

Don't use hardwired passwords. Those "secret codes" that let your own support staff get in and fix problems cheaply for forgetful users are an injury to us all, because they also let crooks get in and create problems cheaply for everyone.

Don't set default passwords. At least, don't have default passwords that exist after the device has been set up for use. After a firmware reset, or on first bootup, prevent the device going online at all until the user has connected up directly to it and chosen unique passwords.

Don't allow unauthenticated or unencrypted protocols for inbound connections. In particular, that means no Telnet (use SSH instead), no FTP (use SFTP instead) and no web administration via HTTP (use HTTPS instead), even for connections from the internal network.

Don't open administrative connections on the outside interface by default. Most users don't need to login from the internet, so don't open up their devices by default for crooks to have a crack at logging in remotely. Let users opt in to remote access, instead of expecting them to remember to opt out.

LEARN MORE
For more IoT security horror stories from which we can all learn, both vendors and consumers, please see:

Follow @NakedSecurity
Follow @duckblog

# data[].attributes.attachment_link.title
Mirai "internet of things" malware from Krebs DDoS attack goes open source

# data[].attributes.attachment_link.description
Last week, we wrote about a DDoS attack on well-known investigative cybercrime journalist Brian Krebs. To explain. A DDoS attack is an aggressive sort of DoS attack, where DoS is short for denial of service.