Too Secure? Paypal shows how...

It has been a while since I found the time to add a blog post, but today I came across some security procedures that gave me the perfect occasion to pick things up again.


Everyone who has followed cyber news the past year will have noticed that data breaches, compromised credit cards, compromised online accounts and all kind of similar subjects are hot topics. Its only normal that online account security has increased for that reason, typically involving two-step verification (alternative email addresses, SMS verification and similar). This can be annoying (have you ever tried to sign in to your Microsoft account from a different country? Yes? Then you know what I'm talking about), but I think we can all agree that such extra security measures are necessary. Or at least that is what I thought, until today.....

Today I wanted to log in to my PayPal account, which I had not done for the past 6 months. After I correctly entered my login credentials, I was redirected to a page that explained me that, in order to confirm I am really the account holder, they needed to call me. Sounds simple enough, except that I no longer own the number that was listed there because I switched to a different service provider last year. And no, astonishing as it may sound, I did not immediately jump to my PayPal account back then to change my telephone number, much as I'd wish to, I don't have a database of online accounts that contain my phone number. I naively assumed PayPal, being a reputable company, would have an option that allows you to introduce your old phone number (which was mostly x-ed out in the web form) and replace it with an updated number.

After peering at the screen and all it options for 5 minutes, I discovered that PayPal doesn't offer that option, my only option was to contact customer service. Of course, to contact customer service they want you to log in, which consequently showed me the "phone verification" screen again. I finally managed to find an email address and contacted them.

Five minutes after sending my support request, including a clear description of my problem, I received an (automated) reply, explaining me that the solution is really simple, I just had to log in and change my phone number in my profile. Sigh.....
But, fortunately the mail also told me that, if this automated message did somehow not resolve my problem, I could reply to it and a support employee would get back to me. So, I replied, explained everything again and sure enough this morning I received a call from PayPal. A very polite support person verified my identity and gave me a security code that should allow me to reset my password, which should fix the problem. And, admitted, the password reset went flawless, there was just this one little problem; after successfully changing my password I still received the phone verification screen so nothing was resolved.

I sent an email yet again, and I naively thought that for sure it would be handy to send them a screenshot (one image can tell more than a thousand words). Handy or not, I promptly received a reply that explained how for security reasons (by that time I was starting to hate that term) they couldn't receive images in email messages.
Not giving up at that, I dutifully copy-pasted the message on screen and sent that instead. Ten minutes later I received another reply: they had removed the old phone number from my account so I should be able to log in now.
And true, the phone verification screen was gone. Now I just got the following:

Of course I mailed them again with the text of the error message. Ten minutes later I received a reply. They had tried to call me, but I hadn't replied, if I kindly could call them instead. I'm absolutely convinced they had tried to call me on the old number, after all I had only explained four times by then that it was no longer in use. But, me being an understanding human being, I gave them a call instead.

I really don't want to withhold what security verification they have on their support line (including entering associated bank account number and telephone numbers), but that would make this post even longer than it is already. After a lot of typing, retyping and please-wait-a-moment music, I finally got hold of another very polite support person. I explained them everything again and they went to talk to "someone" about this (in my experience that means: I don't know what the heck to do about this so I need to talk to my supervisor). After ten minutes they were back. They had found the problem. I was not logging in from the country where my associated bank account is registered. That is correct, and some years ago I already sent them copies of ID, utility bills and what not to explain that fact.

Okay, in that case the solution was real simple: I just had to go to the country where I have my bank account and when I'm there, contact them again. Sounds easy, but not if that is a country you don't live in for the most part of a year.

The support person gave me the following splendid explanation: "You know, this really is for your own good. At PayPal we hold security in the highest regard. This really is necessary with today's attempts at online fraud. The fact that we have imposed these restrictions on your account should therefore make you happy."
Because they already had handed me the solution to my problem and because I already had decided that keeping an account I use maybe twice a year for purchases I can make with my VISA card as well, is not productive, I only remarked that, nevertheless, it appears to me that having such tight security that it will lock out the owner, even though a number of checks have been passed to verify the identity of the account holder, is a bit pointless.


In Conclusion...

On the bright side: my account is so secure that even I cannot access it! Therefore I don't have any reason to be afraid an attacker will gain access to it.

On the not-so-bright side: after the remarks of the last helpful support person, I decided to do a very simple test. Working in security I have a VPN that allows me to select the country I connect to. I connected to the country my bank is located in, I accessed PayPal and sure enough I was able to reach my account without any problem or verification at all.

