Suramya's Blog : Welcome to my crazy life…

January 28, 2022

IoT Devices and Reducing their Impact on Enterprise Security

IoT devices are becoming more and more prevalent in the corporate world, as they allow us to automate tasks and activities without manual intervention, which increases the risk to the organization by increasing the attack surface available to attackers. This is because IoT devices can act as entry points to the organization’s internal network. In order to reduce the security impact of these devices the attack channels and threats from the devices need to be mitigated. This can be done by implementing the suggestions in this paper

IoT or Internet of Things is a collection of devices that are connected to the internet and can be controlled over a network or provide data over the internet. It is one of the fastest growing markets, with enterprise IoT spending growing by 24% in 2021 from $128.9 billion. (IoT Analytics, 2021). This massive growth brings new challenges to the table as administrators need to secure IoT devices in their network to prevent them from being security threats to the network.

IoT devices allow us to manage, monitor and control devices and sensors remotely which in turn allows us to automate tasks and activities without manual intervention. But this capacity comes at an increased risk of vulnerability due to a massive increase of the attack surface available. They are becoming more and more prevalent in an enterprise setting, especially in the office automation and operational technology areas. This increases the risk to the organization by increasing the possibility of threats in areas that traditionally don’t pose cyber security risks.

IoT devices can act as entry points to an organizations internal network and be used to exfiltrate data from the network without raising flags. In 2018, attackers used a compromised IoT thermometer in the lobby aquarium of a casino to breach their system and exfiltrate their high-roller database (~10GB of data) out of the corporate network to servers they controlled via the thermostat. (Williams-Grut, 2018).

In this paper we will review some of the major threats and attack channels targeting IoT devices and look at how we can reduce the impact of these threats on the enterprise security.

IoT Threats and Attack Channels

IoT devices have multiple attack surfaces due to their design and usage. We will cover the major vulnerabilities in this section along with mitigation steps for each threat and attack channel.

A. Physical Vulnerabilities

Since these devices are usually physically deployed in the field in addition to the typical software and communication vulnerabilities, they are also vulnerable to physical attacks where the device can be physically modified to gain access. Some of the examples of Physical attacks are as follows:

  • Attackers physically remove the device memory or flash chips to read & analyze the data and software on the chip.
  • Attackers tamper with the microcontroller to gain access to or identify sensitive information
  • Physically modify the device to return incorrect data or telemetry. For example, camera’s or motion sensors overseeing sensitive locations could be modified to ignore breaches.
  • Use the device connectivity to act as a bridge to gain access to the corporate network.
  • Attackers authenticate locally to the device using debug interface on the device to gain access to the device internals

The best way to protect against such attacks is to ensure the following preventive measures are taken for all devices on the network:

  • Ensure that the device or sensor is not easily accessible physically.
  • All sensors and devices should have tamper proof seals installed on them with regular checks to verify that they are not tampered with.
  • Unused ports, connections, diagnostic connectors etc should be physically disabled when possible.
  • If possible, ensure the devices have hardware-based security checks on it.

B. Outdated Firmware

Many of the IoT devices and sensors run older versions of Linux with no easy way to update the firmware, installed software or applications to the latest versions. This creates a major security risk as the device is running software with known security vulnerabilities which allows attackers to easily compromise a device.

There is no easy way to resolve this problem and protect the devices as a lot of these sensors and devices are not designed with security in mind. The best way to approach this problem is to ensure you are working with reputable device manufacturers who will ensure that appropriate support and updates are going to be available for the device/sensor.

The organization should review the recommendations by the IoT working group of the Cloud Security alliance on how to perform IoT Firmware updates securely and regularly. (Khemissa et al., 2018) The should also include the IoT sensors and devices in the organization’s update cycles which will allow them to ensure that patches and updates are installed in a timely manner on them.

Another option is to explore installing open source firmware and software on the IoT device/sensor if this option is available. The opensource firmware’s are usually updated more frequently and can be customized to better secure the device.

C. Hard Coded Passwords/Accounts

