Beating up on poor antivirus...

I've been reversing malware a lot lately (surprise) and I finally found something novel in a piece I can share.  Usually all the cool stuff is in non-releasable pieces and clients don't want their malware (even descriptions of its internals) shared with anyone).  To that end, I rarely if ever get a chance to blog about my malware adventures.  While this isn't super advanced, it is worth looking at if you've never seen it before.

So here's the code.

I don't do a lot of work in mainland China (or for companies hit by malware targetted at China) so this one took me for a loop.  After doing some research, I found out that kmon.dll belongs to a company called Rising Antivirus (http://www.rising-global.com/). Now other than the fact that their site looks like it was built on the old GeoCities platform (remember them?), I still didn't know the first thing about them.  Okay, I did know that they offer "Lion-Strong Security" and they are still selling the 2011 version of their antivirus software. Sounds "Lion-Strong" to me...

After a little more research (and lots of Google Translate), I found out that kmon.dll implements hooking routines and is injected into every user process that starts on the system.  Lots of security products do this for intrusion detection/prevention, it isn't just a Chinese thing.  Now that isn't to say I'll be installing Rising on any of my machines anytime soon, just pointing out what the product supposedly does is fairly mainstream.

So this malware has no interest in having an IDS/IPS DLL loaded in its address space (and I can't say that I blame it).  So before the malware does anything truly nasty, it attempts to locate "kmon.dll" as a loaded module.  Per MSDN (http://msdn.microsoft.com/en-us/library/windows/desktop/ms683199%28v=vs.85%29.aspx) GetModuleHandle either returns a module handle or a NULL if the module isn't loaded in the process' address space (e.g. the target isn't running Rising Antivirus).

