9 ways people are trying to hack into our company and how to protect your online business

By Erik Desjardins ● May 3, 2018
Share
Tweet

Acquiring data. You have likely heard those two words on countless occasions, seldom followed by a concrete reason why. I always found this pretty interesting : why acquire data at all if you are not planning on using it.

User data is valuable, but can also be really dangerous to have. Imagine you have a server with a lot of personal information about your users. You never really use it, and undergo a data breach.

Not only do you become a public threat, but you also traded something that had close to no value to your business for hatred and lawsuits. What a shame.

Needless to say Narcity Media doesn’t store its readers personal data on its servers. Why? Because we don’t need it. With movements and new regulations like GDPR, it also makes everything so, so much easier.

Still, malignant scrapers, bots, and angry hackers are having fun with our stuff. The good news is no one was successfully able to break in. I thought it would be fun to expose what our homemade security system reported.

WordPress

No, we are not using WordPress anywhere else. Yet, we detect at least 2 WPscan scrapes every day, sometimes 100.

It’s interesting to see the list of passwords attempted using a POST request to “/wp-login.php”. Since our backend does not use PHP, I thought it would be fun to still handle requests sent to that wp-login.php endpoint, and store the POST data in a dummy database.

Those are the five most common attempted combos.This one wasn’t really surprising. If you have a website, please disable the username “admin”. At least use your full name, or an auto-generated string.

SSH

Another advice I like to give is to change your SSH port while keeping port 22 open. Maybe you’ve heard of the term “honeypot”. If you haven’t, it’s basically a fake login where you acquire the username and password used, and create a fake experience where the user believes they are actually logged in. That one made me laugh.

With a little bit of Python and a few beers, you can create a pretty decent fake SSH. I set up this honeypot to let anyone believe they’re in with any username and password combo, or any private key.

Surprisingly, the most used combo after root / [blank] was : ubuntu / ubuntu.

Other interesting attempts were :

But my all time favourite :

Ah, people. If you know someone with that username, you should probably tell them to change their passwords, and to maybe use more special characters.

I’d also like to point out that once “logged in”, most people had NO IDEA how to write proper bash commands.

The login page

Some of them read about Narcity Media before attempting to break in. Although many requested to “/manager”, “/wp-login”, “/edit”, “/servlet” and even “/lilium”, some unsuccessful login attempts were made at the good endpoint. Great job!

I’ve seen some pretty interesting noSQL injection attempts such as :

Ok. If you handle logins, please don’t evaluate JSON. This could have worked otherwise.

npm vulnerabilities

We don’t use any popular npm packages. Too much trouble for too little reward.

I’m all about avoiding to reinvent the wheel, but you can often build a really efficient web server in a matter of minutes. If you know what you’re doing, trying to understand a middleware and make it work with your current stack can be a huge pain compared to writing a small module, documenting it, and presenting it to your team.

We’ve noticed requests to “/node_modules”. What? Why? Everything in there is open source– if you want to know our server’s dependencies, at least try the package.json instead.

Even though it’s a great package for quick deployment, we don’t use Express either.

Directory traversing

How may directories do you think we have, here? So they believe the directory structure is  /usr/share/narcitymedia/prod/server/projects/git/cms/lilium/v/3/0/2/latestbuild/ship/somethingAboutOctoCat/lilium-cms/prod.index.js ?

Many attempts seemed to be coming from automated systems considering the User-Agents were shady. Still, we see more than thousands of requests every month to :

If you just realized you’re vulnerable to such attacks, a good start would be to refuse requests with “..”, set a virtual root, or something hackier like replacing “..” with “.” in the requested URL before doing anything else. Usually, web servers like nginx or Apache will automatically set a virtual root, but your backend app might not.

Emails

Those. I LOVE those. People sending those emails know our names, positions in the business, and are pretty decent at writing straight to the point messages. Only problem is processing a wire transfer to a PERSONAL ACCOUNT doesn’t make sense, and any well established business wouldn’t get caught.

The part where it gets sad is, well– if we keep on receiving these, it’s because it sometimes work. Profiting from people’s naiveness is despicable.

Good news is a lot of people are actively fighting against scams. Even YouTube channels like Nicole Mayhem who goes a step further and record the phone conversations exist. I have a friend of a friend who’s often having a blast closing scam websites like those that clone a bank login page to acquire bank logins through phishing.

Fun.

Bruteforce

Slack is just great. Their API lets you automate so many things, and provides a way to create a quick, real-time notification system.

To give you an idea of how this works :

  1. Store IP + headers hash of requester in RAM with current minute of the day [0, 1440]
  2. Increment that number on each request
  3. If number goes above threshold (100 here), create IP range from source depending on location, and refuse requests for 5 minutes
  4. Send Slack message
  5. Double ban timeout on every ban

Don’t apply logic for static assets and articles.

This doesn’t protect us from distributed denial of service attacks (DDOS), but it’s a pretty quick way to avoid non-distributed attacks. Cloudflare and AWS will help us otherwise.

Slowloris

Alright, so some web servers including some version of Apache (we don’t use that either) have this vulnerability where open sockets will remain open without any timeout until the complete HTTP headers are sent. Using a pretty convenient and commonly known perl script, it is possible to fire up a Slowloris attack with one simple command. This attack can be brutal, especially when distributed.

Not only does it render the server response-less, but it also locks you out due to lack of necessary memory and/or available sockets to handle an SSH tunnel.

Since most web servers won’t do anything until the HTTP headers are received, those will remain open forever. Running this type of attack requires almost no hardware since you aren’t sending anything. They can also be hard to detect because they aren’t that different from normal requests.

Our server will read the HTTP headers in chunks, will do validation on every chunk, and will start the timeout after opening the socket rather than after parsing the headers.

SQL injection

Long story short, we don’t accept query parameters.

We receive a breakdown of all the HTTP error response codes every day, and a lot of them are 404 coming from SQLi requests. This surprised me because everything on the website is public, and there’s no reader login. Why would anyone try to get “more” where everything is already in their face?

Well, a lot of these SQLi attempts contain UNION to tables such as “wp-users”, “users”, “entities”, and even “logins”.

Sigh. We don’t even have a SQL database.

Bottomline

I might start redirecting those attempts to a page with job offers. We’re always looking for talented people to join our amazing team of sharp-minded, motivated, and highly sarcastic developers. A

Trying to hack a harmless website is just ridiculous. Pentesting is fun — I know — and you should do it often! On your own websites that is.

Remember, if you don’t need people information, don’t store it. If one day you get hacked yet don’t have user data, people will forget about it the day after, if they even notice it. Storing private user data is a huge social responsibility, and should not be taken lightly. You can use various third-party systems to manage acquired user data such as Google Analytics or a Facebook Pixel. If they get hacked, it would be a terrible day yet a day you wouldn’t face any lawsuit.

The featured image comes from Unsplash, by Hugo Jehanne.