Suramya's Blog : Welcome to my crazy life…

February 13, 2018

Explaining HTTPS using carrier pigeons

Filed under: Interesting Sites,Security Tutorials,Techie Stuff — 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:

January 29, 2018

How can we secure a Client App so that the server side can detect tampering?

Filed under: Computer Security,My Thoughts — Suramya @ 5:09 PM

If you have been following ADHAAR in the News/Social Media recently then you must have seen the posts by some prominent cyber security folks about basic security issues with Adhaar. I couldn’t resist chiming in with my two cents and pretty soon the conversation switched from the glaring security issues with Adhaar to how we could secure applications when the client could not be trusted. Sushil Kambampati had some interesting questions on this topic and we tried having a discussion on Twitter itself for a short while but since twitter is not the best medium for long winded conversations we switched to email pretty soon and the following is a summary/expansion of my conversation with him.

Special thanks to Sushil for asking the two questions listed below thereby motivating me to write this post. Please note that all the items below are my personal thoughts and I don’t claim to know everything so some of the things below might not be the best option or might require additional safeguards beside the ones I talk about.

What are the risks if the client has been modified by an attacker?

The possibilities are endless if an app has been modified and can still successfully communicate to the server backend. The attackers can tamper with it to install a backdoor on an app, re-sign it and publish the malicious version to third-party app marketplaces. They can also change the app to query the server in ways that the designer didn’t expect. e.g. query the DB for all possibly values of the Adhaar no (as an example) to identify valid values. They can also attempt to perform SQL injection attacks/other attacks on the server by sending it data that it doesn’t expect.

How can the server-code detect whether the client app has been modified?

This is a very interesting problem and there is no foolproof method to ensure that the local client hasn’t been modified. However that said we can always make it harder for the attacker to modify the app. Some ways we can detect tampering are listed below along with potential ways to bypass the checks. (I am going to talk about app side checks in addition to server side since both need to be performed to secure the app). I specifically talk about Android applications here but the same is valid for any server/client system where the client can’t necessarily be trusted (and if your client is installed on a machine you don’t control then it def can’t be trusted).

  • We add code obfuscation/shrink the code using Proguard.This makes it more difficult (though certainly not impossible) to reverse engineer the code by making it harder to read a stack trace because the method names are obfuscated. Other things we can do to harden the app is to include checks to detect if the app is running in a virtual environment (emulator) and abort runs. This check should not be an easy thing to disable e.g. by setting a flag, instead the build process should add the check when building the release version or something similar while making it as hard as possible to disable. Finally we should ensure that all debug code is stripped out from the build when creating the release version. This will make it harder for the attacker.

    The communication between Server & Client should be over a secure/encrypted channel (use HTTPS not HTTP), all local data should be encrypted with a unique password that is generated at runtime (1st run) using a random seed.

  • We have the app send a checksum that the server verifies everytime an API call is made.
  • This is a very basic check that is fairly simple to bypass as any competent attacker will also modify the app to send the correct checksum value even though the actual checksum value is different.

  • Have the Server request for a byte string from a random location in the APP e.g. send me 100 bytes starting from byte # 2000 from the beginning of the file. This check would fail if any changes are made to the file in the section that the check queried.
  • The issue is that there is a high probability that the check location requested by the server is not for the location that the attacker has modified. Also, if the attacker is sufficently motivated they can append a copy of the original App to the tampered app and then modify the check function to return the values from the original app when the server attempts to verify the integrity.

  • Verifying your app’s signing certificate at runtime.
  • All applications in the Appstore are signed with a developers private key and the app signature will be broken if the APK is modified. By default android will not allow you to install an app where the signature doesn’t match. However you can potentially bypass it by changing the code / value you are checking against. Also, the app can still be installed manually if the phone is rooted.

  • Verifying the installer
  • Each app contains the identifier of the app which installed it. Therefore, with a very simple check you could have your app verify the installer ID. This can be an in app check and also triggered by a server API call. However with access to the code (by reverse engineering the app) this check could potentially be commented out.

  • Monitor your server side logs
  • This is very important, because any attempts to hack the server/bypass restrictions will leave a trace in your logs. If you have configured good log monitoring rules then this can act as an indicator of someone trying to hack your application. Then you have the option of putting countermeasures into action like blacklisting etc.

Hope this all makes sense. Please let me know if you have any further questions by posting a comment below or emailing me.

Regards,

Suramya

July 6, 2017

Dear HDFC Bank: Please stop making life easier for phishers

Filed under: Computer Security,My Thoughts — Suramya @ 11:32 PM

I recently had to create a HDFC account because I changed firms and needed a HDFC account in order to be paid 🙂 . Once I created the account I got a few SMS messages from AM-HDFCBK asking me to register online for Netbanking and Mobile Banking which is quite normal (though the no of messages were a bit annoying), what was scary and concerning was that the link in the message was a generic bit.ly URL. (See screenshot below)

HDFC Messages Screenshot

Screenshot of the Messages I got

For those who don’t know, bit.ly is a URL shortening service that allows you to create a short URL that redirects to a different URL. e.g. I have configured http://bit.ly/1MUISmu to redirect to https://en.wikipedia.org/wiki/Phishing. The service is most commonly used on Twitter where the max allowed characters are limited and the URL lengths are long.

