:
:

Powered by GetResponse email marketing software

Make Money Online Instantly

Make Money Online Instantly - Your One Stop Resource For "Make Money Online Instantly"

Friday, August 21, 2020

Recovering Data From An Old Encrypted Time Machine Backup

Recovering data from a backup should be an easy thing to do. At least this is what you expect. Yesterday I had a problem which should have been easy to solve, but it was not. I hope this blog post can help others who face the same problem.


The problem

1. I had an encrypted Time Machine backup which was not used for months
2. This backup was not on an official Apple Time Capsule or on a USB HDD, but on a WD MyCloud NAS
3. I needed files from this backup
4. After running out of time I only had SSH access to the macOS, no GUI

The struggle

By default, Time Machine is one of the best and easiest backup solution I have seen. As long as you stick to the default use case, where you have one active backup disk, life is pink and happy. But this was not my case.

As always, I started to Google what shall I do. One of the first options recommended that I add the backup disk to Time Machine, and it will automagically show the backup snapshots from the old backup. Instead of this, it did not show the old snapshots but started to create a new backup. Panic button has been pressed, backup canceled, back to Google.


Other tutorials recommend to click on the Time Machine icon and pressing alt (Option) key, where I can choose "Browse other backup disks". But this did not list the old Time Machine backup. It did list the backup when selecting disks in Time Machine preferences, but I already tried and failed that way.


YAT (yet another tutorial) recommended to SSH into the NAS, and browse the backup disk, as it is just a simple directory where I can see all the files. But all the files inside where just a bunch of nonsense, no real directory structure.

YAT (yet another tutorial) recommended that I can just easily browse the content of the backup from the Finder by double-clicking on the sparse bundle file. After clicking on it, I can see the disk image on the left part of the Finder, attached as a new disk.
Well, this is true, but because of some bug, when you connect to the Time Capsule, you don't see the sparse bundle file. And I got inconsistent results, for the WD NAS, double-clicking on the sparse bundle did nothing. For the Time Capsule, it did work.
At this point, I had to leave the location where the backup was present, and I only had remote SSH access. You know, if you can't solve a problem, let's complicate things by restrict yourself in solutions.

Finally, I tried to check out some data forensics blogs, and besides some expensive tools, I could find the solution.

The solution

Finally, a blog post provided the real solution - hdiutil.
The best part of hdiutil is that you can provide the read-only flag to it. This can be very awesome when it comes to forensics acquisition.


To mount any NAS via SMB:
mount_smbfs afp://<username>@<NAS_IP>/<Share_for_backup> /<mountpoint>

To mount a Time Capsule share via AFP:
mount_afp afp://any_username:password@<Time_Capsule_IP>/<Share_for_backup> /<mountpoint>

And finally this command should do the job:
hdiutil attach test.sparsebundle -readonly

It is nice that you can provide read-only parameter.

If the backup was encrypted and you don't want to provide the password in a password prompt, use the following:
printf '%s' 'CorrectHorseBatteryStaple' | hdiutil attach test.sparsebundle -stdinpass -readonly

Note: if you receive the error "resource temporarily unavailable", probably another machine is backing up to the device

And now, you can find your backup disk under /Volumes. Happy restoring!

Probably it would have been quicker to either enable the remote GUI, or to physically travel to the system and login locally, but that would spoil the fun.
Related word

posted by Affiliate Marketer @ 7:57 PM  0 Comments

Advanced Penetration Testing • Hacking The World'S Most Secure Networks Free PDF

More information

posted by Affiliate Marketer @ 11:29 AM  0 Comments

Learning Web Pentesting With DVWA Part 1: Installation



In this tutorial series I'm going to walk you through the damn vulnerable web application (DVWA) which is damn vulnerable. Its main goal according to the creators is "to aid security professionals to test thier skills and tools in a legal environment, help web developers better understand the process of securing web applications and to aid both students & teachers to learn about web application security in a controlled class room environment."

I am going to install DVWA in docker so the prerequisite for this tutorial will be an installation of docker (Docker is not the only way to install DVWA but if you have docker already installed then it may be the easiest way to install DVWA).

To install DVWA in docker run your docker deamon if it's not running already and open a terminal or powershell and type:

docker rum --rm -it -p 8080:80 vulnerables/web-dvwa




It will take some time to pull the image from docker hub depending on your internet speed and after it is complete it will start the dvwa application. In the command we have mapped the image instance's port 80 to our hosts port 8080 so we should be able to access the web application from our host at http://localhost:8080

Now open your favorite web browser and go to http://localhost:8080
You should be prompted with a login screen like this:



login with these creds:
username: admin
password: password

After login you'll see a database setup page since this is our first run. Click on Create / Reset Database button at the bottom. It will setup database and redirect you to login page. Now login again and you'll see a welcome page.



Now click on DVWA Security link at the bottom of the page navigation and make sure the security level is set to Low. If it is not click on the dropdown, select Low and then click submit.




Now our setup is complete, so lets try a simple SQL attack to get a taste of whats about to come.

Click on SQL Injection in navigation menu.
You'll be presented with a small form which accepts User ID.
Enter a single quote (') in the User ID input field and click Submit.
You'll see an SQL error like this:



From the error message we can determine that the server has a MariaDB database and we can see the point of injection.
Since there are many quotes we are not able to determine the exact location of our injection. Lets add some text after our single quote to see exactly where our injection point is.
Now I am going to enter 'khan in the User ID field and click Submit.



Now we can see exactly where the point of injection is. Determining the point of injection is very important for a successful SQL injection and is sometimes very hard too, though it might not be that much useful here in this exercise.

Now lets try the very basic SQL Injection attack.
In the User ID field enter ' or 1=1-- - and click Submit.



We will explain what is going on here in the next article.


References:-
1. DVWA Official Website: http://www.dvwa.co.uk/

More information


posted by Affiliate Marketer @ 3:01 AM  0 Comments