As a side note, PayPal doesn't like VPNs either, since I don't like PayPal very much anymore and already closed my account, I'm not too worried about that though... Oh, and we all know that real hackers never would be so sneaky as to use a VPN, TOR or something similar to commit their fraud right??

Oops, I guess my account isn't as secure as I (and PayPal support) thought...
SHAME ON YOU PAYPAL!!

Malware Myths

Undetectable rootkits, irremovable malware, firmware bootkits surviving multiple drive wipes, I read about all these subjects on a regular basis and I will dedicate this blog post to these so-called malware myths in the hope that it may help you getting a better idea of what is possible (and most importantly what is not possible) when it comes to malware.

First of all, undetectable malware doesn't exist. Simply put, if we can't find it it means only we don't search well enough. As no piece of malicious software can exist on air only, it will have a stored component somewhere (this can range from code in a patched file to a sophisticated encrypted file system). While this stored component can be very hard to detect (after all a harddisk is a large place to hide stuff), it is not impossible and in worst case a wipe of the drive will always remove it, no matter how sophisticated. If malware returns afterwards it is time to check out removable/backup media or the network/router a computer connects to.

Firmware malware
Firmware is typically a small piece of software coded directly into a device (for example a video card or DVD writer) necessary for the device to function correctly. This code is highly device-dependent, different manufacturers and different models all require specific firmware. For that reason a firmware infection is not only highly unlikely but also very impractical for a malware writer. Someone who wants to create a successful infection not only needs to make sure the malware stays on the system (by making it harder to detect and delete), but also that it is distributed on a large scale. Deploying a firmware rootkit on a large scale is close to impossible as you'd have to write a lot of different versions for different hardware models.

BIOS malware
This form of malware certainly exists and infects the BIOS firmware. The malicious code can be removed by flashing the BIOS or resetting the BIOS. However, I have never seen such an infection in the wild. Furthermore, while the BIOS firmware is a pretty good place to hide, the only BIOS rootkit out there (mebromi) has plenty of signs and can easily be identified on an infected computer. As already explained above the real problem consists of the various firmware versions there are. Mebromi targets Award BIOS only, which makes distribution difficult. Combine that with the fact that it is easy to spot due to other components of the infection (see article) and you have to reach the conclusion that, although it is a very advanced piece of malware and may be tricky to remove (in worst case you need to open up your computer and reset the BIOS manually by removing the CMOS battery), it will not be more difficult to diagnose this infection is on board than an average MBR rootkit.

RAM resident malware
I can be short about this one: malware surviving in RAM during a power-off is technically impossible. Yes, a malicious loaded driver could in theory still be retrieved from RAM using a so-called cold boot attack, but from there to a rootkit that launches from within RAM is a long way to go. Due to the way RAM is designed it is physically impossible to store the launch code for a rootkit there.

Finally, not every weird symptom is automatically caused by malware. If you suspect suspicious network activity or see suspicious files and processes be sure to research them. Look up the IP addresses you see as well as associated port numbers, search for information on files and don't believe everything you read on the internet. You'll find that about every file on your computer is listed somewhere as infected. It is very important to determine how trustworthy a site is that offers information on files.
An infection usually comes with clear symptoms: redirects, pop ups, fake messages, extreme slowness and so on. "Weird behavior" is not enough to conclude that your computer is infected, specially not after one or more reformats/reinstalls.


"I still don't believe you and I want to know how to reformat and reinstall my computer in such a way that all possible malware is gone."

1. Make sure your computer is not on a network and power it off. Reset your router and reformat all removable storage devices you have (including mp3 players, cameras).
2. Clear CMOS
3. Delete all partitions on your hard disk(s) and reformat using DBAN.
4. Turn your computer off after deleting the partition(s) and reformatting the disk(s) for about 5 minutes.
5. Turn your computer on and reinstall using a legal Windows CD/DVD. Alternatively use a free linux OS which will not get infected at all.

Why I don't recommend Linux rescue CDs

Most AV vendors offer one free for download these days; a <fill in the AV name here> Rescue CD.  The idea behind it? Scan your computer without booting in Windows, which can come in handy when malware is actively preventing removal (for example by blocking the tools you try to run, or by refusing to be deleted easily). It is also offered as option to clean a system that will no longer boot at all in Windows.

