LiquidFiles Documentation
LiquidFiles Documentation

Automated Attacks

On any system that's connected to the Internet, you will see a range of automated attacks that's pretty much happening constantly. This can be referred to as Internet noise or Script Kiddie attacks.

What has happened is that after a vulnerability as been discovered, someone writes a script to exploit this particular vulnerability and then these "script kiddies" uses this script and just scans the Internet up and down looking for vulnerable systems. This is sort of the equivalent of someone walking up and down the street pulling door handles looking for an open door. It's a very unsofisticated attack.

If you look in any system that's connected to the Internet and has a web server, if you look in the Admin → System Log, filtering on Webserver, you will see log entries like this:

152.136.41.189 - - [18/Sep/2020:02:10:55 +0000] http://52.55.253.91 -/- "GET /admin/index.php HTTP/1.1" 404 55 639 "-" "Mozilla/5.0 (Windows NT 5.2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 SE 2.X MetaSr 1.0" "#; charset=utf-8"
152.136.41.189 - - [18/Sep/2020:02:11:00 +0000] http://52.55.253.91 -/- "GET /admin/pma/index.php HTTP/1.1" 404 59 643 "-" "Mozilla/5.0 (Windows NT 5.2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 SE 2.X MetaSr 1.0" "#; charset=utf-8"
152.136.41.189 - - [18/Sep/2020:02:11:00 +0000] http://52.55.253.91 -/- "GET /admin/PMA/index.php HTTP/1.1" 404 59 643 "-" "Mozilla/5.0 (Windows NT 5.2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 SE 2.X MetaSr 1.0" "#; charset=utf-8"
152.136.41.189 - - [18/Sep/2020:02:11:00 +0000] http://52.55.253.91 -/- "GET /admin/mysql/index.php HTTP/1.1" 404 61 645 "-" "Mozilla/5.0 (Windows NT 5.2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 SE 2.X MetaSr 1.0" "#; charset=utf-8"
152.136.41.189 - - [18/Sep/2020:02:11:01 +0000] http://52.55.253.91 -/- "GET /admin/mysql2/index.php HTTP/1.1" 404 62 646 "-" "Mozilla/5.0 (Windows NT 5.2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 SE 2.X MetaSr 1.0" "#; charset=utf-8"
152.136.41.189 - - [18/Sep/2020:02:11:03 +0000] http://52.55.253.91 -/- "GET /admin/phpmyadmin/index.php HTTP/1.1" 404 66 650 "-" "Mozilla/5.0 (Windows NT 5.2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 SE 2.X MetaSr 1.0" "#; charset=utf-8"
152.136.41.189 - - [18/Sep/2020:02:11:03 +0000] http://52.55.253.91 -/- "GET /admin/phpMyAdmin/index.php HTTP/1.1" 404 66 650 "-" "Mozilla/5.0 (Windows NT 5.2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 SE 2.X MetaSr 1.0" "#; charset=utf-8"
152.136.41.189 - - [18/Sep/2020:02:11:04 +0000] http://52.55.253.91 -/- "GET /admin/phpmyadmin2/index.php HTTP/1.1" 404 67 651 "-" "Mozilla/5.0 (Windows NT 5.2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 SE 2.X MetaSr 1.0" "#; charset=utf-8"
5.188.210.227 - - [18/Sep/2020:04:00:08 +0000] http://5.188.210.227 -/- "GET http://5.188.210.227/echo.php HTTP/1.1" 400 666 826 "https://www.google.com/" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36" "text/html; charset=utf-8"

If you look at the GET /path you'll see that all of these attacks are targeting PHP, which is a common script system on the Internet. Most of these attack seem to be targeting PHP — but LiquidFiles does not use PHP so is just not vulnerable to any of these attacks.

CSRF Errors

Another things you'll commonly see if you in Admin → Activity Log are entries like these:

21 Oct, 2022 09:14:35	err	{"message":"CSRF error for User: unknown from invoice.accountingsecurities.com (95.214.235.205), Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
21 Oct, 2022 07:33:50	err	{"message":"CSRF error for User: unknown from b43.jonasklg.com (185.254.196.115), Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
21 Oct, 2022 06:59:03	err	{"message":"CSRF error for User: unknown from 103.89.89.46, Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
21 Oct, 2022 04:45:35	err	{"message":"CSRF error for User: unknown from b43.jonasklg.com (185.254.196.115), Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
21 Oct, 2022 03:09:02	err	{"message":"CSRF error for User: unknown from 198-23-213-25-host.colocrossing.com (198.23.213.25), Accessing: https://52.63.67.172/, Session Terminated","log_level":"error"}
21 Oct, 2022 03:09:01	err	{"message":"CSRF error for User: unknown from 198-23-213-25-host.colocrossing.com (198.23.213.25), Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
21 Oct, 2022 02:06:15	err	{"message":"CSRF error for User: unknown from 105.159.17.114, Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
21 Oct, 2022 02:04:40	err	{"message":"CSRF error for User: unknown from 115-237.static.ipcserver.net (185.158.115.237), Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
20 Oct, 2022 22:58:50	err	{"message":"CSRF error for User: unknown from invoice.accountingsecurities.com (95.214.235.205), Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
20 Oct, 2022 22:39:35	err	{"message":"CSRF error for User: unknown from 79.110.62.114, Accessing: https://52.63.67.172/, Session Terminated","log_level":"error"}
20 Oct, 2022 22:39:32	err	{"message":"CSRF error for User: unknown from 79.110.62.114, Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
20 Oct, 2022 21:19:53	err	{"message":"CSRF error for User: unknown from invoice.accountingsecurities.com (95.214.235.205), Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
20 Oct, 2022 20:14:39	err	{"message":"CSRF error for User: unknown from b43.jonasklg.com (185.254.196.115), Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
20 Oct, 2022 20:14:39	err	{"message":"CSRF error for User: unknown from b43.jonasklg.com (185.254.196.115), Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
20 Oct, 2022 18:27:31	err	{"message":"CSRF error for User: unknown from invoice.accountingsecurities.com (95.214.235.205), Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
20 Oct, 2022 17:14:56	err	{"message":"CSRF error for User: unknown from b43.jonasklg.com (185.254.196.115), Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}
20 Oct, 2022 15:47:18	err	{"message":"CSRF error for User: unknown from invoice.accountingsecurities.com (95.214.235.205), Accessing: http://files.liquidfiles.com/login, Session Terminated","log_level":"error"}

CSRF, or Cross Site Request Forgery, is an advanced attack where an attacker has control of a site X that they lure users to. When the user is lured to site X (clicks on a link in an email, ...), some JavaScript is loaded from site X that sends a request to site Y. If the user is logged in to site Y, the attacker from site X can do bad stuff on site Y without the user knows about it. It's unlikely that someone is actually targetting you with this type of attack.

One of the protections against CSRF attacks is by inserting a random request token. If you look at the source code of any page on the LiquidFiles system, you'll see an authenticity_token field in every form. This authenticity_token has a random code in it that the browser sends back to the LiquidFiles server. What this tells the LiquidFiles server is that the browser has visited the LiquidFiles page before the form submission. I.e. before the user attempts to POST /login, it has done a GET / or GET /login. If the browser didn't do that, they couldn't send the correct, unique authenticity_token that is required for this form submission.

What has happened above is that there's been various attempts at sending POSTs to http://files.liquidfiles.com/login. Now this site requires https so already there would these attempt fail, but in this case the CSRF protection has kicked in and the POST attempt does not reach the function inside LiquidFiles that authenticates the user, because this automated attack has just attempted to send a bunch of POSTs without visiting the login page first to received the random authenticity_token required for this form submission to actually take place.

Please see the Ruby on Rails Security documentation for detailed information on how this CSRF protection works in LiquidFiles.

CSRF and proxies

A proxy is among other things a device that attempts to reduce network load by caching pages so subsequent browser request loads information from the local cache and not from the Internet. LiquidFiles is configured so that all "assets" (static JavaScript, stylesheet, logos and other files that are common for all browser sessions and does not contain any private information) has http headers to tell proxies that they can cache this file for as long as they want. And all pages with any potential private information cannot be cached at all. If a cache does not do the right thing and attemtps for instance to cache the home page "/" assuming this is not unique, you're going to run into problem with the CSRF protection. The unique authenticity_token that is inserted and unique for this browser session has now been cached (against instructions) and the next request will reuse the previous authenticity_token and the login will fail with an CSRF error. If this happens you will need to contact your proxy vendor and have them update their configuration to honor the http cache headers that are being set and not trying to apply their own assumptions that pages that they think can be cached should be cached regardless of this setting.

So how do I stop these automated attacks?

If you have a door, how do you prevent someone from pulling the handle to see if it's open? You can't. And same with systems connected to the Internet, you can't prevent someone from scanning your IP addresses looking for vulnerabilities.

But I really want to stop these automated attacks?

If you're really concerned, you will need to use some for of Web application firewall (WAF). On top of that, you'll have to spend weeks tweaking each web application you have to ensure that the Web Application Firewall does not block legitimate traffic. Your best bet is likely to engage a local security company that can monitor all your web applications, firewalls and anything else you have connected to the Internet on an ongoing basis.

How do I know if the attack succeeded?

First, anything where you see anything in regards to PHP, it's not going to succeed because LiquidFiles does not use PHP.

Second, you can't prove a negative — i.e. you can't prove that no one has succeeded breaking in to any system.

What you have to do is to inspect, and keep inspecting, that there's no actual suspicious activity in the logged in activity.

Are there any good news?

Yes, it's extremely unlikely that a system like LiquidFies, which uses a modern web application framework, that is designed with security in mind and gets frequently security scanned is vunerable to any of these automated attacks.

The one thing you have to ensure is that your system is kept up to date. On default LiquidFiles has auto-update enabled to ensure that as many customers have up to date systems to further minimize the risk of any LiquidFiles system being vulnerable. If you don't want to enable auto-update, you will have to develop your own procedure to update LiquidFiles (and any other system you have connected to the Internet) periodically.