Bugsbane
Dedicated to shooting any bug that moves. and not making new ones.

More TDSS Goodness

July 01st, 2011

This is just a short post to highlight a really good discussion on the TDSS rootkit that I encountered over month ago. http://www.securelist.com/en/analysis/204792157/TDSS_TDL_4

This rootkit is quite insidious and apparently is in active development. There’s a question as to whether or not it still lives on one of my machines. Certainly the DNS spoofing has not happened again, but with all the devices I have on the net, it’s impossible, even using Wireshark, to determine that all packets going through are legit.

It is interesting that TDL-4 has an anti-virus component. So much so that having it infect a machine, then subsequently cleaning it might actually be of benefit.

I wonder if the widespread use of VMs made it easier for virus developers to create strains that resist detection. Consider that TDL-4 hooked into INT 13 to trap disk reads. With that, the signature on the disk could easily be morphed by an encryption key. The INT 13 handler can easily decrypt the payload and the key need not be static. Signature based detection is rendered useless.

I’m more and more convinced that ‘devices’ should be throw-away. They need not be defended. An application lives only for the time it is used, then is returned to the cloud. Data is only in the context of the cloud. I need to really flesh this out before I spout out more nonsense.


Filed under: Uncategorized | No Tag
No Tag
July 01st, 2011 17:37:35

Beginning Drupal… (first impressions)

June 12th, 2011

I’m starting out life as a Drupal n00b. Installed Drupal 7.2 on a number of boxes (basically on all machines I use). On some Windows machines, I use XAMPP, on others (with lots of memory) I picked up a CentOS VM running on a free VMWare player.