Some of the IoT devices have hard coded account passwords that cannot be changed, and this gives an attacker backdoor access to the device that is difficult to protect against. Hardcoded passwords are particularly dangerous because they are easy targets for password guessing exploits, allowing attackers to hijack firmware, devices, systems, and software etc. A famous case of such an exploit was found in 2017 when researchers found default hardcoded passwords in IoT camera’s manufactured by Foscam. (Heller, 2017) that gave admin access to anyone who used them. These passwords allow an attacker to gain access to the device and use it as a launch surface against attacks on the network.

Another famous attack exploiting this was by the Mirai malware in 2016. It scanned for and exploited Linux-based IoT boxes with Busybox (such as DVRs and WebIP Cameras) using hardcoded usernames and passwords. Once it gained access these devices were enrolled in a botnet containing over 400,000 connected devices which were then used to perform DDoS attacks on major companies across the world. (Fruhlinger, 2018)

To protect against these attacks, we should ensure the default passwords on all devices are changed frequently. An active pentest against the device should be conducted to uncover any hidden or hardcoded accounts. If any are found, the manufacturer should be contacted to prove an update to disable these accounts.

D. Poor IoT device management

A study published in July 2020 found that almost 15% of IoT devices on an enterprise network were unknown or unauthorized and between 5 to 19% of these devices were using unsupported legacy operating systems (Help Net Security, 2020). These devices make up what is known as a Shadow IoT network that is implemented without the knowledge of the organization’s IT team and can be a major weak point in the organization’s security perimeter.

The best way to protect against this scenario is to ensure regular scans are done on the network to identify any unknown or new devices connected to the network. The pentest will enable us to identify these unauthorized devices which can then be incorporated into the official network and update cycle or disconnected depending the requirements. Another way to find these unauthorized devices is to monitor and analyze network connections and traffic. New devices will change the network data flow, and this can be used to identify or locate new devices or sensors connected to the network.

E. Man-in-the-Middle Attacks

Communication channels in IoT devices are usually very trivially protected and an attacker can compromise the channel to intercept the messages between devices and modify them. This allows the attacker to cause malfunctions or show incorrect data. This can potentially cause serious harm if the targeted IoT devices are connected to or managing industrial or medical equipment. It can also allow attackers to hide their tracks and physical evidence of their work.

F. Industrial Espionage & Eavesdropping

IoT devices such as cameras, microphones etc are used to monitor sensitive areas or devices for problems remotely. If an attacker compromises these cameras, they allow them to visually and audially monitor their target compromising their privacy and potentially gaining access to sensitive data or video. For example, IoT cameras deployed in bedrooms have been used to record and leak intimate videos of the residents without their knowledge. Compromised security cameras have been used to record ATM pins entered by unsuspecting users.

Other steps that should be taken to reduce risk from IoT devices on your network:

  • Segregate your Networks: IoT devices should be on a separate segment of the network which is isolated from the production and user network with a firewall sitting between the two. This will allow you to block access to the production network from the IoT network which will prevent an attacker from gaining full access to the enterprise network in case they breach the IoT network.
  • Enable HTTPS/Encrypted connectivity for IoT devices: All connections to and from the IoT devices should be encrypted to protect against Man-in-the-middle attacks.
  • Deploy an IDS: Deploying an Intrusion Detection System (IDS) on the network can alert us to attack attempts. All alerts from the IDS should be investigated and verified.

These are just some of the attack surfaces available to attackers targeting IoT devices, in fact with the increase in computing power available to these devices they are almost mini computers and most of the attacks that impact traditional systems such as servers or desktops can target IoT devices as well with minimal modifications. So, it is essential that security trainings are conducted for all employees in the organization to make them aware of the risks posed by IoT devices and train the security team in methods to secure these devices from attackers.


Note: This was originally written as a paper for one of my classes at EC-Council University in Q3 2021, which is why the tone is a lot more formal than my regular posts.

– Suramya

September 17, 2020

How HTTPS Works? Explained in a comic!

Filed under: Computer Security,Security Tutorials,Tech Related — Suramya @ 10:41 AM

Found a fantastic explanation of HTTPS works, what is SSL/TLS & why you should care about any of it in a easy to understand comic format. I love seeing comics like this that aim to show concepts in simple ways.

