
Ask HN: Is a static site hosted on AWS S3 'hackable'? - bikamonki
Let&#x27;s assume both the domain registrar&#x27;s and AWS pwd are super strong, and that static html files are uploaded to S3 from a &#x27;clean&#x27; computer and only from that computer. Can the site be hacked? Defaced? DDOS?
======
dguido
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/](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.

~~~
rsync
"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)

~~~
dguido
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.

~~~
morgante
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.

------
matiu
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

~~~
TamDenholm
As always the weakest part of any security system is the people within it.

------
tptacek
Presuming you don't misconfigure S3, this is one of the least "hackable" ways
to stand up a website.

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

~~~
Artemis2
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...](https://developer.mozilla.org/en-
US/docs/Web/Security/CSP/CSP_policy_directives#frame-ancestors)) and not load
frames to your website.

------
DiabloD3
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...](http://www.troyhunt.com/2015/06/understanding-http-strict-
transport.html)

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

~~~
bikamonki
For the sake of argument let's assume credentials are not hackable. My
question: is the site itself hackable?

~~~
bigiain
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.

~~~
personjerry
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.

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

------
evandrix
You can position your site behind CloudFlare's DDoS protection, eg.
[http://ht.transparencytoolkit.org](http://ht.transparencytoolkit.org)

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

------
contingencies
Endpoint security.

SSH guessable passwords.

HTTP daemon vulnerabilities.

Any other daemons running.

Resource exhaustion.

DNS.

Client MITM.

Route corruption.

