by Michelle Couture
I received an email from Fidelity alerting me that my 401(k) account needed action. It stated that I needed to activate my account within 2 weeks or I would lose matching for the year. Being new to the company, I didn’t want to miss out on this opportunity. I remember thinking that it seemed a little strange considering no other company had imposed such a rule, but I thought, “Hey, maybe this company does things differently.” So I clicked and activated my account.
The next day I received an email from our security and privacy team telling me I had been phished. I was shocked. Nothing seemed fake or out of place. What now?
Sadly, nothing about this story is unique. Every day, people click on links and infect their devices and systems with malware. If you have a “team” monitoring your account, as I did, the impact can be minimized. But for a lot of people the consequences are disastrous. Do you think you would know what to look for?
According to a recent Verizon report, over 20% of people will click on a phishing email. The best way to avoid being phished is to always be on high alert. When I think about my example, I knew something was weird, yet I talked myself out of it and clicked anyways. It’s human nature to trust, and phishers capitalize on that. This is exactly why it is so important to be aware of the scams. That way, if something feels “off,” you know what to do.
In my case there are a few rules I now keep handy:
- Be aware of email requests with high urgency that ask you to take quick action. Phishers often prey on employee trust and will spoof executives to get you to comply with high urgency actions like wiring large amounts of money ASAP. Or in my case, losing my matching benefits if I didn’t immediately comply. As a rule of thumb, if you are ever in doubt, double-check the request with the sender either by phone or by composing a new email—never reply to the email itself.
- Never give sensitive personal or financial information over email. Trusted parties will never ask you for personal or financial information through email (e.g., social security numbers, account numbers, credit card numbers, passwords, etc.). Be cautious of emails that ask you to call a phone number to update your account information as well.
- If an offer seems too good to be true, it probably is. Offers of big bonuses, large payments or gifts (e.g., win a free iPad) are ways attackers try to get inside your head. If the promise is “too good to be true,” do some research into the individual or company before taking action.
- Think about whether you initiated the action. Phishers will try to spoof well-known companies to have you reset your password, update your account or track a shipment. Always be suspicious of unsolicited email, if you didn’t prompt a password reset — don’t click the link.
Just wanted to give you a heads up that if you or friends/family are looking to buy a new computer you may want to steer clear of Lenovo. They are installing a trusted certificate so they can see (MiTM) all your traffic so they can target you with ads better. But they are doing this for every site you visit, including your bank so who knows what information they can see.
On January 10, 2014 a vulnerability in ntpd, the Network Time Protocol daemon, was made public (US CERT VU#348126):
UDP protocols such as NTP can be abused to amplify denial-of-service attack traffic. Servers running the network time protocol (NTP) based on implementations of ntpd prior to version 4.2.7p26 that use the default unrestricted query configuration are susceptible to a reflected denial-of-service (DRDoS) attack. Other proprietary NTP implementations may also be affected.
I have encountered several vCenter Server Appliances, version 5.5.0 build 1476327 and older, that were exposed to the general Internet, and have been found to have this vulnerability. In these cases they were participating in DDoS attacks.
Yesterday I looked to the VMware KB to see if there were any security updates for these vCSAs, or mitigation approaches. Despite the vulnerability being over a month old there is no mention of it from VMware, nor is there a fix of any sort. The vulnerability probably extends to older versions of VMware ESX, too, if you are using NTP on them (as per best practices).
If you are running a vCenter Server Appliance I strongly suggest that you open a case with VMware Support regarding this problem. They have internal KB information about mitigating this. Ask them to search for CVE-2013-5211.
If you want to mitigate this problem on your own there are two ways to do it. First, VMware actually has public KB information in 1006427. It’s just buried (search that KB for CVE-2013-5211). Follow my steps below to edit the file and add their information.
If you want to mitigate the problem in a completely unsupported manner, but the one recommended by SANS and other organizations, you can SSH into the vCSA as root, and add “disable monitor” to /etc/ntp.conf. You can do this with the following steps:
- vi /etc/ntp.conf
- Move the cursor using the arrow keys to just below the entry called “driftfile /var/lib/ntp/drift/ntp.drift”
- Type an ‘i’ to put vi into insert mode. Don’t type the single quotes I use here, just the letter i.
- Type “disable monitor” and hit Enter.
- Type ‘ESC’ to get vi out of insert mode.
- Type ‘:wq’ to get vi to write the file and quit.
- service ntp restart
SPECIAL THANKS for this article: http://lonesysadmin.net/2014/02/13/vmware-vcenter-server-appliance-5-5-0-insecure-ntp-server/