Skip to content
Jun 9 / kkrizka

Thoughts On Fixing a Hacked WordPress Blog

Over the past few months, this blog was being redirected to a website hosting malware. Every time I fixed the problem, it came back within the next few days. I tried several things, like updating to the lastest version of WordPress and changing all of my passwords, but none of them worked. But after reading an article on the I Was Hacked blog, I managed to solve it permanently. The article is very comprehensive, so I will not bother going into details. Instead I want to summarize the steps that I found helpful in solving my problem.

  1. The first step was to remove the links to malware from my blog. Since only my theme was affected, I just re-uploaded it. This was very easy, since I keep a backup on my computer.
  2. I installed the WordPress Firewall by seoegghead plugin. This plugin monitors my blogs activity for funny events, and prevents them from happening.
  3. Within a few hours, I received an email from the plugin notifying me that it had blocked an “WordPress-Specific SQL Injection Attack”. Also it told me that this attack was attempted through the URL “www.krizka.net/wp-content/themes/classic/comments.php”, which contained a very old theme that I haven’t used in a long time and never bothered to delete. Apparently it has a vulnerability that someone managed to exploit.
  4. I removed the classic theme.

This was a week ago, and this blog has not been hacked again.

Jan 4 / kkrizka

Computer Upgrade: tiny101

Over the winter holiday, the power supply on my main computer died. Since the computer also had some very old parts, I decided to do a full upgrade. All of the parts were bought at NCIX Coquitlam, and they also put it together.  Everything seems to work on Linux without a hitch.

Since my original post proved to be very useful when I forgot what parts I put in, I decided to remake it.

AMD Bulldozer FX-8120 (3.1 GHz, 8 cores)
EVGA GeForce GTX 560 Ti Graphics Card
Kingston HyperX KHX1600C9D3K2/8GX DDR3 4GB Memory (x2)
Gigabyte 990FXA-UD3 Motherboard
Corsair H60 CPU Cooler System
Antec Truepower 650W Power Supply
Belkin F5D7050 Wireless G USB Adapter *
LG L226WTX-BN 22IN Widescreen LCD *
Antec Nine Hundred Gamer Case *
Seagate Barracuda 250GB Hard Drive *
Samsung Spinpoint F1 Series HD103UJ 1TB Hard Drive *
Western Digital WD20EARS Caviar Green 2TB (x2) *
Samsung SH-S183A DVD Drive *
Cordless Desktop MX5500 Revolution Keyboard and Mouse *

The parts that are marked by a star (*) came from the old computer.

One quandary I came across was whether this constitutes a new computer and should receive a new name. In the end, I decided that it should still be considered as the old computer, since the main hard drive (containing the files I would have to change to rename it….) is still present.

Jan 13 / kkrizka

Luke Is An Underachiever

This has to be one of the funniest things I’ve seen in a long time.

[vie japscrota]

Jan 6 / kkrizka

ThinkPad X61 Tablet On Ubuntu Maverick Meerkat

I have been running the Maverick Meerkat version of Ubuntu for the last couple of months on my ThinkPad X61 Tablet. That means that an updated post about works and what does not work is required. Well, sort of an update. As for previous releases of Ubuntu, nothing has changed when it comes specifically to the hardware of the X61T. But I did find out about some new, simpler, ways to fix the existing problems.

Just as a reminder, my model is the one with the SWGA screen and does not have finger-touch capabilities. I do not know about the status of the touch-wacom drivers, so you are on your own for that topic. I suggest you checkout the X61T pages on ThinkWiki or Ubuntu docs. Those are great resources! As for other hardware, the tablet also has 2 GB of memory and a Core 2 Duo processor running at a maximum of 1.6 GHz. The processor also supports other frequencies, like 800 MHz and 1.2 GHz. The frequencies can be changed using the standard Linux tools right away.

My reports on previous versions of Ubuntu can be found in my blog’s archive. Here are the links:

Wireless

The wireless on the X61T works great out of the box, including during installation. No further steps are necessary.

For those interested, the module being used is iwlagn.

Touchscreen (Pen Only)

The touchscreen works out of the box using the Wacom pen. I don’t know about finger-touch support, since I do not have that capability.

To take advantage of it, I suggest that you try out xournal for note taking and cellwriter (my tips and tricks) for handwriting recognition. Both are available in the official Ubuntu repositories, but are not installed by default.

Extra Buttons/Screen Buttons

All of the extra keyboard buttons work out of the box, with the exception of the zoom button (Fn+Space). The buttons that work are the volume buttons, the ThinkVantage button and all Fn buttons. The buttonson the screen are the rotate button, the toolbox button, the escape button and the arrow buttons.