In theory that all sounds nice enough, in practice however there are a few serious problems. A Rescue CD is based on the (open source) Linux operating system kernel. That leads also the first problem; a Linux OS can mount an NTFS partition (which is the file system Windows uses) just fine. However it can't load the Windows Registry as easily. There are some Linux-based tools that can be used to access and modify the registry manually, but the registry cannot be loaded remotely as would be necessary for a scan. This means that the Antivirus or Antispyware scanner included on the rescue CD will scan the file system, but not the registry. Many types of malware use the registry in order to launch. For example a Run value that points to baddie.exe will load baddie.exe as soon as Windows has started and the user logged on. Both the file and the Run value that loads it are bad and needs to go. However, the rescue CD will only detect and delete the file. So, on next reboot Windows will still attempt to load baddie.exe but will no longer be able to find it. This will usually not cause a problem when it concerns a Run value (in worst case the user of the computer will get an annoying error pop-up on each boot), but may have much more grave consequences when it considers other registry locations.

A classic example is the Userinit value. Some (older) infections use(d) to add a file to that value resulting in the so-called logon-logoff loop if the file is removed without adjusting the value correctly. While it is not impossible to recover such a computer, it isn't exactly simple.

Another, more actual, example is the 64 bit version of the ZeroAccess rootkit which hijacks the Windows value in the HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems key so that it will attempt to load the rootkit component consrv.dll instead of the legit winsrv.dll file. If a scanner deletes consrv.dll without adequately adjusting the Windows value data, the computer will no longer boot and instead display a 0xc0000135 BSOD. Luckily most 64 bit Windows versions nowadays have the Recovery Environment pre-installed, which makes recovering from this error a lot simpler, but still, this involves a relatively complex registry edit.

Another issue you need to be aware of when scanning with a Rescue CD is the fact that any file can be deleted, even those that are critical Windows system files. Normally Windows Resource Protection will (attempt to) prevent the deletion of such files. In case a system file has become infected, it will need to be identified and replaced. Deletion will in many cases lead to unbootable or unusable systems.

There are many examples here, just a random one: if the 32 bit ZeroAccess rootkit infects i8042prt.sys (which is the keyboard/mouse ps2 port controller) and this file is deleted using a rescue CD the user of the computer will no longer be able to use their ps2 mouse/keyboard. Both will be completely unresponsive once Windows is loaded.

Does that mean a rescue CD is totally useless? I don't think so, you can still use it to diagnose/detect the malware you are dealing with. To stick with the i8042prt.sys example, if a scanner detects it as infected you can then replace it manually using the rescue CD (browse to a clean copy and use that to replace the infected file). 

My advice: if you want, use it, but use it wise and don't let it delete files but rather investigate what it detected and prepare a manual fix based on that. If you are not sure how to do that, then I recommend to look for help as doing it yourself may very well worsen the state of your computer.

             

"The Google Redirect Virus"

I have encountered this term in more different ways, shapes and forms than I care to remember and it continues to amaze me, because there is no such thing as a Google Redirect Virus.
Of course that is easy for me to say, but I suspect that if you have encountered or have become the victim of google redirects (because, contrary to the Google Redirect Virus, google redirects most definitely exist) you'll understand the term a lot better all of a sudden.

When googling "Google Redirect Virus" I get 18.300.000 results, but examining the first page does not give me a lot of clarity of what we're dealing with in fact.

First of all, what is a redirect? A redirect itself is not necessarily malicious. If I type in a site address and I make a typo, I can get redirected to the correct address. Nothing wrong with that. When talking about redirects in this post, I will only refer to malicious redirects
There are different forms of malicious redirects, but generally speaking, a redirect means that, when you use a search term in a search engine, either you get results that are in no way related, or when you click on seemingly related search results, you will be directed to an entirely different page than the one you think you are going to. Usually the page you are ending up at is either commercial in nature, or has malicious content that will attempt to infect your computer.

Next, what is a virus? A virus is a piece of malicious code that inserts itself in a legit file and can reproduce itself, thus having the ability to spread from one computer to another. More information in this Wikipedia article.

Why does it not make sense to talk about a "Google Redirect Virus"? Simply because there are so many different pieces of malware than can cause redirects. A redirect is a result, or symptom of a malware infection, it is not a cause (although it can become a secondary cause of infection by directing you to a malicious site). In most cases a redirect is not caused by a traditional computer virus but rather by other categories of malware.