However since anyone can create a bit.ly redirect there is no way of verifying that the link I got in the SMS was actually created by HDFC and points to a legitimate site and not a website controlled by a cyber criminal who is out to steal my data. The link can point to literally any website in the world that the sender wants including sites that are copies of the legitimate HDFC bank but in reality are storing your credentials to allow people to steal your money or sites that infect your system with a virus/ransomware.

There is a reason why computer security professionals tell people not to click on random links you get via email/SMS/whatsapp.

If you think that since the sender of the SMS is ‘AM-HDFCBK’ the message is legitimate and thus safe to click then think again. There are a ton of websites out there that allow you to spoof SMS sender details to anything you want at a cheap price. In fact you can also code your own software for doing this in bulk using publicly available API’s at ridiculously cheap prices. These are sites I found after a couple of mins of searching on Google, I am sure there are more secure/untraceable methods of sending fake/spoofed SMS messages on the dark web. So the risk of clicking on unknown links that I got out of nowhere is not worth it.

Normally what companies do in similar scenarios if they absolutely have to use a shortner is that they but a short domain name and use that so people getting the messages can identify the link as something pointing to the official site. But I guess someone at HDFC is trying to save money by not registering a new domain that would protect their customers. *Shrug*.

Ah well, looks like I will need to go to their official site and register my account from there.

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

– Suramya

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

June 15, 2015

Winners for the 2014 Underhanded C Contest are announced

Filed under: Computer Security — Suramya @ 10:45 AM

The underhanded C Contest is an annual contest where developers are asked to write code which is clear, readable and as straight forward as possible while doing something evil in a very subtle manner. The goal behind the contest is to make people aware that even code that looks completely benign can be doing something bad either intentionally or accidentally. The contest has been around for 7 years and the solutions people have come up with are amazing. This years winner was Karen Pease and trying to understand their code made my head hurt.

Here’s an extract from the site that explains how Karen gamed the system:

  • We get the cur_time = localtime() and we want to check if
 cur_time->tm_year is a leap year
  • We call __isleap( cur_year = AUDIT(cur_time->tm_year) )
  • this expands into a line of code from nested macros
  • The first thing that happens is a call to check_clock_skew() that calls localtime() on a teensy time interval, overwriting our time structure
  • cur_time->tm_year is now 0, which satisfies all three clauses in the __isleap() macro,
  • Causing AUDIT() code to be evaluated thrice
  • Ow my head, and
  • The year (or rather, the number 0) is written to the audit record three times. This overfills the audit buffer.
  • Thus the final AUDIT call zeroes out a user’s created time, if the user was surveilled.

Looking at this code, it explains how difficult it is to prevent a skilled programmer from adding backdoors or Easter eggs in software and why code reviews are so important.

– Suramya

April 25, 2015

There is no such thing as a completely secure OS

Filed under: Computer Security,My Thoughts — Suramya @ 1:47 AM

Every once in a while while talking to folks about computer security I am told that I should switch to Mac’s because they don’t have security issues or viruses. I find that very amusing and I think the following comic sums up the ‘apple fanboi’ thinking quite succinctly:

Even though it is funny, unfortunately a whole lot of folks still believe in the Myth that Apple computers/devices are secure/don’t get viruses. Now, don’t get me wrong, there are a lot of good points for the Mac OS and they just work for some people. I am not one of them but that doesn’t mean that I ‘hate’ Mac OS or Windows for that matter. I like Linux, others don’t. That is their choice and this is my choice. This post is to talk about computer security and high light some of the major flaws that have hit Apple computers over the past few months:

Firmware Boot kit: Thunderbird

This was discovered by Trammell Hudson back in Jan 2015. It allows a user to quietly, persistently and virally compromise Apple Macs from boot. Since the code is stored in the firmware it is very difficult to detect and remove. It works against all Macbooks released since 2011. Apple has released a fix but it is hard to ensure that your computer isn’t already infected before applying the patch.

Details are at: Thunderstrike shocks OS X with firmware bootkit.

Shellshock: Mac’s are vulnerable

Shellshock allowed attacker’s to insert malicious pieces of code from a remote location and get full system control of a victim’s machine. The scary part of the story wasn’t that Apple computers were vulnerable (plenty of systems were), it was the fact that Apple refused to acknowledge the issue and took over 15 days to release a patch for the problem, even though it was being actively exploited in the wild. Their justification was that “The vast majority of OS X users are not at risk to recently reported bash vulnerabilities… With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services”.

So basically if you don’t use your computer to do anything other than the default configuration you are good. (for the most part) Those of us who use Mac’s to actually code or develop stuff are not a priority for Apple.

Bypassing OS X Security (Gatekeeper & xProtect)

Patrick Wardle, director of research at Synack spoke at the RSA conference a few days ago about OS X security and as per him getting around the restrictions put in by the OS X Security tools is trivial.

“Gatekeeper doesn’t verify an extra content in the apps. So if I can find an Apple-approved app and get it to load external content, when the user runs it, it will bypass Gatekeeper,”

