Posted on Fri, Feb 17, 2012
In Part 1, we discussed the definition of malware; provided an example of how easy it is to get malware onto your computer; and detailed several caveats on proactive steps to take and also what to look for to avoid being victimized.
This post focuses on email issues that could cause damage. Every day we see links into spam emails; the email per se may be clean; it may just be spam and not necessarily malware infected but it contains a link (with the name of the link masked). Here’s a recent sampling – an email contained a link presumably to a downloadable PDF file, when in reality, the actual (embedded) link would send us to a web server hosted in India. Naturally, we didn't click through to see what awaited on the other side but this is yet another example of how hackers can mislead users into clicking on something thus causing harmful code to be downloaded and installed.
At first look, these emails generally look official and realistic – they may appear to be coming from the U.S. Internal Revenue Service; another may state that your wire transfer was ‘blocked by the Federal Reserve‘; and the list goes on. Furthermore, they're often seasonal: case in point being the IRS look-alikes which tend to be distributed after April 15th for obvious reasons.
You may also have seen emails allegedly coming from your ‘bank’ requesting that you verify a transaction and/or personal information. By clicking on the email, you'll either cause something to be installed on your machine; or you’ll be redirected to a web site that looks remarkably similar to your bank BUT it is actually a reproduction hosted on a rogue server and the sensitive data you’ll be asked to enter can (and will) be used to quickly steal a lot of personal financial information.
Last year, we all heard about the RSA breach (http://www.nytimes.com/2011/06/08/business/08security.html?pagewanted=all). This entire series of events was started by an employee clicking on a link in an email that appeared legitimate. This case was different because the hackers launched a very focused attack – the email seemed incredibly genuine; the user clicked; and a Trojan was downloaded. Said Trojan went to work, and stealthily downloaded a larger piece of code, which scoured the LAN for the specific information the hackers were after. But again, the whole thing started simply because someone clicked on a link they should have avoided!
For the most part, all of these email scams have one common agenda – to steal something be it personal data; corporate information; or customer particulars.
Part 3 will cover the various methods that malware can infect a network.
As always, if you have any questions, please contact me at pierluigi.stella@networkboxusa.com.
Posted on Thu, Jan 26, 2012
If even a small minority of all the hackers out there focused their intelligence, inventiveness and imagination away from malware and into constructive web-based endeavors, we’d all be better off.
That said, don’t hold your breath. Malware is an ongoing problem and scourge to both public and private entities and you need to understand what it is and how to deal with it. It’s a huge topic so I’ll break up the text into multiple posts.
First of all, you need to know what malware is – executable code that runs on your computer and is designed to cause some sort of damage – either by harming your data or stealing it. But the operative word is ‘executable’ – it’s a program, therefore it has to be activated, and in most cases requires someone unknowingly installing the malware and running it.
Hackers are constantly looking for new ways to trick users into ‘clicking’ on something – and that simple one stroke click can activate the software and quickly start wreaking havoc.
Last month, for instance, we decided to test a computer sans any AV/malware protection, went online and started browsing. We checked out Google for Indian flags and clicked on one – suddenly messages popped up that allegedly were from the operating system stating that the disk was broken, partitions couldn’t be found, and other formidable looking warnings. All looked legit.
Then an alleged Microsoft tool popped up offering to ‘scan’ the warnings. I know what the real program looks like – this one was an almost identical clone but there were obvious clues that it was a fake. But since we were running an experiment, we followed along, clicked, and the program claimed to have scanned our entire system in less than two minutes. Of course, it found several issues that required an immediate fix, and up popped another screen requesting gobs of personal information, including a credit card number – to purchase the software and fix the computer.
We downloaded a Kaspersky emergency cleanup tool and cleared the virus, but even when the computer was clean we still couldn’t access our data - the scanning tool had set the hidden attribute to all files on the disk, OS, data, programs – everything was hidden and it appeared that the disk was empty. Once the hidden attribute (attrib-h) was removed, the system was restored.
But you can also get dinged from stealth programs that read what you type – known as keyloggers. Fortunately this is becoming less commonplace as good AV software will become aware of keyloggers by their behavior. There’s also software that functions as a browser add-on that can protect your secure websites – if you try to do online banking, for instance, and you’re not connected to the right IP address, the software will stop you.
Lastly, beware of malware being distributed now via HTTP – rather than hand delivering a nice little virus to you via email, the hacker will place the code on a web server and entice you to go a particular website. In most cases, these are legitimate websites that have been compromised – unbeknown to the site’s owners. A script attached at the bottom of the home page index.html file can add hidden links to this page which the user won’t see. So while browsing, the mouse causes a piece of malware code to start running, it’s installed on the computer, and the hacker’s off to the races and starts pilfering your data.
Getting a bit nervous? Stay tuned for Part 2 where I’ll wax eloquent on malware and email issues.
Posted on Mon, Dec 12, 2011
Previous posts about cloud security have covered a wide range of topics and issues; some of these have included tips on connecting both private and public clouds; cloud computing security risks; pointers on the pros/cons of the hybrid cloud model, and more.
This post will focus on a growing concern that is facing both public and private sector organizations, not only in the US, but globally –identifying a few security holes affecting cloud implementations, and what steps you can take to mitigate these from becoming a major digital thorn for you.
And amazingly, I still see examples of servers with default user IDs that are untouched, default passwords that are never changed – and in extreme cases – no password set up at all! So there’s your data in the cloud with a login prompt totally exposed – no protection, no password/user/access authorization rules. It’s enough to turn an IT manager’s hair white overnight – and result in many a sleepless night to boot!Organizations from all walks of life are migrating to the cloud, principally to reduce costs. But many don’t factor in an important consideration – they lack the internal resources/skills to initially determine how to best protect their data, and once the data’s in the cloud, how to then protect it on an ongoing basis.

Before you jump to the cloud, you also need to figure out who’s going to provide security. Should your IaaS provider offer a certain level of security? Have your MSP using that IaaS do it for you? Do it yourself?
All of the above. The IaaS, for instance, owns the address space- if your network/server is compromised, it will appear from an outsider’s perspective that the IaaS’ address space has been compromised. And not only can the telco snatch those IP addresses from the IaaS, but the federal government can close down the servers and lines, which means the IaaS could be hurt financially and even forced to close its doors.
So how can you patch these potential holes so your organization’s data isn’t put at risk? Here are a few simple tips:
✓ With any kind of remote connection, lock it up and use a VPN, e.g., such as a certificate based SSL with AES256 encryption.
✓ Conduct due diligence with your MSP and IaaS.
✓ Check out the hardware side of your virtual environment and make sure your virtual neighbors can’t accidentally access your data.
✓ Trust no one and make sure that your LAN is yours and yours alone!
Any questions? Email me at pierlugi.stella@networkboxusa.com.
Posted on Fri, Oct 28, 2011
In two previous posts, we discussed tips on connecting private and public clouds; the first as an immediate extension of a company’s data center, the second as a way to offload hardware costs, maintenance and any other issues to someone else, share the burden and lower the overall costs.
As it turns out, several companies are choosing a mixed model, which is being called the hybrid cloud.
The idea is, some companies don’t trust public cloud security enough to entrust their most sensitive data to it, but they still want to use it for some data or some applications; and at the same time they want to use the concept of the cloud for the sensitive data, so they build a private one, where they feel they are more in control of processes, procedures, security and anything related to it.
There are several points to consider.
As a security professional, my thoughts go immediately to the question – who says that the public cloud is not as (or more) secure than the private cloud? Assuming this would mean assuming that the company has security experts on staff that are absolutely certain of their ability to keep the company safe. Many companies can’t afford staff that’s trained in security matters; and most of the times security ends up in the hands of network engineers, whose training doesn’t allow them to properly address the security posture of a company.
As a managed services provider, we see this repeatedly: Networks that have all the tools necessary for protection, but are not protected because they are not configured properly; because the procedures are not in place; because the firewall is configured to the convenience of the network engineer and not to the dictates of security best practices.
So stating that sensitive data is better protected in the private cloud than in the public one is not necessarily a correct assumption.
This of course, assumes that the public cloud is protected. There are many different offerings for public cloud in the market today.
Some companies offer a protected cloud. They have a team of security trained experts, who establish processes and procedures, and are in charge of ensuring the security of the entire cloud offering.
Some public cloud companies do not offer any security at all. They simply sell IaaS. You just purchase the use of hardware from them. The advantage of this offering is price – usually you will be sharing the load with several other companies and pay only what you consume. There is a company (6Fusion) that has actually invented a method for calculating how much of the hardware resources a customer is consuming, and charges based on a concept similar to the power consumption at home – the KWh; in fact, they call it WAC. 6Fusion doesn’t offer anything but hardware; their customers are MSPs, who in turn build solutions for their own customers. The security of each solution is entirely left to the MSP.
There may be instances in such a case where the customer could be better off keeping sensitive data in house (assuming in house security is at least decent); or maybe they could both (MSP and customer) seek help from a company such as Network Box, which provides virtual managed security that is perfect for this type of offerings. In fact, Network Box has been a valued partner of 6Fusion for almost 2 years now, and we can count several of their customers as our own.
Posted on Mon, Oct 03, 2011
In last week’s posting, we focused on the private cloud. Let’s talk about the public cloud now.
In a public cloud, the infrastructure is shared and the location of that infrastructure may be unknown. The customer has no physical access to the infrastructure. Its data may be stored on a dedicated disk, but most likely it is not; everything is virtual. So the data is on a virtual disk and it appears isolated from other companies’ data, but physically it’s probably hosted on a very large array of disks set up in batteries of RAIDS shared among all the customers using that facility. The same happens for the servers, the switches, the firewalls and anything else being used in this infrastructure. Nothing is really as it appears; everything is virtual and shared.
This of course allows much greater savings than the private cloud, because a single physical server can be shared among several customers, and the same goes for disks and any other resource in the datacenter. There is no private cage with reserved racks and computers; everything is shared and the only thing that keeps things isolated from one customer to another is the VM software running the virtualization.
Companies offering this solution have adopted different business models. Some offer redundancy and backups included in the cost of the servers; some do not. Some companies are truly virtual in that the server’s location may be unknown; some specify precisely where the server is. Some companies rent out a physical server per customer, defeating in a way the scope of virtualization and going back to the rented physical infrastructure of many years ago.

Then there are several companies that have come up with software to measure the actual use of resources, so that customers can be billed based on the actual use rather than on a reserved amount of CPU or disk that they may never have used fully. Since the resources are shared, they are dynamically allocated to the various customers, and therefore allowing each customer to pay based only on actual usage seems like a fair business model, which helps reduce costs for the customers even further and making the provider economically more competitive.
With the public cloud you get away from having to deal with hardware altogether. No more hardware costs, amortization, obsolescence; no more A+ certified personnel to maintain that hardware; no more technical issues to deal with. Outsourcing is not new. But this is a form of total infrastructure outsourcing that makes a lot of sense for basically anyone. The private cloud model defeats the purpose, as it implies maintaining the same old model of having to deal with hardware issues in house. The advantages are too little when the savings of not having to deal with hardware are not properly realized.
Leveraging the cloud in its true sense can only be achieved using the public cloud; delegating entirely the issues of hardware to an infrastructure in the cloud vendor and getting away completely from having to deal with any hardware issues.
Nevertheless, since private and public clouds are a reality, how do we connect private and public clouds? The only logical way is via a VPN.
Too many companies, especially small companies, are connecting to their public cloud via remote terminal connections. This is not safe; unless you can set your firewall rules to allow only specific source subnets, using RDP means exposing a Windows login to anyone. And hackers have all the time in the world to attempt breaking that login. Your protection in such case is only as strong as your weakest password. Such logins should not be open to the public; it should be protected behind a VPN.
A site-to-site VPN is typically built using IPSEC; although devices such as Network Box nowadays support site-to-site SSL VPN, which in my opinion works much better. Eventually, as more and more vendors start supporting site-to-site SSL VPN, IPSEC will disappear; it is clunky and messy, routing through it is not the simplest thing, and it is sometimes rather unstable. SSL has none of these issues, and provides numerous advantages. It is very stable and routing is very simple. You can even set BGP through an SSL VPN; large networks that use dynamic protocols internally can take full advantage of this possibility, which is not so simple (if not impossible) with IPSEC.
Depending on the type of services hosted on each side, remote access software such as Citrix should be considered as well. It offers adequate security, nice wire speed, simplicity in its set up, and although it shouldn’t replace the VPN option, it can certainly complement it at least for users who do not have a need for complete access to a network but simply need to access a handful of applications. There are many competitors emerging, thanks to the cloud offers.
To connect the customer premises to the private cloud a VPN can be considered as well, though many companies are adopting other options, such as MPLS. This creates a private connection from the office to the private cloud, and ensures security of the communications. But it cannot usually be adopted to connect to the public cloud because in that case the Internet link is not under the control of the customer but is provided as part of the infrastructure by the hosting provider. Therefore VPN is basically the only real option.
Got any questions on private/public cloud security issues? We're more than happy to address them - contact us.
Posted on Tue, Sep 27, 2011
A tool that cracks SSL cookies in ten minutes was recently introduced at the Eckoparty security conference. The tool is called BEAST, which stands for Browser Exploit Against SSL/TLS. It works only with TLS 1.0 and not with TLS 1.1; although, most of us are using 1.0, whether we know it or not. The 1.1 version is not widely used yet. Click here to read more about how it works.
While it is not simple to immediately achieve the exploit, the article mentions that the tool is a Java script which needs to be injected into the victim's browser - something we unfortunately see all too often: hackers have done it, know how to do it, will continue doing it. So, the attack is not necessarily easy, but it appears feasible.
Granted, this is merely research that is demonstrating the possibilities of cracking SSL cookies. This has yet to be done by hackers in a real-world application. How many times have we seen this before? How long will it be before this becomes a real threat?
Computers become more powerful every day; as a consequence, encryption becomes easier to crack. The 128 bits encryption used in VPNs was quickly replaced by AES256. AES256 was designed to last well into the 21st century because the computing power it requires to be compromised is such that no existing commercially available computer can crack it in a meaningful time. And that's, ultimately, what we want. It may never be possible to create encryption that cannot be cracked; but, if we can make it hard enough that no computer can crack it in a human lifetime with the current computing power commonly available, then we should be OK. Of course, in this constantly changing, fast-paced technology era, as computing power increases, the time it takes to crack an encryption algorithm decreases. That is why we went from 64 bit, at the end of the 20th century, to 128 bits, which we still use today. It has only been 11 years, but maybe it is time to move to 256, before someone comes up with a way to use the BEAST as a hacking tool and we start losing some serious data over HTTPS.
Posted on Mon, Sep 26, 2011
Ask someone what the difference between a private and public cloud is, and most will probably elicit a somewhat confused expression.
With that in mind, I thought I’d elaborate a bit on some of the key attributes and differences for each. Part 1 will focus on the private cloud. Next week’s posting will concentrate on the public cloud.
In brief, a private cloud usually means a reserved space in a data center, with lots of racks full of computers, possibly surrounded by a gate to isolate them from the rest of the datacenter.

This basically means that the company has moved its data center to a remote facility rather than keeping it on premise. The advantages are many - a data center requires redundancies for Internet, power, fire emergency and it requires adequate access control. Putting together a dedicated data center for one company is very costly. It is not just the cost of the infrastructure necessary to support the mentioned redundancies; it is also the cost of setting up the necessary access procedures and controls, keeping a log of such accesses, ensuring procedures are followed and protocols are met. Then, getting certifications (such as SAS70) adds to the costs.
Delegating this to a company that does it as its only business means sharing these costs with all the other customers, and obtaining a far stronger infrastructure for a fraction of the cost. You get multiple internet links coming in each on a separate pipe, and using BGP you are guaranteed an up time of 99.99% without too much effort. You get multiple UPSs, not just one, each fed by multiple, cross connected power sources. You get multiple power sources, generators always on standby, and guaranteed gasoline refills. Usually these facilities are on the emergency refill list just after hospitals and few other high emergency facilities. And they are hosted in bunker facilities not easily expunged. Finally, security is strict, adopting a mix of bio and badge technologies, keeping logs of who walks in and out and when; checking people’s bags for content; tracking closely which hardware is brought in or removed. Some of these facilities may also have DOD clearance.
The cost of hosting a company’s infrastructure in such a center is lower than building it from scratch, and the results are better. Today the cloud term is used and abused, and many companies have taken to calling this solution the private cloud. They are no different than they were a few years ago. Only the terminology has changed.
The introduction of virtual solutions has changed the way this private cloud is structured internally and probably allowed the reduction of space and increased companies’ savings; but the substance remains the same.
Posted on Mon, Sep 05, 2011
This morning, I was reading some comments on the Diginotar breach. The Dutch minister of internal affairs gave a press conference at 1:15 AM, Saturday, September 3rd. He announced that the Dutch government was revoking trust in Diginotar. News about this breach can be found here. If you "google" it, you will find plenty of information on the topic.
There is a lot of speculation on the source of the attack, though, at this point, many are speculating it to have originated from the Iranian government. There is plenty of information around, so I will not dwell on providing further insights. My main reason for writing this entry is to discuss "user behavior."
When you browse an HTTPS website, your browser and the server exchange a CA certificate. CA stands for Certificate Authority. There is a reason for this name - the entity who created the certificate is "authorized" to do so. It has the authority to create public certificates; it has an infrastructure in place to guarantee that such certificates are original, and to revoke them when they are not. Browsers take notice of this and when a certificate is revoked, your browser receives an update so it knows not to trust that particular certificate anymore.
These certificates usually carry the name of the website; for example, if you go to https://mydomain.com, you would expect the certificate to carry that domain's name in it. So, if you reach the same server via its IP address, instead of its name, the browser will issue a warning saying something like: "This certificate name does not match the URL you were trying to reach." Now, it is up to you to accept the certificate anyway - to trust it - or to move on and browse somewhere else.
The unfortunate truth, of which I myself have been guilty a few times, is that even though the browser gave us a warning, we tend to pay little attention to it. We click "get me there anyway", and keep going.
This allows a hacker to conduct what we call a "man-in-the-middle attack." That little and, apparently, insignificant warning your browser tried to give you might have been related to the fact that you didn't really reach the intended site, but another, rogue, server. And ipso facto, you have been attacked and your computer might have been compromised.
The same situation can occur if you are trying to VPN to your office with a clientless, browser based, VPN. Assume you are in a public place, a coffee shop for example, or at the airport. You attempt to logon to the VPN via your unprotected wireless connection; someone with ill intentions is in the same area, sniffing the airwaves with an automated tool (there are plenty on the internet, all free), and when it intercepts your attempt, it sends you a different certificate, conducting a man-in-the-middle attack. In essence, your computer "thinks" it is talking to the VPN server when, in reality, it is talking to the attacker's computer. Your browser will give you a warning, but you are too busy to notice, get annoyed by the warning, click OK and keep going. Now the attacker is talking to your computer pretending to be the VPN server, and it is talking to the VPN server pretending to be you. So all your communications back to your office, which you assume are encrypted and well-protected, are actually flowing through the computer of your attacker. He can record them and decrypt them (remember, you are using his certificate so he can open your conversation), and basically steal all the information that is going across your communication.
What can you take away from all of this? If your browser issues a warning about a certificate, don't ignore it. Read it, read it carefully, and if in doubt, abort what you were doing and call for help. It may be nothing; but it may be something very serious indeed!
Incidentally, this is also the reason why, at Network Box, we have been resistant to the idea of a clientless SSL VPN. They are easy to deploy and maintain, but they are subject to these risks (among other things); and therefore they cannot guarantee 100% true security. Additionally, since security is what we do, we have been cautious about this feature. The market wants it, and therefore we may eventually give in; but with the warning that such issues may occur because of the way browsers work and because of the way we all, as humans, tend to behave. After all, hacking is 90% exploitation of human behavior. But that's a topic for an entirely separate conversation.
A good week to everyone who reads this post.
Posted on Wed, Aug 24, 2011
Michael Gazeley, General Manager of Network Box Corporation, LTD, was interviewed by Bernie Lo regarding the recent high-profile hacking attacks on the Hong Kong Exchange.
Posted on Sat, Aug 20, 2011
Last week, I reported on how Z-Scan, Network Box's real time cloud based antivirus, is shifting the paradigm in the battle against viruses and helping us create signatures in seconds, when traditional AV companies still take several hours for a single signature.
This week we can proudly report that, after one year of field use in the war against viruses, this same technique is also being applied against spam.

The malware traps we have deployed are simply fake email addresses; what they receive is either spam or malware. It is, therefore, a natural progression to apply Z-scan spam, as well. When a new email arrives without an attachment and nothing malicious, we know it is spam. If our other 24 anti-spam engines do not recognize it yet, Z-scan creates its usual hash signature, but, this time, it is not used by the antivirus. The Z-scan anti-spam, as a 25th engine, will flag this email as spam, and from that point on, all Network Boxes globally will do the same.
Later on, our expert team analyzes the email and creates signatures that our 24 engines can use to block that same email. But, in the mean time, our customers have been spared the nuisance already!
Now the challenge is on.
In September 2010, when we first deployed Z-scan antivirus, we were running around 100 signatures a day. Today, that number has gone up all the way to 300 thousand! Three hundred thousand pieces of zero-day malware!
Today Z-scan antispam has only 597 signatures. I am certain that very soon, this number will grow exponentially as spammers increase the onslaught.
Network Box has 25 engines to protect customers from spam. Our spamtraps show that our success rate is currently 99.7%; a figure that is truly hard to beat as is. With Z-scan anti-spam, the rate will grow even closer to 100%.