A few examples of infections that can cause google (or other search engine) redirects:

• Router infections: when a router is infected, it usually means that the WAN DNS server addresses have been hijacked. The chance of this happening is a lot higher if you have not changed your default router password. A router reset should resolve this problem (afterwards any non-default settings like ISP usernames and passwords will need to be entered manually). The computer itself may or may not be infected.
• DNS hijacking: the same thing as router hijacking, except that in this case the DNS settings on the computer are affected. This usually only happens on computers that do not use a router to connect to the internet.
• Malicious Firefox extensions: the so called GooRed (Google Redirect) infection uses a malicious extension typically XUL Cache or XULrunner. Disabling/uninstalling the extension will fix the problem. A typical sign is that redirects only occur in Firefox and not in Internet Explorer.
• Hosts file hijacking: this file (typically located at c:\windows\system32\drivers\etc\hosts) contains a list hostnames and the IP addresses they should refer to. More information can be found in this Wikipedia article. Malwae can add lines to this file so that, when you type in a known/safe site's address, you will be redirected to a malicious IP. The fix is simple: remove the mlicious lines.
• TDSS rootkit variants: all TDSS rootkit variants starting with TDL3 cause persistent google redirects. For more information about this infection, see my blog post here (infected objects can be: patched system file, MBR or partition table).
• Winsock/LSP hijacking: many types of malware have used or use the Layered Service Provider in order to facilitate redirecting search results. An example that is seen much these days is the ZeroAccess/Sirefef rootkit (note that the LSP hijack caused by this infection is not its main component). In order to fix this hijack, the winsock catalog will need to be adjusted accordingly. Doing this incorrectly may lead to loss of internet connection.
• Patched system files: there are different infections that patch system files in order to facilitate redirecting. Examples are TDL3 rootkit (see above), ZeroAccess/Sirefef (see above) or Bamital, which infects c:\windows\explorer.exe and c:\windows\system32\winlogon.exe (XP) or c:\windows\system32\wininit.exe (Vista/7). In all cases deletion of the files is not an option and may cause even more problems. Infected system files need to be replaced with a clean copy.

A combination of techniques can be observed in many infections and removal depends completely on the cause. Just like a medic won't say to a patient who complains about a tummy-ache: "well, lets start removing your appendix and see if that has any result", we shouldn't apply solutions in hopes of having the desired effect without first researching what we are dealing with.

Two ways to adjust the Partition Table (an exercise in futility...)

After I made a mention last week about the latest TDL4 version which alters the partition table, I decided to try a few things to see how to manually do this. Note that this is NOT a fix for the latest TDL4 variant (for more information about this rootkit, see TDL4 rebooted | ESET Threat blog).

Repeating the steps below is at your own risk; if you are not sure what your are doing, this may result in serious damage. My recommendation for everyone who wants to try this, is to use a Virtual Machine (I use Virtual Box).

For this experiment I have used a VM (VirtualBox) with one partition, containing XP. I have used TestDisk to alter the partition table so that the boot flag for this partition no longer was Active. I also have written the TestDisk MBR to the drive to illustrate that the partition is still there and can be booted from. I then dumped the MBR using linux's DD utility (using xPUD live CD), after which I opened this dump with HxD hex editor. I used this to manually change the bootflag for the partition back to Active. Finally I restored this fixed MBR using DD, et voila...


1. Use TestDisk to change the bootflag

TestDisk can be used both under Windows and Linux (in this case I used the xPUD live CD). The hard disk showed up as follows in Testdisk (you can see here this is a virtual harddisk, created using Virtual Box).
After selecting the device, you get presented with some options. To see and alter partition information you need to select Analyse. After a Quick Search the following was displayed (see image below).

Next I used the arrow keys to change the bootflag from Primary and bootable (*, see left image) to Primary partition (P, see right image).







2. Use TestDisk to rewrite the MBR

To make sure I could test the altered partition table afterwards, I next
have rewriten the Master Boot Record with TestDisks MBR (this option is available after choosing the Device, see right picture). The only advantage is that this, when it doesn't see an Active partition or when it is not able to boot from the Active partition, will display manual boot yptions, as you can see in the left image below. The right image displays what happened when I pressed 1 at that point.
By doing that I forced the computer to look on primary partition 1 (as present in the partition table) for a boot loader. As this was present (on XP this is the NTLDR file), the boot process continued normally and Windows was loaded.