The most convenient place to get the VMWare image has been from VMWare itself. This link provides a CentOS 5.3 image (http://www.vmware.com/appliances/directory/34758) – but a simple yum update and you’re up to CentOS 5.6 as of this writing.

First thing to do is to add the EPEL repo. (basically a couple of RPM commands which I did not document). This is completely biased but I find EPEL to be more ‘complete’ than RPMForge. For instance, if you’re using php-xdebug, then you’re S.O.L. with RPMForge.

CentOS 5.6 is still on PHP 5.1.6 – so if you like that, keep it, otherwise yum update to php 5.3.
Make sure you install VMWare tools – makes life easier allowing shared directories between the host OS (Windows 7 in my case) and CentOS. Of course, you could go the samba share route like Sacha Chua did on this post.

If you’re going the php53 route, remove 5.1.6. (yum remove php-cli php-common php). Then install 5.3 (yum install php53 php53-gd php53-mysql php-dom php53-devel) – Drupal needs those.

I turned off iptables on my machine. If you ever get to the a point where you can SSH to your box but an http request does not respond – it’s a good chance iptables is blocking you. I could do this since my VMWare is NAT’d to my machine. Most people (Sacha included) prefer to run their VM in ‘bridge’ mode – which means that it’s a peer on the subnet. If that’s the case, I’d be leery about turning off iptables.

Download Drupal and follow the install instructions.

THEN: jump into the built a module tutorial. Seriously. So many links on the web have Drupal 6 tutorials for building modules. But a lot of things changed between Drupal 6 and Drupal 7 – not the least of which are the module_hooks. THUS: if you’re following along on a Drupal 6 tutorial and all of a sudden you can’t get past the point where your ‘block’ is supposed to show up in Admin->Structure->Blocks list – then the chances are you didn’t implement the Drupal 7 hooks.

For instance: if your module is named: lame_module, you’ll need to implement lame_module_block_info() and lame_module_block_view(). NOT lame_module_block()… grrr.. I wasted an hour of my time trying to debug that. Follow this tutorial: http://drupal.org/node/1074360 – works like a charm – although I daresay they could have made the tutorial a little easier for n00bs. There was, for instance, no need to delve into the DB as early as the tutorial did – and concentrate instead on the initial render of block view of the module.

I guess that’s about it. It appears to be a decent framework. Quite different from developing in CakePHP or Zend or Symfony – in a way it feels more ‘cumbersome’ – but already in drupal is functionality that I would not have to write in other frameworks. We shall see how I feel at the end of the month. I might really hate it.

Something I did notice: Drupal has a *LOT* of information on the Web. Mostly with a version of Drupal that is not 7.x. Stay away from it, IMHO. it’s better to read 7.x-specific stuff than be mislead by old docs.

Stay tuned to this space. I’ll post more of my Drupal adventures in the coming days.


Filed under: Uncategorized | Tags:
June 12th, 2011 06:45:15

Rogue DHCP Server Malware (2011 version)

May 29th, 2011

TL;DR

The Rogue DHCP Server can be killed by TDSSKiller from the Kapersky anti-virus site (http://support.kaspersky.com/faq/?qid=208283363) . Other antivirus software did not seem to detect this rootkit. YMMV.

The Details…

My wife’s laptop got hit by some malware. It basically runs a rogue DHCP server so it can provide a bad DNS server to the other machines on the network. In our case, it pointed the DNS to 188.229.88.7.

Fixed this first by setting up static IPs (bypassing DHCP). But the possible consequences are scary. First off, the guy could have also changed the default gateway. If he (or she) were devious enough, it was easy enough to do a man-in-the-middle attack where they could spoof a bank site and grab our credentials.

Luckily the fiend(s) were after low hanging fruit. The DNS server basically responded with its own IP. Opening up a CMD prompt, (yes.. I know this happened in a WinDoze box which I have hardly booted… so sad), I pinged a number of hosts by name, and got the same IP address: 188.229.88.7. Attempts to browse to any site from a machine which got that DNS brings up a page that prompts you to download a ‘browser upgrade’ with a link to a file called: update.exe. Local virus scans would detect nothing (since the attack was on DNS).

It is funny that I saw no anomalies while browsing in my mac. Perhaps the mac’s DHCP failed with the rogue DHCP server and instead got the credentials from the real server. Or perhaps it was by luck that I opened the mac while the infected laptop was turned off. In any case: be careful of this. I’ll post an update once I find the offending process.

One other symptom is that Netflix fails to open movies. I need to verify that. So if your Netflix has been acting strangely, you might have a poisoned DNS provided by a rogue DHCP.

GLHF

UPDATE (5/29 9:32AM): I ran MalwareBytes on the ‘poisoner’ laptop – and it failed to detect and remove the rogue DHCP server. More to come as I squash this sucker (after lunch with relatives)

UPDATE (5/30 6:48AM): The Rogue DHCP server still runs. I have not been able to kill it yet. Numerous restarts, but here’s what I’ve found out.

  • The rogue DHCP Server is started by a process calling svchost.exe
  • The rogue DHCP Server appears not to be started upon boot – but when a broadcast request to port 67 happens, it springs to life. Ports 135 and 445 are also suspect – since the DHCP request might also send packets to these ports. This has not been confrimed by wireshark. so take that info with a grain of salt
  • ZoneAlarm might be able to protect against this by ensuring that svchost can only be started by privileged processes. I have not tried this. I want to see if I can catch the malware process and remove it instead.

Tools I’ve used to try to weed this out:

  • Download and install sysinternals/TCPView from Sysinternals
  • Reboot the machine and fire up TCPView from wherever you installed it.
  • Observe that there is no process listening to the bootps port. (That’s the DHCP port)
  • Make a DHCP request from another machine. Then watch the rogue DHCP server spring to life in TCPView.

Mitigation so far:

  • Make all your computers use static for now until someone figures out how to solve this.
  • Alternatively, specify the DNS for each of your network’s computers.

As always… Good Luck. and Have fun. Let me know via comments you’ve made more progress than I.

UPDATE (5/31 22:08PM): Thanks to the comments, David, Alex, et al, the malware is now history. I’ve confirmed that it is indeed removed by TDSSKiller from http://support.kaspersky.com/faq/?qid=208283363 . The cleaning process requires a reboot as the rootkit hides itself in the MBR.

Thanks all!


Filed under: Uncategorized | Tags:
May 29th, 2011 04:39:35

jQuery-ui Sortable gotcha! serialize() method was returning empty

January 07th, 2010

I cobbled together a quick demo of jQuery sortable for a todo quick and dirty todo-list for the websites I maintain. In an attempt to come up with minimal code to demo the jQuery sortable element, I came up with the following. The following code is best ran through firebug with a console enabled to be able to see the update messages. Also, the jquery.js and jquery-ui.js are symlinks to jquery-1.3.2.min.js and jquery-ui-1.7.2.custom.min.js which can be downloaded from jquery.com


<html>
<head>
    <title>To Do</title>
    <script src="jquery.js"> </script>
    <script src="jquery-ui.js"> </script>
    <script type="text/javascript">
    $(document).ready( function () {
        $("#alist").sortable({
            update: function () {
                    var orderx=$("#alist").sortable('serialize');
                    console.log( 'orderx is '+orderx );
                }});
    });
    </script>
</head>
<body>
    <ul id="alist">
        <li id="item_1">First Item</li>
        <li id="item_2">Second Item</li>
        <li id="item_3">Third Item</li>
        <li id="item_4">Last Item</li>
    </ul>
</body>
</html>

It is important that the ids for the <li> elements are set. and that the value of the id must have an underscore. This is necessary for the serialize method to work. Thus, item_1 will work, while item1 will not. It took me 35 minutes to carefully read through the docs and flail a bit to figure this out.

The portion of the id before the underscore is used as a variable name, in this instance: item. When you run through this a few times, you’ll get the following console output:


orderx is item[]=4&item[]=1&item[]=2&item[]=3

This string can then be passed as part of a URL for a server-side script to do with as it pleases. In my case, I intend to persist the ordering. Thus, there are N * M databases update statements where N is the length of the list and M is the number of times a given list element is moved. Quite inefficient, but we’ll tackle that in another post.


Filed under: javascript,Uncategorized | Tags: , , , , , , ,
January 07th, 2010 22:04:19

Setup and Teardown issues with PHPUnit Tests, mysql query logging

January 05th, 2010

I have a PHPUnit test at work which does the prototypical setup and tear down to setup the data that the test needs. In this particular case, I need to create a user during setup, and remove it to restore state during the teardown phase.

The test case has a handful of tests so the setup and tear down functions happen, say, a dozen times during the course of the test. Academically, I should just leave the test as is, but during some builds, I get a failure. Digging deeper into the problem, I noticed that the user creation and user deletion was calling an API which invoked a service. For some reason, the server (which is multi-threaded) is slower in handling the delete than the insertion of the user. To avoid build failures, I’ve had to insert a 1 second delay after the delete request during the tear down. That eliminated the race condition which caused the subsequent insert to fail because of a duplicate key constraint during setup of the next test. The sporadic failure of the unit tests decreases the confidence that my developers have in the unit tests, and makes them more likely to ignore the build failures. This is unacceptable since I want them to jump at red-light build failures IMMEDIATELY.

I consider this hack more like “flailing” versus a “surgical” fix. The real problem is that the server seems to be delaying the execution of the DELETE sql until the row is no longer being read. Since we’re using InnoDB, we do not have table level locking, but a LOW PRIORITY modifier on the delete statement could still be causing the problem.

I’m using mysql 5.1.31 at the moment. To turn on query logging, I simply bounce mysqld with the –general_log=1 and –general_log_file=/var/log/mysqd_queries.log options as per: http://dev.mysql.com/doc/refman/5.1/en/query-log.html .

Now that the culprit has been identified, we need to do a couple of things.

One: do I really need to delete the user? – I might be able to use the test-chaining features of PHPUnit 4 to avoid having to delete a user which will just be recreated by the same test (as long as the test does not modify the user record). I need to ensure though that when the test case is finished, that the DB is in the same state as when I entered it.

Two: I think that using services in the setup and teardown sections of a PHPUnit test case is asking for trouble. I know what state the DB has to be in. It behooves me to do a brute force insertion of the data that I need for the test to work. The problem with this solution lies in its brittleness. As the data changes, I need to make sure the setup and tear down also change. In time, the maintenance of setup and tear down functions may be time consuming.

I’m still trying to find a good balance between flexibility, ease of implementation and reliability of running tests. What are your thoughts on handling build failures that are caused by nuances of the system rather than by actual bugs in the code?


Filed under: continuous integration,Uncategorized | Tags: , , , , , , ,
January 05th, 2010 19:20:18

Debugging Techniques

January 04th, 2010

This site is dedicated to the elimination of bugs, either by Unit tests, Conitunuous integration, Monitoring applicaitons or Hints about forensic analyses of log files. It is my hope that this becomes a resource for developers and operations personnel to make their life easier.

It is my hope to add the following in this blog:

1) PHP debugging techniques.

2) Apache Configuration debugging

3) MySQL query Logging

4) Hudson and CruiseControl configuration

5) Debugging Phing make files


Filed under: Uncategorized | No Tag
No Tag
January 04th, 2010 21:59:36