By work, I mean they report a valid symbol to X.Org. For some of them, you have to bind them to an action to make them do something useful.

Middle Button Scrolling Using TrackPoint

For the first time ever, you can scroll with the TrackPoint (hold down the middle button and move the track point) out of the box. I did not have to create an addition to xorg.conf at all.

Suspend/Hibernate

Suspending your computer to RAM works without any trouble. I just close the monitor and the tablet suspends automatically.  Hibernate to disk did not use to work, but it seems to have been mostly fixed by now. The tablet enters hibernation mode properly, but sometimes does not resume. It just hangs there with a black screen. But it does work from time to time.

Hard Drive Accelerometer

The hard drive accelerometer (hdaps) module still does not work out of the box and most likely never will because of political reasons (at least as far as I understand the situation). To get it working, one needs to install it from the tp_smapi sources manually. The simplest way to do this is by running the following commands (posted by Derek in comments):

user@computer:$ sudo aptitude install tp-smapi-dkms

Using the tp-smapi-dkms package will take care of rebuilding the module after every kernel upgrade automatically.

There are two additional packages that I recommend installing. The first package is the hdapsd daemon (available from the official Ubuntu repositories) that stop your disk from spinning when you are moving around. As you can imagine, this is good for the health of your drive. The second package I recommend is my AutoRotate daemon.

Fingerprint Scanner

The scanner does not work out of the box. And even after manual configuration, you can only go so far. While the hardware is supported, the software that uses it isn’t that great. You can configure PAM to allow you to login via fingerprints, but it cannot identify the based on the fingerprint and it always asks for a specific finger at a time.

The best software for this is fprint. I have written a tutorial on how to configure fprint. However you no longer have to add the PPA in it, since fprint is now part of the official Ubuntu repository.

Another choice is thinkfinger. I have also written a tutorial for it.

Dec 30 / kkrizka

Setting Up A Public GIT Repository With GoDaddy Shared Hosting

Over time, I have worked on a lot of small personal projects. Most of them are versioned locally using GIT, so I can track any changes that I make. However when I release them, I do it as a tarball meaning that all of the change history is lost. Also these periodic releases mean that – Of course, I could setup a public GIT repository with GitHUB (and I have for the AutoRotate Daemon), but most of these projects are very small and depricated soon. Going through the entire setup of creating a GitHUB repository for such quick projects just takes too long. For this reason I’ve looked into ways to host GIT repositories on this website, which is powered by GoDaddy’s shared hosting plan. This post is a step-by-step guide as to how I accomplished it.

My configuration is not perfect, mainly because my hosting plan is designed to host web sites and not GIT repositories. To summarize, the repository is available to the public through the HTTP protocol in a read-only fashion. Nothing special is required here. However the developer needs a read-write access to it, so it can be updated with the latest version of the code. This is done through the SSH protocol, since GoDaddy does allow secure shell access to your website.

But this access is limited, which is where the “hacky” part of my configuration starts. First of all to update a git repository through SSH, one needs the git-upload-pack and git-receive-pack commands installed on the server. GoDaddy’s servers do not have them, which means you need to install them in your home directory. But your home directory is not in the PATH variable of a non-interactive bash shell (used by GIT) and it is impossible to change this. I’ve come up with two ways to get around this.
First solution is to specify the full path to git-upload-pack and git-receive-pack commands through the remote.origin.uploadpack and remote.origin.receivepack variables in the configuration of the private repository (local machine).
The second solution is to use the command option in .ssh/authorized_keys and source the .bashrc files and update the PATH variable through it. Of course, this only works if you are using SSH keys for authentication.
If you come up with alternate solutions, feel free to leave a comment below.

Requirements

  • GoDaddy shared hosting – I’ve written this tutorial assuming that you are using GoDaddy’s servers. Of course, the key steps should work with other web hosts too as long as they allow SSH access. The only issue might be that the GIT binaries that I provide are compiled for CentOS 5.2 (used by GoDaddy), so there might be an incompatibility issue.
  • Previous GIT experience – This is not a tutorial on how to use GIT. I assume that you already know how it works. If not, then read the GIT Community Book.
  • GIT installed on local machine – Hopefully self explanatory.
  • SSH client installed on local machine – We’ll need some way to setup stuff on GoDaddy’s servers. Also I’m pretty sure that it is required for GIT to work with SSH.
  • Bash shell on local machine – I provide the commands on how to accomplish all of the tasks. If you are using a GUI (ie: Putty or WinSCP on Windows), then you are on your own. On Windows, you can use Cygwin.