More details on the issue are at: Researcher Discloses Methods For Bypassing All OS X Security Protections

iOS WiFi Bug Allows Remote Reboot of All Devices In Area

This one is my favorite. It allows an attacker to cause all iOS devices (iPhones/iPads) in a particular area to Crash and/or reboot. It involves setting up a rogue wireless access point (WiFi hotspot) and manipulating the traffic to it to cause all apps and iOS devices in range to crash. The best part is that there is no fix for it. The only way to resolve the issue is to move out of range of the Access Point. Even putting your phone in Airplane mode doesn’t work. Which is scary on it’s own because that means that even when you are in Airplane mode the phone is still transmitting/receiving data from wireless networks.

Since there is no fix for it yet, the researchers have not released a lot of details on the exploit but once Apple releases a fix they will give more details it. Then I can just imagine someone setting up one of these using a Raspberry Pi at a conference hidden under a table causing a whole bunch of people a whole lot of pain/annoyance.

Additional details of the issue are at: Evil Wi-Fi kills iPhones, iPods in range

There are a whole lot more where these came from. So the moral of the story is that there is no system that is 100% secure. If you want to stay safe, follow best practices, update frequently and pray.

– Suramya

November 8, 2014

Be careful of software claiming to hide your data on your Phone

Filed under: Computer Security,My Thoughts — Suramya @ 11:59 PM

Yesterday (well, technically today) I was trying to find some data on my old phone to copy to my new phone so I decided to copy over all the folders from the phone to my desktop to make it easier to look through it. While I was going through the data I found a folder called .keepsafe under the Android/data folder so I looked in it cause I got curious and found some interesting data. Actually before I tell you what I found lets take a step back and go over what Keepsafe is: It is an app for both iOS and android that allows you to hide photos/files on your phone and then only people with the correct PIN can view them. From their site: “You lock your rings in a jewelry box. You lock your certificates in a cabinet. Now KeepSafe makes sure your personal files are locked down and hidden, using privacy features such as PIN Pad and Fake PIN.” I had installed this version of Keepsafe a few years ago to try it out but had since uninstalled it as I didn’t find it useful.

Coming back to the folder and what I found. It had two files under it: .local and .email. The .email file had my email address in it but the contents of the .local file were shocking. It had my ‘secret pin’ in clear-text in the file. So anyone with some idea of how apps store data and access to a file browser would have been able to get my pin and view images/data that was supposed to have been protected.

Since this was an older version of the software I downloaded and installed the latest version on my S5 to see if the issue was still there. Thankfully someone at the company figured out that storing the data in clear-text was extremely stupid and in the latest version of the software the same two files are still there but the data is encrypted. Not sure how strong the encryption is because I don’t have the knowledge/skill set to try to figure that out. I did however identify where the files are being stored (they are all encrypted as well) so someone with the original image and an encrypted copy could potentially reverse engineer the encryption and assuming they are using a static encryption key decrypt the remaining files as well.

Moral of the story is that if you want to ‘hide’ data on your phone be very careful of the software you use to do it. Ideally you should avoid storing any data that is sensitive on the phone. There are plenty of ways to get access to the data if someone is interested and has time. This is not an isolated case of a badly written software, There are other cases as well where other software was found to have similar amazing security. So be careful out there.

I did find some more interesting data on the phone that I will take a stab at when I get some time.

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

– Suramya

November 7, 2014

Free Intro to Cryptography course for programmers

Filed under: Computer Security,Security Tutorials — 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

November 3, 2014

Use Excel to Watch Movies at Work

Before I start, let me make it very clear: I don’t recommend that you do this at work. If you get fired for doing this then it is your fault. I take absolutely no responsibility. That being said, lets proceed. I found this very interesting because it shows that no matter how much you try to secure a system there is always a way around any restrictions people put in the system and the only truly secure system is one encased in a ton of concrete at the bottom of the ocean. In this case a user figured out how to use the VBA (Visual Basic for Applications) functionality in Excel to go around the restrictions placed on his computer by his company’s IT department to watch movies at work.

From a Hacker/ingenuity point of view I love this, but from a work perspective I don’t think this was such a good idea. If you really wanted to watch a movie at work then there are easier and safer options to do so; watching it on your phone or tablet is one option that comes to mind. I seriously doubt that his IT admin or his manager would be amused when they find out about this hack.

Behind the cascade of rectangles and in the land of the Excel macro, [AyrA_ch] took advantage of the program’s VBA (Visual Basic for Applications) functions to circumvent the computer’s restrictions. Although VBA typically serves the more-complex-than-usual macro, it can also invoke some Windows API commands, one of which calls Windows Media Player. The Excel file includes a working playlist and some rudimentary controls: play, pause, stop, etc. as well as an inspired pie chart countdown timer.

Hacking things is fun, but folks need to realize that they need stop being stupid about it. I am sure there is a lot of things I can do at work that I might not be supposed to but just because you can, doesn’t mean that you should.

Check out the original post on Reddit for a link to the file and a more detailed explanation.

Thanks to Hackaday.com for the story.

– Suramya

Older Posts »

Powered by WordPress