Once the malware has a handle to the process it attempts to free the library using the FreeLibrary API (http://msdn.microsoft.com/en-us/library/ms683152%28v=vs.85%29.aspx).  The FreeLibrary call is used internally by DLLs as they are unloading so the process can unload their dependencies.  But some DLLs (such as kernel32.dll) are used by many other DLLs and shouldn't usually be unloaded.  To prevent premature unloading, Windows implements a reference counter.  FreeLibrary only frees the library when the reference count reaches zero.  Ordinarily this could be a problem for our malware code as it doesn't check the reference count.

Windows offers a sort of backdoor for unloading modules.  When GetModuleHandle is used to get a handle to the loaded library, the the reference count isn't updated.  By contrast, the normal method for obtaining a module handle is to use the return from LoadLibrary (which does increment the reference count).  MSDN even warns of this behavior as it can normally trigger some nasty bugs.  In fact, it may here too, but I doubt the malware author cares if she crashes the antivirus software.

So is the code broken?  Maybe.  If the reference count on kmon.dll was greater than one, then it's likely that kmon.dll would stay loaded.  Still, this code is neat and it gave me the chance to discover an AV vendor I've never heard of that's been around since at least 2011.

Tonight we're going to party like it's 1999!

All the cool kids are doing it...

So let's say you have a website you want to protect? Should you use .htaccess?  That's not a horrible idea.  A .htaccess file is good for basic authentication and is great because you can set permissions/directives at the directory level rather than the server level.  Yeah, you can set directives at the directory level in a server configuration file, but the .htaccess files are great when you don't want to give users access to the server level configurations. 

Enter Barracuda networks

Apparently .htaccess files are apparently how Barracuda networks administers their site.  I can think of lots of reasons for this, but none of them are good.  All of them emphasize usability over security.  Let's face it: usability is always at odds with security.  When you run a security company, I suggest you err on the side of security.  Reputations are hard to replace.  It's hard to sell security when you are making dumb security mistakes yourself.  The .htaccess files specify who can access what website areas while credentials are usually stored in a separate .htpasswd file.

  

Here's where things take a turn towards stupid

The first rule of .htpasswd files: never talk about .htpasswd files.  Okay, not really, the first rule of .htpasswd files is KEEP THEM OUT OF THE WEB ROOT!  For obvious reasons, the web server process must have read permissions to the .htpasswd file.  But if you store one in the web root, they can be stolen by attackers by navigating there in a web browser.

So what can you find in an .htaccess/.htpasswd file?

Among other things, you can find out where the most sensitive files and directories are.  That information would be located in the .htaccess file.  One of the great things about the .htaccess file is being able to see who the important users are.  Hint: they are the ones who can access a directory nobody else can.  Then you can concentrate your efforts on brute force attacking the passwords of legitimate users who can log in.  The .htpasswd file can reveal usernames and password hashes.  Combined with the .htaccess files, it's like a road map for an attack.  It can be like finding a copy of /etc/shadow, only for the web server directories it is protecting.

How easy are the hashes to crack?

Well, usually pretty easy.  Most use relatively weak encryption (salted MD5 or SHA1).  To put it easily, the protection on these is better than most unsalted MD5 hashes used by some poorly written sites.  For instance, go to eHarmony for a mate, not salted password hashes (eHarmony was one such site hacked last year that failed to implement basic security measures such as salting password hashes).

Well at least the hashes are salted, right?

Sure enough.  As long as you are using password hashes in the first place.  For ease of administration, the .htpasswd specification (rather myopically) allows for plaintext passwords.  But surely no serious company would use plaintext passwords, right? Well, that's where Barracuda networks comes in.  Apparently, they not only use .htpasswd files, but they also stored one in the web root directory.  Then, to compound things, they decided to make sure the passwords were stored in plaintext.  Since we all know people reuse passwords, this is a HUGE problem for Barracuda.

Best practices:

Before I go, here are a few thoughts on some best practices

• Avoid .htaccess files if you can get away with using server level configurations
• Don't trust security to .htaccess/htpasswd files alone
• If you use .htpasswd files, don't store the files in the web root
• If you use .htpasswd files, don't use plaintext passwords - it's 2013, not 1999

Reference:

http://thehackernews.com/2013/07/Barracuda-network-Password-disclosure-vulnerability_24.html

Edited 2013-07-25: Thanks to Ebrahim Hegazy (@Zigoo0) for pointing out an error in the posting here where I was ambiguously (and incorrectly) interchanging the .htaccess and .htpasswd file names.  The actual attack on Barracuda involved the disclosure of the .htpasswd file (the passwords/hashes), not the .htaccess file (the configuration).

Critical Budget Items for SMBs

I read an excellent TechRepublic post on things that an SMB should have in their budget.  I actually agree with most of the article's points.  For instance, they point out that buying hardware today, for today's specs, is a recipe for failure: couldn't agree more.  Consumer class printers don't meet business needs: agreed.  You need adequate Internet bandwidth: check.  You should have third party backup software that allows you to recover easily to bare metal: a must have for any SMB.

But where is security in this article?  Well, there is one specific mention of security: the recommendation to purchase a hardware firewall.  Okay, that's good I suppose.  I mean it certainly is good advice, but here's what's missing: consulting/technical/architecture services.

What are you selling?
I'm not selling anything, just want to share some common sense.  If you are convinced by this article to buy a hardware firewall, you don't have the necessary expertise in house to architect/configure/manage it.  The article points out that "not only are these devices far more secure, they are also more reliable and flexible."  And the flexibility is the problem in this case.  What they don't say is they offer the flexibility to shoot yourself in the foot.  You have to try to misconfigure your built-in Windows firewall.  You also have to try to correctly configure a standalone hardware firewall.  Installation matters.  Configuration matters.  You can actually make your business less secure by incorrectly installing a high powered hardware firewall.

Missed opportunities
There are some missed opportunities in this article as well.  For instance, you need security on your backup server/appliance.  As a penetration tester, I can't tell you how many times I've been able to compromise a backup server to get the goods stored on a server that otherwise wasn't vulnerable.

Also, what are the easiest ways for attackers to get in?  Social engineering and client side attacks.  I talked a little about social engineering in an earlier post.  Client side attacks are usually dependent on out of date software patches.  A centralized patch management solution is cheaper than many companies realize and does wonders for securing the computers.  Trailing close behind is a centralized antivirus management server.  This ensures all of your antivirus clients have current definition updates and similar configurations.

We're too small to be attacked
Whoa!  If your business is financially solvent (i.e. you are making money) you have something to lose. The simple fact that you are making money means you have something to lose.  Sure, others might have more to lose (making them better targets).  Those 'better targets' might also have better security, making them 'harder targets.'  Consider this: physical break in rates are lowest when on-site security guards are present, even though they have the most to lose.  Think about what competitive advantage you would lose if your competitors had all of your IP (business contacts, product designs, 50 secret herbs and spices, etc.).  This doesn't mean you should spend $1mil to protect $100k, that's just stupid.  But get real, consider what you have to lose, and spend on security like you are a target (because you really are).

Am I being socially engineered?

So the other night I get a call from a financial company with where I have an abandoned 401k.  You know, the kind where you work for a company for a few years and then leave it alone when you leave. The caller said that he was reaching out because I didn't currently have a financial adviser on the account and he wanted to set up a time to talk about my investment goals.  Fair enough.  I must have surprised him when I said "Sure, how about now."  He said, "Okay, I'll just need to verify some personal information before we can discuss the account. Can I get your birth date?"  Here's where I said "Have a nice evening" and hung up the phone.  Was I being socially engineered?  Probably not, but I'm not taking any chances either.  Let's step through this and see what smells wrong here.

Pretexting

Successful social engineering starts with pretexting.  Start by giving the victim a back story, or pretext, that makes your questions seem legitimate.  Why?  Because if I call you and ask for your birthdate and mother's maiden name you should tell me to take a long walk off a short plank.  You don't know who I am and I probably intend to do something bad with your info.  But these questions are perfectly normal when you call your bank.  In fact, you should be suspicious if your bank doesn't verify your personal information on the phone.  If I believe that I'm on the phone with the bank (the pretext), I'm more likely to reveal personal information to a complete stranger.  The social engineer hopes you forget who called who (or don't even think about it) and just give up the info.  Of course this pretext doesn't do any good if the social engineer calls from the wrong "bank."