Setup GIT Binaries On GoDaddy’s Servers

As the first step, you need to install the GIT binaries on the server. This will be done by unpacking a pre-compiled binary of GIT that I provide.

  1. The first step is to enable SSH access to your account. All GoDaddy hosting plans come with the SSH access which can only be enabled after you provide a valid phone number. To do this, go to the Control Center for your hosting plan. Next locate the page under Settings->SSH and follow the instructions. They are to basically type in your phone number and wait for a bit. Soon you’ll receive an automated call that will give you a PIN code. The message says it twice, so don’t panic if you didn’t catch it the first time. Type this PIN into the box provided on the website and hit enter. If everything went correctly, you will see a message saying that SSH access is being enabled. If something goes wrong, consult the GoDaddy help pages.
  2. Wait a while, it takes an hour or two for SSH to become enabled.
  3. After SSH is enabled, connect to your GoDaddy server with the following command:
    user@computer:$ ssh username@yourwebsite.com

    The username is the same as your primary FTP username. If you don’t know what it is, you can find out by looking under Settings->Manage FTP Users in the Control Panel. The password is the same as you use for FTP. If this step worked, you can also setup password-less login through SSH keys. All of the following commands are to be executed in this SSH session.

  4. Download the GIT binaries on the GoDaddy server by running the following command:
    user@computer:$ wget http://www.krizka.net/download/files/git-1.7.3.4_centos5.2.tar.bz2

    These binaries were compiled from the GIT (version 1.7.3.4) source code by me. I compiled it in a virtual machine (VirtualBox) running CentOS 5.2, which is the same operating system that my GoDaddy server is running. In my experience, Linux binaries are relatively portable so these might also work on servers running a different operating system. However if they do not, you’ll have to compile them yourself. As I mentioned, the simplest way to do it is create a virtual machine using the same guest operating system as your web host is using.

  5. Unpack these binaries using the command:
    user@computer:$ tar -xvjf git-1.7.3.4_centos5.2.tar.bz2

    This unpacks everything into a directory called git. So if you want to uninstall everything later on, just delete this directory.

  6. Using your favourite text editor, add the following lines to the bottom of the ~/.bashrc file on the GoDaddy server:
    export GIT_BIN=${HOME}/git
    export PATH=${GIT_BIN}/bin:${PATH}
    export LD_LIBRARY_PATH=${GIT_BIN}/lib:${LD_LIBRARY_PATH}
    export GIT_EXEC_PATH=${GIT_BIN}/libexec/git-core

    This tells your shell where the GIT binaries are located, making their use available in an interactive shell. You have to login and logout for the changes to become recognized.

  7. You can now logout from the SSH session.

Publish The Private Repository

In this section, you will create a “bare” public repository and publish it on your web server. As an example, I will use my private repository of my AutoRotate Daemon project as a base.

  1. Create a bare clone of your private repository using the command:
    user@computer:$ git clone --bare ~/Projects/autorotate autorotate.git

    The –bare option strips all of the explicit files from the repository, saving the space. The first argument, ~/Projects/autorotate, is the path to your private repository. The second argument, autorotate.git, is the directory where the bare clone will be created. This clone will your public repository.

  2. Copy the public repository (autorotate.git) to your webserver. You can use either FTP or SCP to do this. I prefer SCP, because it is much simpler to use:
    user@computer:$ scp -r autorotate.git krizka.net:~/html/git/

    The last argument, krizka.net:~/html/git/, is the path on your webserver that the public repository should be copied to. krizka.net is the host name of your server and should be in the same format as the one used to connect though SSH in the first section (username@yourwebsite.com). The part after the : (~/html/git/) is the path on the webserver. The ~/html folder corresponds to the root of your website. So in my case, you can access the AutoRotate Daemon public repository at http://www.krizka.net/git/autorotate.git .

  3. Test that everything worked by running the following command on your local machine:
    user@computer:$ git clone http://www.krizka.net/git/autorotate.git

    Of course, replace http://www.krizka.net/git/autorotate.git with the expected URL of your repository.

  4. The final step is to update the server info in the public repository. This is required to make it work with HTTP. To do this, first connect to your server through SSH.
    user@computer:$ ssh krizka.net
  5. Second, enter the directory of your public repository.
    user@computer:$ cd html/git/autorotate.git
  6. Finally, run this command:
    user@computer:$ git update-server-info
  7. You can now logout from the SSH session.

Let Local GIT Know About Remote GIT