Have you ever wondered why a green lock icon appears on your browser URL bar? And why is it important? We did too, and this comic is for you!
Follow the adventures of Certificat, Browserbird, and Compugter as they explain why HTTPS is crucial for the future of the web and how it all works together.
Don’t let the bad crabs get you (you’ll know what we mean in the comic). Get to know HTTPS and why it is essential to your privacy.

Check it out at: howhttps.works

– Suramya

February 13, 2018

Explaining HTTPS using carrier pigeons

Filed under: Interesting Sites,Security Tutorials,Tech Related — Suramya @ 7:07 PM

HTTPS is something that a lot of people find hard to explain without going into a lot of technical jargon which frankly just confuses most people and causes them to zone out. However it is an essential service/protocol so understanding it is a good idea. To address this issue Andrea Zanin who is a student created the following primer that explains how HTTPS works using carrier pigeons as the messengers.

Below is an explanation on how HTTP would work with carrier pigeons:

If Alice wants to send a message to Bob, she attaches the message on the carrier pigeon’s leg and sends it to Bob. Bob receives the message, reads it and it’s all is good.

But what if Mallory intercepted Alice’s pigeon in flight and changed the message? Bob would have no way of knowing that the message that was sent by Alice was modified in transit.

This is how HTTP works. Pretty scary right? I wouldn’t send my bank credentials over HTTP and neither should you.

Check out the link for the full writeup.

Well, this is all for now. Will write more later.

– Suramya

February 7, 2018

Hacking the Brainwaves Cyber Security CTF Hackathon 2018

Earlier this year I took part in the Brainwaves Cyber Security Hackathon 2018 with Disha Agarwala and it was a great experience. We both learnt a lot from the hackathon and in this post I will talk about how we approached the problems and some of our learning’s from the session.

Questions we had to answer/solve in the Hackathon:

  • Find the Webserver’s version and the Operating system on the box
  • Find what processes are running on the server?
  • What fuzzy port is the SSH server running on?
  • Discover the site architecture and layout.
  • Describe the major vulnerability in the home page of the given website based on OWASP TOP 1. Portal Url: https://socgen-ctf.0x10.info
  • Gain access to member area and admin area through blind sql, or session management.
  • Dump all user account from member area. [SQLi]
  • [Broken Validation] Demonstrate how you can modify the limit in order management.
  • [Open Redirect] Redirect site/page to hackerearth.com
  • List any other common bug came across while on the site
    • After logging into the member area, perform the following functions:
    • Find the master hash & crack it
    • Dump all user’s
    • Find the email ID and password of saved users

Information Gathering:

In order to find the services running on the server, the first thing we had to do was find the IP/hostname of the actual server hosting the site which was a bit tricky because the URL provided is protected by CloudFlare. So, any scans of socgen-ctf.0x10.info took us to the CloudFlare proxy server instead of the actual server which was a problem.

We figured this out by trying to access the IP address that socgen-ctf.0x10.info translated to in the browser.

suramya@gallifrey:~$ host socgen-ctf.0x10.info 
socgen-ctf.0x10.info has address 104.28.15.64 

Since the site homepage didn’t do anything except display text that refreshed every 15 seconds we needed to find other pages in the site to give us an a attack surface. We checked to see if the site had a robots.txt (It tells web crawlers not to index certain directories). These directories are usually ones that have sensitive data and in this case the file existed with the following contents:

# robots.txt
Sitemap: http://socgen-ctf.0x10.info/sitemap.xml
User-agent: *
Disallow: images
Disallow: /common/
Disallow: /cgi-bin/

The images directory didn’t have any interesting files in it but the /common/ directory on the other hand had a file named embed.php in it which basically ran a PHP Info dump. This dump has a lot of information that can be used to attack the site but the main item we found here was the IP address of the actual server where the services were running (38.109.218.93).

Using this information we were able to initiate a nmap scan to get the services running on the site. The nmap command that gave us all the information we needed was:

nmap -sV -O -sS -T4 -p 1-65535 -v 38.109.218.93

This gave us the following result set after a really really long run time:

PORT     STATE    SERVICE       VERSION
23/tcp   filtered telnet
25/tcp   open     smtp?
80/tcp   open     http          This is not* a web server, look for ssh banner
81/tcp   open     http          nginx 1.4.6 (Ubuntu)
82/tcp   open     http          nginx 1.4.6 (Ubuntu)
137/tcp  filtered netbios-ns
138/tcp  filtered netbios-dgm
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
497/tcp  filtered retrospect
1024/tcp open     kdm?
1720/tcp open     h323q931?
2220/tcp open     ssh           OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8 (Ubuntu Linux; protocol 2.0)
2376/tcp open     ssl/docker?
3380/tcp open     sns-channels?
3389/tcp open     ms-wbt-server xrdp
5060/tcp filtered sip
5554/tcp filtered sgi-esphttp
8000/tcp open     http          nginx 1.4.6 (Ubuntu)
8080/tcp open     http          Jetty 9.4.z-SNAPSHOT
8086/tcp open     http          nginx 1.10.3 (Ubuntu)
9090/tcp open     http          Transmission BitTorrent management httpd (unauthorized)
9996/tcp filtered palace-5
19733/tcp filtered unknown
25222/tcp filtered unknown
30316/tcp filtered unknown
33389/tcp open     ms-wbt-server xrdp
33465/tcp filtered unknown
34532/tcp filtered unknown
35761/tcp filtered unknown
35812/tcp filtered unknown
35951/tcp filtered unknown
37679/tcp filtered unknown
38289/tcp filtered unknown
38405/tcp filtered unknown
38995/tcp filtered unknown
40314/tcp filtered unknown
44194/tcp filtered unknown
47808/tcp filtered bacnet

For some reason the results from the nmap scan varied so we had to run the scan multiple times to get all the services on the host. This was possibility because the server was setup to make automated scanning more difficult.

Once we identified the port where the SSH server was running on (2220) we were able to connect to the port and that gave us the exact OS Details of the server. We did already know that the server was running Ubuntu along with the kernel version from the PHP Info dump but this gave us the exact version.

Discovering Site architecture:

Since we had to discover the URL to the members & admin area before we could attack it, we used dirb which is a Web Content Scanner to get the list ofall the public directories/files on the site. This gave us the URL’s to several interesting files and directories. One of the files identified by dirb was https://socgen-ctf.0x10.info/sitemap.xml. When we visited the link it gave us a list of other URL’s on the site of interest (we had to replace the hostname to socgen-ctf.0x10.info) including the members area (http://socgen-ctf.0x10.info/members.php?p=login) and siteadmin (http://socgen-ctf.0x10.info/siteadmin).

After a long and fruitless effort to use SQL Injection on the siteadmin area we started to explore the other files/URL’s identified by dirb. This gave us a whole bunch of files/data that seem to be left over from other hackathons so we ignored them.

SQL Injection

The main site https://socgen-ctf.0x10.info/index.php?p=. appeared to be vulnerable to SQL at the first glance because when we visit https://socgen-ctf.0x10.info/index.php?p=.’ (note the trailing single quote) it reloads the page. This meant that we could write queries to it however since it didn’t display a true or false on the page a SQL injection wasn’t easily possible. (We could have tried a blind injection but that would require a lot of effort for a non-guaranteed result.