How do they pick the bank?

We post a wealth of information about ourselves online every day.  In particular, sites like LinkedIn tend to have our work histories.  Given a company and the time you worked there, it's relatively easy to find out who manages the 401k (or other retirement plan) there.  That's who they call from.  If you say that you transferred all the money to your new retirement plan with your current company, well sir, it's your lucky day.  An audit of our records show the employer stiffed you on some matching funds/profit sharing/etc. you should have been entitled to.  People jump at the opportunity for free money, so that's a win.

But how did they get my phone number?

In my case it's on my business card.  If you don't have a business card, it's probably on pastebin from some site you registered with years ago. Do you have a resume posted online? Maybe the phone number is there.  Plus there are all sorts of sites attackers can use to look up your number for pocket change.  Finally, they can simply use the phone book.

Protecting yourself from this attack

Protecting yourself is pretty easy, albeit less convenient.  Don't given any information to someone who calls you. You should call them back.  Where should you get the number?  Don't, and I can't stress this enough, call the number given to you by the caller.  I've seen many a social engineering attempt resurrected when the victim says "I've been trained to only give information to people I call on verified numbers." But then they follow up by calling the attacker back on his "direct line."  Go to the company website and get a valid phone number.  There's usually an option to transfer to an extension.

Conclusion

So was this a social engineering attack?  Probably not, but I don't take risks like that.  The reason I suspect this was legitimate is based only on the fact that the caller initially asked to set up an appointment to talk to me rather than getting my information now.  But that is a good technique for putting me at ease about the situation.  Does it matter whether you get my information today or later this week?  Probably not. Even in the context of penetration testing, these engagements usually last a while.  He has time to wait.