In the previous section, you have created a public repository that can be read by anyone. Now you have to setup write access to it through SSH. This is done in two parts. First you have to add a remote repository to your private repository. And then you have to tell it where to find the git-upload-pack and git-receive-pack commands. As mentioned in the introduction, I found two ways to accomplish this. I prefer the second method, because I only have to do stuff once per computer. With the first method, you have to do stuff once per repository clone.

  1. On your local machine, enter the directory containing your private repository.
    user@computer:$ cd ~/Projects/autorotate
  2. Add the remote repository as origin using the command:
    user@computer:$ git remote set-url origin ssh://krizka.net/~/html/git/autorotate.git

    Don’t forget to replace krizka.net/~/html/git/autorotate.git with the path to your public repository, just like you did when copying it over with scp. Note that in this case, the : was replaced with a /.

  3. Try to push some changes to the public repository. You will fail with the following error:

    bash: git-receive-pack: command not found
    fatal: The remote end hung up unexpectedly

    This is because GIT does not know where the GIT binaries are installed are GoDaddy’s server. For interactive Bash, we accomplished this through the .bashrc file. But this file is only read when using an interactive shell. If you start Bash in an non-interactive mode, which is what GIT does, then no such initialization file is used. It is impossible to change the environment variables in an elegant way for non-interactive shells, so you have to pick one of the following dirty methods to fix this.

Method 1: Tell Local GIT Where To Find Binaries

  1. In the directory of the private repository, run the following two commands:
    user@computer:$ git config --local --add remote.origin.uploadpack /home/content/k/r/i/krizkanet/git/bin/git-upload-pack
    user@computer:$ git config --local --add remote.origin.receivepack /home/content/k/r/i/krizkanet/git/bin/git-receive-pack

    Make sure to replace the last argument in both commands with the full path to the two binaries.

Method 2: Use SSH Forced-Commands

If you are using SSH keys for authentication (tutorial on how to do this), then it is possible to change the command that will be run remotely. In our case, we change the command to be “read .bashrc; eval requested command”.

  1. Connect to your web server using SSH. All of the following actions will be done there.
  2. Open the .ssh/authorized_keys file in your favourite editor and locate the line that contains the public key that you use to login. My key looks like the following:

    ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArXgEE/YSFIjlCQIDJP68Fng2jsEZQjaTgZ4h0/HUjZLXzE+F2RLJwRRFS+Sn30y8sZ3buCGYeIQKH+L0FLvN/0kn3CM+/mIwBeH1+CGETsIliGjSO62ewk+ePsM6vtQ7RxVY7Z1NI+lz5vMuTXiUr9qd5Le/EiblbcIDiIAzVtHVLYFUPiTlHeEbsSgP1wA9dUPzz5Ge4sIBqYuur1FlvJT55cjo+PsZkHuarbLabhR69U/zfd9w8ba01RJJiJVL7ZqozuYi9GnnGMT72UroIvriyUZfJqRIdQm2VxME+KSBsnf8sqqJJVUY+owCluYPMjFpsnmnXoNosLSDpZpP+Q== kkrizka@tiny101

  3. Add the following text in front of your key. It should be on the same line!
    command="if [[ "x${SSH_ORIGINAL_COMMAND}x" == "xx" ]]; then /bin/bash; else source ~/.bashrc; eval "${SSH_ORIGINAL_COMMAND}"; fi; "

    What this does is check if a command is to be run remotely, and if it is then it sources .bashrc and runs the command. If no command is to be run, then it just starts an interactive shell. After you are done, the line containing your key should look something like:

    command=”if [[ "x${SSH_ORIGINAL_COMMAND}x" == "xx" ]]; then /bin/bash; else source ~/.bashrc; eval “${SSH_ORIGINAL_COMMAND}”; fi; ” ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArXgEE/YSFIjlCQIDJP68Fng2jsEZQjaTgZ4h0/HUjZLXzE+F2RLJwRRFS+Sn30y8sZ3buCGYeIQKH+L0FLvN/0kn3CM+/mIwBeH1+CGETsIliGjSO62ewk+ePsM6vtQ7RxVY7Z1NI+lz5vMuTXiUr9qd5Le/EiblbcIDiIAzVtHVLYFUPiTlHeEbsSgP1wA9dUPzz53e4sIBqYuur1FlvJTP5cjo+PsZkHuarbLabhR69U/zfd9w8ba01RJJiJVL7ZqozuYi9GnnGMT72UroIvriyUZfJqRIdQm2VxME+KSBsnf8sqqJJVUY+owCluYPMjFpsnmnXoNosLSDpZpP+Q== kkrizka@tiny101

Try to push your changes now. Everything should work now. A full list of my public GIT repositories is available at http://git.krizka.net/

References: