2

In spite of precautions, hackers got files of mine.

I have a password protected area on my server. I am using

AuthType Basic
AuthName "Title"
AuthUserFile /var/www/vhosts.../.htpasswd
Require valid-user

And in that .htpasswd I have

username:$apr1......

I am using SSL/TLS with a self-signed certificate to encrypt pw-& file transmission.

But in my access logs I found several ips, for instance 31.55.57.141 not just trying to access but getting through to my files(200), even though I changed the pw just in the 1st of february.

31.55.57.141 -0 username [12/Feb/2017:20:36:52 +0100] GET /IMG_20170212_202924800~3.jpg HTTP/1.1 200 802973 android-app://com.google.android.gm Mozilla/5.0 (Linux; Android 6.0; ALE-L21 Build/HuaweiALE-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.91 Mobile Safari/537.36

I only send links via email and I never publish them in forums on the internet.

What methods do you recommend to avoid this from happening in the future?

5
  • 2
    It seems pretty unusual that an attacker would be accessing these files via a mobile phone. If the user-agent is not forged, this access log entry is from someone using the GMail app to access the file... and you've mentioned sending links via email. Why do you think this is not a legitimate access?
    – David
    Jan 14, 2018 at 23:31
  • That is a good point. But I know the recipients and they were never in great britain. I collected a list of IPs that accessed my files. Do they not look suspicious to you? pastebin.com/AzGCdzu2 Jan 15, 2018 at 0:45
  • The information you show so far suggests that the password is known to the client. But the question provides no useful details which can be used to pin down how the client got access to the password. It might have been included in some mail, it might have been guessed, there might have been a successful brute-force attack against a weak password etc. Since it is unclear where the client got the password it is unclear on how to protect against this attack. That's why I suggest to close it as too broad. But the general rule is: use a strong password and don't tell anybody. Jan 15, 2018 at 5:38
  • While your users may not be in Great Britain, they may - or may not - be using a VPN provider and/or Tor that has an endpoint there to access your web site. Jan 15, 2018 at 7:21
  • @Anti-weakpasswords I just thought about a proxy... Jan 15, 2018 at 12:19

1 Answer 1

0

What methods do you recommend to avoid this from happening in the future?

  • If you have unknown security worries, then go over the security of your servers from top to bottom
    • All your servers
    • Validate all the users and all the access
      • In particular, who has access to the files in question
    • If you can reasonably block IP address ranges - like foreign ones - go for it. See who complains - if the user believes it's legit Great Britain access, they'll complain. Maybe after their brother/sister/cousin's roommate thrice removed complains to them.
    • Change all the passwords to long, random strings, perhaps using KeePass to generate and protect them with a long, strong master password, AFTER changing the iteration count (database, settings) to be AT LEAST 1 second of time, preferably more.
    • Make sure HTTP isn't allowed at all
  • Validate your firewall security
    • Same treatment
  • Turn up logs to a higher level so you can see more
    • Start looking at WHO is logging in to those links to get the passwords
  • Since you use SSL/TLS to move passwords around, use SSLLabs to validate your TLS settings.

    • Increase security if possible this answer still has valid cipher suite reasoning and lists.
  • I see you're using Apache's $apr1$ password hashing algorithm; that's iterated MD5. Stop that and use either BCrypt through htpasswd $2y$ or your operating system's iterated SHA-256/SHA-512 version, with a high work factor/iteration count.

    • BCrypt should be used in general, but if you insist, you could use - on Debian - something like the following after apt-get install whois
    • mkpasswd -m sha-512 -R 500000 -S RandomSalt
      • Make sure to generate a random salt per username+password
  • If you can, start giving each valid user their own username/randomly generated long password pair, even, and then look in your logs to see which username is coming from weird places.
  • If you're truly paranoid about this, investigate having a very minimal username/IP/links of interest logging that goes straight to a printer - awfully hard for an attacker to alter paper logs.
  • If you want to see even more, use Wireshark to decrypt the TLS so you can see what password they're sending over, in the fantastically unlikely case that there is some kind of hidden master password at play.
0

Not the answer you're looking for? Browse other questions tagged .