As we explored the remaining URL’s in sitemap.xml one of the links (https://socgen-ctf.0x10.info/embedframe.php) was interesting as it appeared to give a dump of data being read from the site DB. Opening the site while watching the Developer Toolbar for network traffic identified a URL that appeared to be vulnerable to SQL injection (https://socgen-ctf.0x10.info/ajax.php?cid=&p=view_channel&id=28) and once we tested the url we found that the variable id was indeed vulnerable to injection.

We used blind sql to gain access by executing true and false statements and see that it returns different results for true(displays ‘1’ on the webpage) and false (displays 0) . We checked whether a UNION query runs on the site which it did and using other queries we identified the DB backend to be a mysql database (5.xx.xxx version). Then we found out the table name (members) which was an easy guess since the website had an add customer field. After identifying the number of columns in the table we got stuck because any statements to list the available tables or extract data were failing with an error about inconsistent column numbers.

Finally, we ran sqlmap which is an open source tool for automating SQL injection. It took us a few tries to get the software running because initially any attempt to scan the site was rejected with a 403 error message. Turns out that the connections were being rejected because the site didn’t like the useragent the software was sending by default and adding a flag to randomize the useragent resolved the permission denied issue.

Once the scan ran successfully we tried to get access to the MySQL usertable but that failed because the user we were authenticating as to the MySQL server didn’t have access to the table required.

sqlmap -u 'https://socgen-ctf.0x10.info/ajax.php?cid=&p=view_channel&id=28' --random-agent -p id --passwords

So, then we tried getting an interactive shell and an OOB shell both of which failed. We finally ran the command to do a full dump of everything that the system allowed us to export using SQL injection via SQLMap. This included the DB schema, table schema’s and a dump of every table on the database server which the mysql user had access to. The command we used is the following:

sqlmap -u 'https://socgen-ctf.0x10.info/ajax.php?cid=&p=view_channel&id=28' --random-agent -p id  --all --threads 3

This gave us a full dump of all the tables and the software was helpful enough to identify password hashes when they existed in the table and offered to attempt decryption as well. In this case the password was encrypted with a basic unsalted MD5 hash which was cracked quite easily. Giving us the password for the first two accounts in the database (admin & demo).

Looking at the rest of the entries in the users table we noticed that they all had funny values in the email address field, instead of a regular email address we had entries that looked like the following:

,,,"0000-00-00 00:00:[email protected]509a6f75849b",1
,1,RU,

As we had no clue what this was about the first thing we attempted was to access the
https://socgen-ctf.0x10.info/cdn-cgi/l/email-protection URL. This URL gave us a message that told us that the email addresses in the DB were obfuscated by CloudFlare to protect them from Bots. A quick Google search gave us a 21 line python script which we tweaked to convert all the hash to email address and passwords. (The code is listed below for reference)

#! /usr/bin/env python 
# -*- coding: utf-8 -*- 
# vim:fenc=utf-8 
# 
# Copyright © 2016 xl7dev  
# Distributed under terms of the MIT license. 

""" 

""" 
import sys 
import re 
fp = sys.argv[1] 
def deCFEmail(): 
   r = int(fp[:2],16) 
   email = ''.join([chr(int(fp[i:i+2], 16) ^ r) for i in range(2, len(fp), 2)]) 
   print email 
if __name__ == "__main__":                                                                                                                                                                       
   deCFEmail() 

This gave us the email addresses and passwords for all the users on the site. Since the accounts appeared to be created by SQL injection a bunch of them didn’t have any passwords but the remaining were valid accounts for the most part and we verified a couple by logging in manually with the credentials.

OWASP TOP 10 Vulnerability

To find the vulnerabilities in the home page we tried various manual techniques at first but drew a blank so we decided to use the owasp-zap. This tool allows you to automatically scan for vulnerabilities in a given URL along with a whole other stuff.

At first the scan failed because of the same issue as earlier with the user-agent. This time we took a different approach to resolve the issue by configuring owasp-zap as a proxy server and configuring Firefox traffic to use this proxy server for all traffic. This gave us the site in the software and we were then able to trigger both an active scan and spider scan of the site.

This gave us detailed reports that highlighted various issues in the site which we submitted.

Redirecting HomePage

The redirection of the home page was quite simple. We tried inserting a customer name with javascript tags in it and were able to do so successfully. So we inserted the following into the DB and the system automatically redirected the page when the Customer list section was accessed.

Other Interesting Finds

The nmap scan told us that in addition to port 80 a web server was listening on ports 81, 82, 8000, 8080 and 8086.

Ports 82, 8000 and 8086 were running standard installs of nginx and we didn’t find much of interest at these ports even after we ran dirb on all of them. Port 8080 appeared to be running a proxy or a Jenkins instance.

Port 81 was the most interesting because it was running a nginx server that responded to any queries with a 403 error. When we tried accessing the site via the browser we got an error about corrupted content.

We were unable to identify what the purpose of this site was but it was interesting.

SSH Banner / PHP Shell

The webserver instance running on port 80 had the version set to the following text “This is not* a web server, look for ssh banner Server at private-tunel.wehostservers.ru Port 80” so we went back and investigated the SSH Banner from the ssh server on port 2220. The banner was encrypted and to decrypt the SSH banner, we continuously converted the cipherText from its hex value to ASCII value . It gave us the following results on each conversion

3333333733333333333333373333333333333336333333383333333233333330333333363333333233333336333333313333333633363335333333363336333533333336333333353
3333337333333323333333233333330333333363333333633333336333633363333333733333332333333373333333733333336333333313333333733333332333333363333333433333332333333303333
3337333333333333333633363333333333363333333133333337333333333333333633333338333333323333333033333336333333333333333633363336333333373333333533333336333633333333333
63333333433333332333333303333333633363333333333363333333533333336333333313333333633333334333733393336363633373335373436663230363132307368336c6c2e706870

3337333333373333333633383332333033363332333633313336363533363635333633353337333233323330333633363336363633373332333733373336333133373332333633343332333033373333333
636333336333133373333333633383332333033363333333636363337333533363633333633343332333033363633333633353336333133363334373936663735746f206120sh3ll.php
 37333733363832303632363136653665363537323230363636663732373736313732363432303733366336313733363832303633366637353663363432303663363536313634796f75to a #

ssh banner forward slash could lead you to a #sh3ll.php

Once we got the full decrypted text we knew that there was a potential webshell on the server but it wasn’t apparent where the shell was located. After hit and try failed we turned back to our old faithful dirb to see if it could find the shell.

dirb allows us to specify a custom word list which is used to iterate through the paths and we can also append an extension to each of the words to search for, so we created a file called test with the following content:

suramya@gallifrey:~$ cat test 
shell
sh3ll
sh311

and then ran the following command:

suramya@gallifrey:~$ dirb https://socgen-ctf.0x10.info/ test  -X '.php'

This gave us the location of the shell.


Accessing the link gave us a page with a message “you found a shell, try pinging google via sh3ll.php?exec=ping 8.8.8.8”

Accessing the URL with the additional parameter gave us a page with the following output:

February 20, 2016

How to encrypt your Hard-drive in Linux

We have heard multiple stories where someone looses a pendrive or a laptop containing sensitive/private data which is then published by the person who found the drive embarrassing the owner of the data. The best way to prevent something like that from happening to you if you loose a disk is to make sure all your data is encrypted. Historically this used to be quite painful to setup and required a lost of technical know-how. Thankfully this is no longer the case. After trying a bunch of different options I found Linux Unified Key Setup-on-disk-format (LUKS) to be the most user-friendly and easy to setup option for me.

Setting it up is quite easy by following the instructions over at www.cyberciti.biz. However since things on the internet have a tendency of disappearing on a fairly frequent basis, I am using this post to save a paraphrased version of the installation instructions (along with my notes/comments) just in case the original site goes down and I need to reinstall. All credit goes to original author. So without further ado here we go:

Install cryptsetup

First we need to install cryptsetup utility which contains all the utilities we need to encrypt our drive. To install it in Debian/Ubuntu you just issue the following command as root:

apt-get install cryptsetup

Configure LUKS partition

Warning: This will remove all data on the partition that you are encrypting. So make sure you have a working backup before proceeding amd don’t blame me if you manage to destroy your data/device.

Run the following command as root to start the encryption process:

cryptsetup -y -v luksFormat <device>

where <device> is the partition we want to encrypt (e.g. /dev/sda1). The command will ask you for confirmation and a passphrase. This passphrase is not recoverable so make sure you don’t forget it.

Create drive mapping

Once the previous command completes you need to create a mapping of the encrypted drive by issuing the following command:

cryptsetup luksOpen <device> backup2

You can also map a partition to using its UUID (which is what I do) by issuing the following command instead (This works great if you want to script automated backups to an external drive):

cryptsetup luksOpen UUID=88848060-fab7-4e9e-bac2-f9a2323c7c29 backup2

Replace the UUID in the example with the UUID of your drive. (Instructions on how to find the UUID are available here).

Use the following command to see the status for the mapping and to check if the command succeeded:

cryptsetup -v status backup2

Format LUKS partition

Now that we have created the mapping we need to write zeroes to the encrypted device, to ensure that the outside world sees this as random data and protects the system against disclosure of usage by issuing the following command:

dd if=/dev/zero of=/dev/mapper/backup2

Since this command can take a long time to complete depending on the drive size and dd by default doesn’t give any feedback on the percentage completed/remaining I recommend that you use the pv command to monitor the progress by issuing the following command instead:

pv -tpreb /dev/zero | dd of=/dev/mapper/backup2 bs=128M

This will take a while to run so you can go for a walk or read a book while it runs. Once the command completes you can create a filesystem on the device (I prefer to use ext4 but you can use any filesystem you like) by formatting the device:

mkfs.ext4 /dev/mapper/backup2

After the filesystem is created you can mount and use the partition as usual by issuing the following command:

mount /dev/mapper/backup2 /mnt/backup

That’s it. You now have an encrypted partition that shows up as a regular partition in Linux which you can use as a regular drive without having to worry about anything. No special changes are needed to use this partition which means any software can use it without requiring changes.

How to unmount and secure the data

After you are done transferring data to/from the drive you can unmount and secure the partition by issuing the following commands as root:

umount /mnt/backup

followed by

cryptsetup luksClose backup2

Creating a backup of the LUKS headers

Before you start anything else, you should create a backup copy of the LUKS header because if this header gets corrupted somehow then all data in the encrypted partition is lost forever with no way to recover it. From the cryptsetup man page:

“LUKS header: If the header of a LUKS volume gets damaged, all data is permanently lost unless you have a header-backup. If a key-slot is damaged, it can only be restored from a header-backup or if another active key-slot with known passphrase is undamaged. Damaging the LUKS header is something people manage to do with surprising frequency. This risk is the result of a trade-off between security and safety, as LUKS is designed for fast and secure wiping by just overwriting header and key-slot area.”

Create a backup by issuing the following command:

cryptsetup luksHeaderBackup <device> --header-backup-file <file>

Important note: a LUKS header backup can grant access to most or all data, therefore you need to make sure that nobody has access to it.

In case of disaster where our LUKS header gets broken, we can restore it by issuing the following command:

cryptsetup luksHeaderRestore <device> --header-backup-file <file>

How to remount the encrypted partition?

Issue the following commands in sequence to mount the partition:

cryptsetup luksOpen <device> backup2
mount /dev/mapper/backup2 /mnt/backup

Please note that data encrypted by LUKS is quite obvious with most Linux systems identifying it as an encrypted partition automatically. So if someone examines your system they will know you have encrypted data and can force you to divulge the password by various means (including the use of Rubber-hose Cryptanalysis. )

If you want the encrypted partition to be hidden then you can use Deniable encryption/Hidden Partition or use steganography. I haven’t really used either so can’t comment on how to set it up correctly but maybe I can talk about it in a future post after I explore them a bit more.

Well this is all for now, hope you find this useful. Will write more later.

– Suramya

November 7, 2014

Free Intro to Cryptography course for programmers

Filed under: Computer Security,Security Tutorials,Tech Related — Suramya @ 1:34 AM

Security pro Laurens Van Houtven has created a free introduction cryptography course to help programmers, by giving them a bird’s eye view of how cryptosystems work and teaching them to apply the same principles in real software. This is an extension of his talk given last year on breaking crypto.

Comes with everything you need to understand complete systems such as SSL/TLS: block ciphers, stream ciphers, hash functions, message authentication codes, public key encryption, key agreement protocols, and signature algorithms.

Learn how to exploit common cryptographic flaws, armed with nothing but a little time and your favorite programming language.

Forge administrator cookies, recover passwords, and even backdoor your own random number generator.

Check it out at: Crypto 101

Thanks to The Register for the link to this great resource.

– Suramya

October 12, 2014

Take Orders From A Cat And Learn Cybersecurity

Here’s an interesting site that teaches Cybersecurity to folks in the form of a game. As you know cyber criminals are getting more and more sophisticated and the best way to counter that is to train more folks on the basic principles of Cyber Security. It is targeted towards children but is good fun for adults as well.

Take cybersecurity into your own hands. In this Lab, you’ll defend a company that is the target of increasingly sophisticated cyber attacks. Your task is to strengthen your cyber defenses and thwart the attackers by completing a series of cybersecurity challenges. You’ll crack passwords, craft code, and defeat malicious hackers.

Check it out at: NovaLabs Cybersecurity
Source: Popsci.com

– Suramya

October 3, 2007

Automatic session logging/monitoring with GNU screen

Filed under: Computer Security,Computer Tips,Security Tutorials,Tech Related — Suramya @ 11:10 PM

Found this good article on how to setup screen on Linux/Unix so that it automatically logs all activity made in the session. Screen is a utility that I use very often on my Linux box. Basically its a program that you start and it attaches to a specific console and if you ever get disconnected you don’t loose your work/position, all you have to do is log back in and reconnect to that screen. You can also connect to a system via ssh/telnet and start a program then disconnect from ssh then move to another location and reconnect to server and join the same session from there. I use it all the time when compiling stuff or downloading large files.

The main issue I had with screen was that it would only keep 20-30 lines in the history so if you wanted to scroll up to read the previous logs you couldn’t. Now this article explains how to set up logging so that you can do that. For the impatient here’s how you do it:

I wanted to automattically launch a screen session when somone logged in so if I happened to be on the server I could monitor them in real time. I also wanted a log of the session in case I wanted to look over it later or if I was not able to monitor the session live.

I ended up adding the following to my .bashrc

# — if $STARTED_SCREEN is set, don’t try it again, to avoid looping
# if screen fails for some reason.
if [[ “$PS1″ && “${STARTED_SCREEN:-No}” = No && “${SSH_TTY:-No}” != No ]]; then
STARTED_SCREEN=1 ; export STARTED_SCREEN
if [ -d $HOME/log/screen-logs ]; then
sleep 1
screen -RR && exit 0
# normally, execution of this rc script ends here…
echo “Screen failed! continuing with normal bash startup”
else
mkdir -p $HOME/log/screen-logs
fi
# [end of auto-screen snippet]

and add the following to your .screenrc

# support color X terminals
termcap xterm ‘XT:AF=E[3%dm:AB=E[4%dm:AX’
terminfo xterm ‘XT:AF=E[3%p1%dm:AB=E[4%p1%dm:AX’
termcapinfo xterm ‘XT:AF=E[3%p1%dm:AB=E[4%p1%dm:AX:hs:ts=E]2;:fs=07:ds=E]2;screen07′
termcap xtermc ‘XT:AF=E[3%dm:AB=E[4%dm:AX’
terminfo xtermc ‘XT:AF=E[3%p1%dm:AB=E[4%p1%dm:AX’
termcapinfo xtermc ‘XT:AF=E[3%p1%dm:AB=E[4%p1%dm:AX:hs:ts=E]2;:fs=07:ds=E]2;screen07′

# detach on hangup
autodetach on
# no startup msg
startup_message off
# always use a login shell
shell -$SHELL

# auto-log
logfile $HOME/log/screen-logs/%Y%m%d-%n.log
deflog on

Keep in mind that this is not a very secure setup. Anyone with any technical knowledge can edit the logs as they are located in the user’s home directory and are editable by them. So don’t rely on it extensively to keep a system secure.

Complete article is available here: Automatic session logging and monitoring with GNU screen for the paranoid.

Thanks,
Suramya

August 8, 2007

Secure Websites Using SSL And Certificates

The following website has a good How-To on how you can Secure Websites Using SSL And Certificates on a system running Apache, Bind and OpenSSL.

– Suramya

December 7, 2005

20 ways to Secure your Apache Configuration

Filed under: Security Tutorials,Tech Related — Suramya @ 11:36 PM

Finally a decent guide on how to secure an Apache installation. I am not maintaining any apache server’s right now but if I was this would have been a great help.

Complete Article: 20 ways to Secure your Apache Configuration

– Suramya

Older Posts »

Powered by WordPress