People have a tendency to install and enable things that they do not fully understand. In this article I will try to explain just what Root and Xposed Bridge is and how dangerous it can be. Don't get me wrong, I love both of these things, but it is important to be careful and not grant just any application these types of rights.
Let's picture a small village. In the middle of this village is a large bank. It is surrounded with a lot of smaller buildings. The bank represents the core Android system while the buildings are all of the Applications. All the people within each building can communicate with one another since they are all within the same building. If a building needs to communicate with another building, it has to send someone across town to the other building. It is then up to the people in that building to decide whether or not they want to let that person inside. While inside, the person can make a request or a delivery. Maybe he wants to borrow some sugar. He then delivers the response (in this case the sugar) back to his building. The same applies for the bank which is surrounded by guards. To make a request for a specific item in the bank, a building will need a permission slip for that item in order to bypass the guard watching it.
One building however has an Xposed Module implemented. In this case it is a specific type of person, I spy if you will. The building can send this person over to the bank and make him act as a guard. The bank and it's other guards will not not sense that anything is wrong. This spy can now move around in any section of the bank without any permission slip. He can steel items, place new items or make changes to the existing once without anyone asking questions. He can also disguise himself as a member of other buildings and walk around those without an invite. This spy is essentially a god amongst men.
In Android it allows applications to provide features not normally available, like changing theme and colors in any part of the system, create security modules that can restrict other applications from gathering specific information and much more. But it also allows application to do things that you might not want it to, like gathering information and uploading it to a server. Since the module can do whatever it wants, there is no way to restrict it.
Root is similar. It is the main built-in Administrator in the Linux kernel (Which Android is built on top of). In this case it acts as the emperor of the village. It is the main authority in the system and no one would dare to tell it no. It can move, do and behave just as it feels like without no one trying to stop it. The most important thing to note here is that Xposed Modules is able to acts as root, even if the device is not rooted. It is also important to note that gaining root via Xposed Bridge will not trigger your normal Root Popup window on rooted devices. So you will not even know that this has happened.
There is no doubt that devices with Xposed Bridge and Root enabled are much more fun. This article is not meant to scare anyone from rooting their devices or install Xposed Bridge on them. It is meant to inform people about the danger of doing so to make them more aware next time they enable an Xposed module or grant root to an application asking for it. Make sure that the application in question can be trusted, which most importantly mean that you should not allow this for Closed Source applications. If the source codes are close, there is no telling what has been implemented into the application.
So the next time you think about enabling an application in Xposed Bridge or grant root to an application, do some research first. Make sure that you can find a link to the source codes, make sure that the developer is contactable, do some searches to make sure that others have not warned about this application.
In any case, do not just blindly enable whatever the application asks for.
Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts
Wednesday, May 27, 2015
Friday, August 23, 2013
Controlled Environment
You are building a library of some sort, and you want to have a primary class with additional "extender" classes which all should be accessed through your primary one. Why? Don't know, hopefully you do since your the one making it. However, what is to stop anyone from accessing your "extender" classes directly? You could add your "extender" classes as sub-classes to the primary and make your constructors private or protected. But if your planing on expanding this library a great deal, you will end up with a pretty large file at the end. And splitting your "extender" classes into single files with private and protected constructors will just ensure that not even your primary class will be able to create instances of them. So what's left? I know that some languages actually has a feature which allows you to lock a class and define whom has access to create an instance. I have not worked with Java for long, so I don't know whether or not this feature exists in Java. But there are other ways of doing this, which will actually work in other OOP capable languages as well.
The trick here is Data Types. This is something that Java is very strict about, which makes this so much easier. What you need to do, is have a small class that only your primary can create an instance from. The easiest way is to place this as a sub-class to the primary class. This small class will be used to parse along as an argument to a static method in each "extender" class, who’s job is to return an instance of themselves. Meanwhile we will keep each "extender" constructor private, so that no other can access it. And we will make each class final, so that they cannot be extended in order to bypass this protection.
This is our primary class:
This is one of our extenders:
In order to get an instance from MyExtender, you will need to parse through it's getInstance method. However, this method requires a MyTransport argument, which only the primary class can create. From the getInstance method, it will attach an instance of itself and then return the MyTransport object to the primary class. And by implementing MyDataType, you can use the same MyTransport class for any extender classes as they will all be able to be casted to the same data type.
That is all that there is to it. And like mentioned above, this can be used in any OOP language. In some however, you will need some manual checking of data types. PHP for an example does not really care about data types, so you will need to do a manual instanceOf check in the extender getInstance methods to make sure that the argument really is a MyTransport object. But that is not all that difficult to implement.
The trick here is Data Types. This is something that Java is very strict about, which makes this so much easier. What you need to do, is have a small class that only your primary can create an instance from. The easiest way is to place this as a sub-class to the primary class. This small class will be used to parse along as an argument to a static method in each "extender" class, who’s job is to return an instance of themselves. Meanwhile we will keep each "extender" constructor private, so that no other can access it. And we will make each class final, so that they cannot be extended in order to bypass this protection.
This is our primary class:
public final class MyPrimary {
public MyExtender extender(String param) {
MyTransport transport = new MyTransport();
transport.arguments = new Object[] { (Object) param };
return (MyExtender) MyExtender.getInstance( transport ).instance;
}
public final static interface MyDataType {}
public final static class MyTransport {
private MyTransport() {}
Object[] arguments;
MyDataType instance;
}
}
This is one of our extenders:
public final class MyExtender implements MyDataType {
public static MyTransport getInstance(MyTransport transport) {
transport.instance = (MyDataType) new MyExtender( (String) transport.arguments[0] );
return transport;
}
private MyExtender(String param) {
...
}
}
In order to get an instance from MyExtender, you will need to parse through it's getInstance method. However, this method requires a MyTransport argument, which only the primary class can create. From the getInstance method, it will attach an instance of itself and then return the MyTransport object to the primary class. And by implementing MyDataType, you can use the same MyTransport class for any extender classes as they will all be able to be casted to the same data type.
That is all that there is to it. And like mentioned above, this can be used in any OOP language. In some however, you will need some manual checking of data types. PHP for an example does not really care about data types, so you will need to do a manual instanceOf check in the extender getInstance methods to make sure that the argument really is a MyTransport object. But that is not all that difficult to implement.
Wednesday, May 8, 2013
Multiple Encrypted Disks with Linux
This is a fallow up to the parent guide, Full Disk Encryption with Linux. If you have not yet read it, then you are advised to do so before continuing with this one.
Encrypting you entire hard drive is great. But what if you like me, have more than one hard drive in your computer? One thing that is not great, is having to enter multiple passwords on each boot. Well, you don't have to.
The magic word here is Key File. It is a small file containing some random bytes which can be used as a key to unlock an encryption without using a password. An if you are a person that sucks at coming up with great passwords, it will in most cases be more secure than any password you would assign an encryption. The insecure part is how you store it.
In this guide, we will store this key on our primary encrypted hard drive. It will not be accessible until the first drive has been unlocked. We can then use it to unlock any additional drives that you may have attached to your computer, and get away with only having to type in one single password to unlock multiple drives.
You can skip this step if you already have an additional and fully encrypted hard drive, and just want to know how to assign a key to it.
Otherwise, let' wipe your drive.
Remember to change Y to the letter matching your additional drive.
Now let's partitioning this drive. We will just create one single partition which will hold the encryption. Also, we will not be using LVM in this guide as we do not need things like SWAP or an OS on it. We have this on the primary disk.
We will also need it unlocked in order to use it.
And last, creating a new file system inside the encryption.
You can use whatever file system or label that you wish.
Now we have an 4096bit key and it is only accessible by root, which means that it is quite secure even on a booted system.
In order to use this key, we need to assign it to the encryption.
Now the encryption can be unlocked by both the assigned password and this key.
We will also need to add the encryption and key to crypttab to let the boot loader know how to handle this. Open /etc/crypttab with a file editor and add the line below.
If you would like the partition to be mounted during boot, you will need to add it to fstab. Open the file /etc/fstab and add the line below.
Now we just need to rebuilt the kernel image, reboot and we are done.
You can redo this guide for as many disks as you like.
Encrypting you entire hard drive is great. But what if you like me, have more than one hard drive in your computer? One thing that is not great, is having to enter multiple passwords on each boot. Well, you don't have to.
The magic word here is Key File. It is a small file containing some random bytes which can be used as a key to unlock an encryption without using a password. An if you are a person that sucks at coming up with great passwords, it will in most cases be more secure than any password you would assign an encryption. The insecure part is how you store it.
In this guide, we will store this key on our primary encrypted hard drive. It will not be accessible until the first drive has been unlocked. We can then use it to unlock any additional drives that you may have attached to your computer, and get away with only having to type in one single password to unlock multiple drives.
Preparing the hard drive
You can skip this step if you already have an additional and fully encrypted hard drive, and just want to know how to assign a key to it.
Otherwise, let' wipe your drive.
shred -v /dev/sd<Y>
Remember to change Y to the letter matching your additional drive.
Now let's partitioning this drive. We will just create one single partition which will hold the encryption. Also, we will not be using LVM in this guide as we do not need things like SWAP or an OS on it. We have this on the primary disk.
cryptsetup -y --cipher aes-xts-plain --key-size 512 luksFormat /dev/sd<Y>
We will also need it unlocked in order to use it.
cryptsetup luksOpen /dev/sd<Y> <Enc_Name_Add>
And last, creating a new file system inside the encryption.
mkfs.ext4 -L Additional <Enc_Name_Add>
You can use whatever file system or label that you wish.
Creating the key
dd if=/dev/urandom of=/root/encryption.key bs=4096 count=1 chmod 0440 /root/encryption.key
Now we have an 4096bit key and it is only accessible by root, which means that it is quite secure even on a booted system.
Assigning the key
In order to use this key, we need to assign it to the encryption.
cryptsetup luksAddKey /dev/sd<Y> /root/encryption.key
Now the encryption can be unlocked by both the assigned password and this key.
Adding the encryption to crypttab
We will also need to add the encryption and key to crypttab to let the boot loader know how to handle this. Open /etc/crypttab with a file editor and add the line below.
<Enc_Name_Add> /dev/sd<Y> /root/encryption.key luks
Adding the unlocked partition to fstab
If you would like the partition to be mounted during boot, you will need to add it to fstab. Open the file /etc/fstab and add the line below.
/dev/mapper/<Enc_Name_Add> /media/additional ext4 defaults 0 2
Update grub and boot loader
Now we just need to rebuilt the kernel image, reboot and we are done.
update-grub update-initramfs -u
You can redo this guide for as many disks as you like.
Full Disk Encryption with Linux
A great thing about Linux, is the built-in subsystem DMCrypt, which, with some help from the brilliant Initrd, allows you to make a full disk encryption, including the root partition (Boot excluded of cause) and have it unlocked by a key file or password during boot, all without any third party software. This guide will show you how to encrypt your entire hard drive and set up your computer to unlock it on each boot using a password.
What is even better, is Logical Volume Manager. This will allow us to create partitions inside a partition, which means that we only need to encrypt one partition on the hard drive, and then create whatever volumes we need, inside that single encrypted partition.
Because Ubuntu is the most used distro of all the available once, this guide will use this for the examples. But it should be easy enough to incorporate this guide into other distro's as well, especially since this guide will be using a terminal to do all of the work, and the shell is mostly the same across all distro's.
Before we can continue, you need to download Ubuntu (Or any distro of your choice), and create a live CD or USB Pen. Then boot up the live system, and once in the UI, press Ctrl+Alt+F1 to enter a terminal.
This guide will assume that you know your way around Linux. So we will not cover anything about creating live disks or how the shell works. You can google it if you don't already know. This is all about the encryption part.
The first thing to do, is erasing any existing data on the hard drive and replacing it with random bytes. Even though the hard drive will be encrypted, attachers will still be able to see which part of the drive contains any data. This allows them to focus on that specific part of the drive, and making it much easier cracking it. By placing random bytes across the whole drive, we hide the real data which makes it much harder to determinant which parts of the drive contains anything worth cracking.
Remember to replace X with the letter matching your drive.
Next we need to create a new partitioning table. By wiping the drive, the existing table was erased along with the rest of the content. Use fdisk, or another partition manager, to create the table below.
Now we create the encryption on /dev/sd<X>5. This is the partition that will store our logical volumes.
After you have typed in the password that you wish to use, we need to unlock the encryption in order to use it.
The Enc_Name is the name that will be used for the device map. It will create /dev/mapper/<Enc_Name> which is the entry point (door if you will) to the device behind the encryption. Just replace Enc_Name with the name that you wish to use.
In this guide, we will be creating 3 volumes. 1 for SWAP, one for root and one for home. You can of cause create whatever you need or want.
Before we can create the volumes, we need to initiate our encrypted volume for LVM and create the volume group that will store the volumes.
Replace Vg_Name with the name that you wish for your volume group.
Now we are ready to create the actual volumes.
We now have 3 new devices
It is now time to get the OS installed. Press Ctrl+Alt+F7 to get back into the live system UI and select install. Once you get to the partitioning part, select manual. Now assign appropriate mount points to the 3 logical volumes that we created before and use /dev/sd<X>1 as boot. Continue the installation. Once done, do NOT reboot, instead press Ctrl+Alt+F1 again to get back into the terminal.
Now that we have the OS installed, we need to make some changes to it, but before we can do that, we need for it to act as the main OS. In other words, we need some help from chroot.
You should now have entered a new apparent root directory and we are ready to make changes to the OS that you have just installed.
The first thing that we need to do here, is edit/create /etc/crypttab. This is a file which will tell the boot loader how to handle the encrypted partition, or more accurate, it will tell the system how initrd should be structured once we rebuild it.
Open /etc/crypttab with a file editor like nano, and append the content below.
This will tell the boot loader that /dev/sd<X>5 contains a luks encrypted partition, which should be decrypted to the device map <Enc_Name>. The none part is where we could have assigned a key file, without it, a password prompt will be used instead.
The second thing to do, is have some specific modules loaded on boot, which are needed to unlock the partition.
Open the file /etc/initramfs-tools/modules
And last, we regenerate initrd
Reboot your computer. During boot, you will be prompted to enter a password. Enter the password and your hard drive will decrypted and the computer will continue it's regular boot.
Next time you need to upgrade or for other reasons reinstall your OS, all you have to do, is decrypt/unlock the encrypted partition and then fallow this guide from the parts after the installation of the OS. Everything above that is a one time thing.
What is even better, is Logical Volume Manager. This will allow us to create partitions inside a partition, which means that we only need to encrypt one partition on the hard drive, and then create whatever volumes we need, inside that single encrypted partition.
Because Ubuntu is the most used distro of all the available once, this guide will use this for the examples. But it should be easy enough to incorporate this guide into other distro's as well, especially since this guide will be using a terminal to do all of the work, and the shell is mostly the same across all distro's.
Before we can continue, you need to download Ubuntu (Or any distro of your choice), and create a live CD or USB Pen. Then boot up the live system, and once in the UI, press Ctrl+Alt+F1 to enter a terminal.
This guide will assume that you know your way around Linux. So we will not cover anything about creating live disks or how the shell works. You can google it if you don't already know. This is all about the encryption part.
Erasing the hard drive
The first thing to do, is erasing any existing data on the hard drive and replacing it with random bytes. Even though the hard drive will be encrypted, attachers will still be able to see which part of the drive contains any data. This allows them to focus on that specific part of the drive, and making it much easier cracking it. By placing random bytes across the whole drive, we hide the real data which makes it much harder to determinant which parts of the drive contains anything worth cracking.
shred -v /dev/sd<X>
Remember to replace X with the letter matching your drive.
Preparing the hard drive
Next we need to create a new partitioning table. By wiping the drive, the existing table was erased along with the rest of the content. Use fdisk, or another partition manager, to create the table below.
| Device | Type | Size |
| /dev/sd<X>1 | Primary | 1GB |
| /dev/sd<X>2 | Extended | Everything |
| /dev/sd<X>5 | Logical | Everything |
Creating the encryption
Now we create the encryption on /dev/sd<X>5. This is the partition that will store our logical volumes.
cryptsetup -y --cipher aes-xts-plain --key-size 512 luksFormat /dev/sd<X>
After you have typed in the password that you wish to use, we need to unlock the encryption in order to use it.
cryptsetup luksOpen /dev/sd<X> <Enc_Name>
The Enc_Name is the name that will be used for the device map. It will create /dev/mapper/<Enc_Name> which is the entry point (door if you will) to the device behind the encryption. Just replace Enc_Name with the name that you wish to use.
Creating the LVM volumes
In this guide, we will be creating 3 volumes. 1 for SWAP, one for root and one for home. You can of cause create whatever you need or want.
Before we can create the volumes, we need to initiate our encrypted volume for LVM and create the volume group that will store the volumes.
pvcreate /dev/mapper/<Enc_Name> vgcreate <Vg_Name> /dev/mapper/<Enc_Name>
Replace Vg_Name with the name that you wish for your volume group.
Now we are ready to create the actual volumes.
lvcreate -n swap -L 6G <Vg_Name> lvcreate -n system -L 25G <Vg_Name> lvcreate -n home -l 100%FREE <Vg_Name>
We now have 3 new devices
- /dev/mapper/<Vg_Name>-swap
- /dev/mapper/<Vg_Name>-system
- /dev/mapper/<Vg_Name>-home
Installing the OS
It is now time to get the OS installed. Press Ctrl+Alt+F7 to get back into the live system UI and select install. Once you get to the partitioning part, select manual. Now assign appropriate mount points to the 3 logical volumes that we created before and use /dev/sd<X>1 as boot. Continue the installation. Once done, do NOT reboot, instead press Ctrl+Alt+F1 again to get back into the terminal.
Set up chroot
Now that we have the OS installed, we need to make some changes to it, but before we can do that, we need for it to act as the main OS. In other words, we need some help from chroot.
mkdir /mnt/system mount /dev/mapper/<Enc_Name>-system /mnt/system mount /dev/sd<X>1 /mnt/system/boot mount --rbind /dev /mnt/system/dev mount --rbind /sys /mnt/system/sys mount --rbind /proc /mnt/system/proc chroot /mnt/system
You should now have entered a new apparent root directory and we are ready to make changes to the OS that you have just installed.
Set up crypttab
The first thing that we need to do here, is edit/create /etc/crypttab. This is a file which will tell the boot loader how to handle the encrypted partition, or more accurate, it will tell the system how initrd should be structured once we rebuild it.
Open /etc/crypttab with a file editor like nano, and append the content below.
<Enc_Name> /dev/sd<X>5 none luks,retry=1
This will tell the boot loader that /dev/sd<X>5 contains a luks encrypted partition, which should be decrypted to the device map <Enc_Name>. The none part is where we could have assigned a key file, without it, a password prompt will be used instead.
Loading modules
The second thing to do, is have some specific modules loaded on boot, which are needed to unlock the partition.
Open the file /etc/initramfs-tools/modules
dm-crypt aes-x86_64 (aes-i586 is you are using 32bit) xts sha256_generic sha512_generic ahci
Recompiling kernel image
And last, we regenerate initrd
update-initramfs -u
Reboot your computer. During boot, you will be prompted to enter a password. Enter the password and your hard drive will decrypted and the computer will continue it's regular boot.
Next time you need to upgrade or for other reasons reinstall your OS, all you have to do, is decrypt/unlock the encrypted partition and then fallow this guide from the parts after the installation of the OS. Everything above that is a one time thing.
Subscribe to:
Posts (Atom)