1

I'm investigating some files in a website which were hacked and the site is under version control in a Subversion repository, but it doesn't show the files as being modified. How do I stop SVN from ignoring the files so I can check in clean copies?

I'm cleaning up a website that was hacked (relatively minor, some casino links were added to a page header) and the site is hosted from a working copy of an SVN repo. (Yes, it does have a functioning .htaccess file that prevents access to the .svn folders.) Interestingly, the hacked file has the modification date of the last updated version in the SVN repo, svn status shows it as being unmodified, svn log -v <hacked_file> shows no commits past the last updated version in the SVN repo, svn diff <hacked_file> also shows no difference between the file and the last modified version in the repo. I whipped up some scripts to check logs & diffs between each version and there's nothing modifying that file.

However, I noticed that the file name does appear in .svn/all-wcprops, as follows:

K 25
svn:wc:ra_dav:version-url
V 48
/<repo>/!svn/ver/97/trunk/www.example.com/<hacked_file>
END
favicon.ico

Naturally, svn proplist -v <hacked_file> doesn't output anything and svn propget 'svn:wc:ra_dav:version-url' <hacked_file> returns an error saying it's "a wcprop, thus not accessible to clients".

I'm not seeing any 'svn:ignore' props and svn status --no-ignore doesn't show the hacked file.

I've done a lot of research and am really not finding any information in SVN 'wcprops' or .svn/all-wcprops. Is it safe to delete the all-wcprops file?

Any other possibilities/options/advice other than blowing away the working copy and checking on a fresh copy (this in an all-too-large repo, so it's time consuming and would take a long time to review to make sure everything is working, esp. since I can't trust that there are no modified files that might be lost)? Is this something that was likely modified in the main SVN repo?

  • Blowing it away and restoring from a known-good version is the right thing to do regardless. As you say, you can't trust that there are no modified files that might not be lost... – Michael Homer Jan 31 '17 at 18:51
  • @MichaelHomer Err, restore it to the version that was just cracked a few hours ago? :) – Satō Katsura Jan 31 '17 at 18:58
  • 1
    Over leaving up the version that is known to be compromised right now and can never be trusted again? Yes. Blow the whole account away, in fact. – Michael Homer Jan 31 '17 at 19:09
0

As others have pointed out, it's best to check out a fresh copy of the repository from SVN anyway, since the working copy is both untrustworthy and unreliable. So, I did the following:

  • Checked out a new working copy
  • Confirmed that the contents of the hacked file were correct as appeared in the repository, without the malicious modifications
  • Confirmed that modifications to the hacked file (and others listed in .svn/all-wcprops) would show as modified by svn status when edited
  • Swapped out the working copies
  • Ran diff -qrx .svn <hacked_working_copy>/ <new_working_copy>/ to determine what files were actually changed/added in the hacked working copy, but not showing as such
  • Confirmed the contents of, and manually copied over, any uncommitted files, as necessary
  • Archived & removed the hacked working copy for further investigation/evidence, then removed it

Naturally, further action & precautions are being taken, but the recursive diff made it easy to identify questionable files.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.