3. Dump the MBR with DD
While it would be easy to change the boot flag back to Active (bootable) partition with TestDisk (just reverse the steps under point 1), lets fix this another way than I broke it. For the next steps I used the xPUD live CD and an USB jump drive. In xPUD I navigated to my USB drive (usually present in the File menu as /mnt/sdb1) and opened a terminal. I executed the DD command visible in the image, which dumped the first 512 bytes of the drive (otherwise known as the MBR) to my USB drive as mbr.bin.

4. Edit the MBR dump to manually change the boot flag

Now that we have the MBR dump, we can open it with any (hex) editor. I used HxD hex editor for this. This is how mbr.bin looks in a hex editor (see image):

I have highlighted the partition table and color coded it for clarity. The first partition entry is yellow, the second green, the third blue and the fourth pink. Because this harddisk has only one partition, only one partition is present in the Partition Table.



In order to readjust the Partition Table so it will once again have an Active partition set, we can simply edit this dump. The bootflag for each partition is set in the first number of the respective partition entry (for the partition we need to adjust, this is 000001BE). The bootflag for the Active partition is 80, so we can simply edit the number in 000001BE and change it from 00 to 80. When done I saved the change I made in mbr.bin (to be sure I also saved the original as mbr.bin.bak) and transfered the USB jump drive with mbr.bin back to xPUD.

5. Restore the adjusted MBR

The only thing that remains to be done now is to restore the adjusted MBR and overwrite the existing MBR with it. We can do that in xPUD using DD as shown in the image.

The computer booted normally afterwards.

I hope that this example has helped you to gain an insight in how the Partition Table "works" and how you can adjust it.

TDSS in layman's terms

Since 2008 it has been a constant factor in malware-land: the TDSS rootkit (also known as Alureon rootkit).  

There is a lot of good in-depth information and analysis posted all over the internet, a few examples are TDSS - Securelist and TDSS aka TDL: A Botnet Framework. However, I often get questions from people who are looking for a simple description: how are the different variants being identified and what is the difference between them? For that reason I have posted this (very) general overview.

• TDL1: Classic TDSS; created a hidden driver service named TDSSserv, which loaded c:\windows\system32\drivers\tdssserv.sys

• TDL2: Same as TDL1, but the names differ and contain a random string. There are many different versions, each of them containing new tricks to avoid detection and deletion. Examples are UACxxxxx, SKYNETxxxxx, GEYEKxxxxx, GASFKxxxxx, H8SRTxxxxx, PRAGMAxxxxx (where xxxxx represents a random string).

• TDL3: The aim is to patch the hard disk controller driver (atapi.sys/iastor.sys) in order to get control over the system. Classic TDL3 directly patches atapi.sys on disk, later versions patch a random .sys file in the c:\windows\system32\drivers folder, which in turn patches atapi.sys in memory only, thus making detection/removal more difficult.

• TDL4: The aim of this variant is the same as that of TDL3, however instead of patching a file, the Master Boot Record is patched, which makes infection of 64 bit systems possible and detection/removal harder. 

• The latest version (at this moment still called TDL4) no longer patches the MBR. It alters the partition table so that its own hidden HPFS partition is set to Active. That way, when the computer is started, it will boot from the TDLFS partition, and load the infection from there, thus gaining control over the machine (it can then alter the MBR in memory and from there acts similar to TDL4 as described above). Fixing the MBR is no longer an option; the only way to fix this is to alter the partition table.

Next-best

Every once in a while I encounter users I am helping online to remove malware who tell me: "I think I will have this resolved by an Expert..." Usually this happens when things do not go as fast as anticipated. Said Expert usually is a form of paid support (whether that is online/remote support or a local repair shop).

This always makes me wonder: can you only be considered an expert if you are paid for what you do? That would be a discouraging conclusion, meaning that no matter how hard or how well I work in malware removal, as long as I do that on a voluntary basis, I'm still considered "next-best". Now I know quite a few people more knowledgeable and experienced when it comes to malware removal than I am, but they also are working as volunteers.

So, why does "getting paid" inspire more confidence than being a volunteer? I have no idea. I have my own "policy", which means that I do my best to help everyone as best as I can. I think I can safely say that I have managed so far to bring that in practice. If that is still not enough, then by all means, find an Expert...