apt get life

Life around technology

You are here: Home

mount disk image created with dd using ubuntu

by

If you’ve cloned a whole drive using dd and you need to access one of the partitions on it here are some steps to follow in order to gain access:

Find the partition start sectors using fdisk -b512 -l. Note that you’re explicitly setting the sector size to 512 bytes and you’ll need to change your command to match your own image file.

1
fdisk -b512 -l backup_sata.img

You should get output similar to this (note I’ve truncated it to only show the appropriate output):

Shell
1
2
3
4
5
6
Device         Boot     Start       End   Sectors   Size Id Type
backup_sata.img1 *         2048    206847    204800   100M  7 HPFS/NTFS/exFAT
backup_sata.img2         206848 237185023 236978176   113G  7 HPFS/NTFS/exFAT
backup_sata.img3      237185024 588070911 350885888 167.3G  f W95 Ext'd (LBA)
backup_sata.img4      588070912 625137663  37066752  17.7G 27 Hidden NTFS WinRE
backup_sata.img5      237187072 588070911 350883840 167.3G  7 HPFS/NTFS/exFAT

Normally sector are 512 bytes, so you can calculate the offset you need in the next command with:

start * 512 = offset

So if you want to mount backup_sata.img5 (partition 5 of the backup image) you’d run 237187072×512=121439780864:

1
mount -o ro,loop,offset=121439780864 backup_sata.img /backup_sata

Remember to have created /backup_sata or whatever directory you’re mounting to first!

Fixing “Cannot remount block device is write protected” on Ubuntu

by

While working on an old hard drive, I came across a problem that it would only mount as read only, even when specifying that it should mount as read write. Here’s an example:

1
2
mount /dev/sdb1 /media/aptgetlife/datadisk -o remount,rw
mount: cannot remount block device /dev/sdb1 read-write, is write-protected

By this point I’d already got the data disk mounted to the local user media folder, so I could read data from /media/aptgetlife/datadisk but not write data to it.

After some investigation I was able to found this post on stack overflow regarding a similar problem and a solution using blockdev:

1
blockdev --setrw /dev/sdb1

After which it was possible to run the mount command again, which didn’t present an error and allowed me to write data to the disk.

Add a policy to ImageMagick in Debian

by

As Arstechnica have recently reported, there is a critical security vulnerability in ImageMagick, an image processing library used by many websites. While official patches are being worked on, this is a reccomended workaround to secure ImageMagick on Debian.

1. Check loaded Imagick policies

From a terminal, check to see if any policies are loaded. There will almost certainly be none returned if you’ve not configured any previously.

Check ImageMagick Policies
1
convert -list policy

2. Open Imagick’s policy.xml file

In Debian, you can find the ImageMagick policy file in /etc/ImageMagick:

Edit Policy.xml
1
nano /etc/ImageMagick/policy.xml

In other operating systems your best bet is to run a find:

Find Policy.xml for Non-Debian based systems
1
find /usr | grep "policy.xml"

3. Edit policy.xml

Now we need to edit policy.xml. The current reccomended settings related to the vulnerability are here: https://gist.github.com/rawdigits/d73312d21c8584590783a5e07e124723 It’s best to check this URL for the latest version. Alternatively here’s the code at time of writing:

policy.xml
1
2
3
4
5
6
7
<policymap>
  <policy domain="coder" rights="none" pattern="EPHEMERAL" />
  <policy domain="coder" rights="none" pattern="URL" />
  <policy domain="coder" rights="none" pattern="HTTPS" />
  <policy domain="coder" rights="none" pattern="MVG" />
  <policy domain="coder" rights="none" pattern="MSL" />
</policymap>

Remember it’s Ctrl + x to exit nano and you do want to save the changes. If you’re told you don’t have write permissions try closing the file and opening it again with sudo.

4. Check the Imagick policy is loaded

Now re-run the first step to make sure the policy has been loaded properly.

Check ImageMagick Policies
1
convert -list policy

You should get the following output:

policy output
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#
Path: [built-in]
  Policy: Undefined
    rights: None
 
Path: /etc/ImageMagick/policy.xml
  Policy: Coder
    rights: None
    pattern: EPHEMERAL
  Policy: Coder
    rights: None
    pattern: URL
  Policy: Coder
    rights: None
    pattern: HTTPS
  Policy: Coder
    rights: None
    pattern: MVG
  Policy: Coder
    rights: None
    pattern: MSL

For more details on the problem, check out the ArsTechnica post here, and the ImageMagick forum announcement on the subject here.

Official patches are due to be distributed over the weekend, but may take longer to enter your distributions package manager.

Laravel 5.2 API Token Authentication

by

At work I’ve been tasked with improving an API recently, and I decided it would be a good opportunity to take Laravel out for a spin. I’ve been keen on learning more about laravel and it’s API capabilities which are supposedly very strong, although I have noted that there’s not much documentation around them. The existing API is flat PHP and uses token based authentication. This allows users to authenticate with a string “api_key” in the request URL, in the header or in the body of the JSON request. I decided that instead of trying to get existing users to upgrade to something like oAuth (for which there are some interesting plugins https://packagist.org/packages/lucadegasperi/oauth2-server-laravel), I’d just implement the same token based authentication model for the revised API in Laravel. There are already advantages to using Laravel for APIs – it highly encourages a restful approach, as for Laravel 5.2 it includes rate limiting out of the box and allows for route prefixing, so it is possible to have multiple endpoints in one Laravel application.

Setting up token based authenticaton in Laravel is so poorly documented that it took me a while to work out how it is achieved.

1. User API Tokens

Users need to have an API token to be associated with them in order to allow the authentication model to work. This is easy enough to add by editing the user migration in your laravel installation.

edit CreateUsersTable
1
2
// Store an API key for this user.
$table->string('api_token', 60)->unique();

This allows you to store a 60 character unique API Token for each user.

2. Setting up API Authentication

There are several ways you can now call API Token authentication for your application. Probably the best is to use middleware in your routes file:

Adding API authentication to your middleware
1
2
3
4
5
6
Route::group([
    'prefix' => 'api',
    'middleware' => 'auth::api'
    ], function() {
    Route::resource('fruit', FruitController);
});

Now any time requests are made to the route group, the API authentication method will be called. This includes token based authentication (now defined in the users table) as well as the API rate limiting.

3. Making API Requests

You can now submit your API requests to see if the Laravel token authentication is working. To do this you can submit “api_token” as either a GET or POST paramiter. There’s also hidden away the option to have it set as a header, however this requires you to use an Authorization header:

Key: ‘Authorization’

Value: ‘Bearer [token]’

Check out the code here:

https://github.com/laravel/framework/blob/c04159dee4a47b0d7cd508ab720932121927b1b3/src/Illuminate/Http/Request.php#L815-L822

and here:

https://github.com/laravel/framework/blob/master/src/Illuminate/Auth/TokenGuard.php#L81-L94

 

Linux servers – using ClamAV to find malware

by

ClamAV is an open source anti-virus program that can be run from the command line, making it incredibly useful for locating any viruses and malware on Linux based servers. Recently someone I’ve previously worked with reported that they’d had reports of abuse originating form one of their servers. Given the quantity of sites, it was difficult to locate any potential vulnerabilities.

1
grep -RPl --include=*.{php,txt} "(passthru|shell_exec|system|phpinfo|base64_decode|chmod|mkdir|fopen|fclose|readfile) *\(" /var/www/

 

Blindly grepping for potentially malicious strings such as “base64_decode” and “exec” was getting tired fast, as these can be legitimately used for some applications. I stumbled across reports that ClamAV works well for locating potential threats

Shell
1
nice -n 19 clamscan ./ -r -i | grep " FOUND" >> possible_exploits.txt

You can then review these files as you see fit, editing the file to remove ones that are false positives. I then run a command to delete the infected files:

1
while read f; do rm $f ; done<$possible_exploits.txt