Archive for February 2009
February 28, 2009, 4:22 pm
Its bad enough when Google can’t keep their G-Mail servers up. Its worse when they screw up causing all search results to have a security warning. Its worse again when they force you to fill out a captcha to perform a search because some algorithm has decided that you’ve searched to much, or searched for a suspicious term.
Now for the second time in two months I’ve been banned from G-Mail for up to 24 hours.
This account has been locked down due to unusual account activity. It may take up to 24 hours for you to regain access.
Unusual account activity includes, but is not limited to:
Receiving, deleting, or downloading large amounts of mail via POP in a short period of time.
Sending a large number of undeliverable messages (messages that bounce back).
Using file-sharing or file-storage software, browser extensions, or third party software that automatically logs in to your account.
Leaving multiple instances of your Gmail account open.
Browser-related issues. Please note that if you find your browser continually reloading while attempting to access your Inbox, it’s probably a browser issue, and it may be necessary to clear your browser’s cache and cookies.
If you feel that you have been using your Gmail account according to the Gmail Terms of Use, you can troubleshoot your problem by clicking here.
As near as I can tell, the only activity I have performed is leaving Gmail open on two or three computers. This 24 hour lockout is bull.
February 24, 2009, 11:27 am
Secunia has verified disabling javascript does not provide full protection against the zero day in all supported versions of Adobe Acrobat and Adobe Reader.
The current exploit seen in the wild uses javascript to perform a heap spray for code execution. The vulnerability is in in a non-javascript function call. The original alert put out by Shadowserver states:
There may be a method for populating the heap with the necessary shellcode without JavaScript, however if such a technique exists I am not aware of it.
Secunia reports that they have “managed to create a reliable, fully working exploit (available for Secunia Binary Analysis customers), which does not use JavaScript and can therefore successfully compromise users, who may think they are safe because JavaScript support has been disabled.”
Even without this method of exploiting without javascript, a SANS commenter has pointed out the potential problem of disabling javascript. When a user opens a PDF containing javascript, they are prompted to re-enable javascript by clicking yes. How many users are really going to stop and consider the source of the file before re-enabling javascript.
February 23, 2009, 12:46 pm
I saw this linked from Lenny Zeltser’s Twitter. Securology’s So you think you want a job in computer security.
The security operations all too true. Here’s part:
The worst part about SecOps is that you’ll either realize you’ve hit your Peter Principle with that job, in which case it’s time to spend all of your free time on backyard barbecues and retirement planning (nothing necessarily wrong with that — ignorance is bliss), OR, you’ll want out immediately because everyone around you has hit their Peter Principle highest job and you want more.
The post should be read in its entirety.
February 20, 2009, 10:37 pm
Adobe has posted a security advisory for the zero day in Adobe Acrobat and Reader that I blogged about yesterday.
They say they are
“planning to release updates to Adobe Reader and Acrobat to resolve the relevant security issue. Adobe expects to make available an update for Adobe Reader 9 and Acrobat 9 by March 11th, 2009. Updates for Adobe Reader 8 and Acrobat 8 will follow soon after, with Adobe Reader 7 and Acrobat 7 updates to follow”
Last time the updates for version 7 followed along about 8-10 months later if memory serves. Their little incentive for people to upgrade. I’m surprised they haven’t sunset-ed version 7 already. I’ve looked for software support life-cycle information from Adobe and haven’t found it.
The recommended mitigation for this vulnerability is disabling javascript until a patch is available. I’ve never seen anyone mention what effect that might have.
Every article says to disable javascript in Adobe through Edit -> Preferences -> javascript. In an enterprise you would want to know Is there a way to disable javascript in Adobe programatically (by pushing a registry entry via a login script, SMS or Group Policy).
Using Process Monitor from Sysinternals, I see that when you disable javascript in the GUI it sets HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\8.0\JSPrefs\bEnableJS to 0. Googling bEnableJS, I found that SANS ISC has a ADM file (used in Group Policy for the non-windows admin types) they posted during the last Adobe exploits back in November. It disables javascript for 6, 7 and 8 Acrobat and Reader.
February 19, 2009, 11:48 pm
As linked from SANS ISC, shadowserver is reporting targeted attacks using a zero day vulnerability in Adobe Acrobat and Adobe Reader. Versions 8 and 9 are vulnerable.
Disable javascript in Acrobat/ Reader to avoid the code execution vulnerability, however the application will still crash.
February 19, 2009, 3:20 pm
eWeek has an article “Macs Rebound at RAND”. The funny thing is the article says that this big rebound is from Macs being 20% of all systems to 22% of all systems. In their 2000 user environment this means this article was written because of 40 new Macs.
The article doesn’t get into what software they are using to patch much less perform whole disk encryption.
February 16, 2009, 1:06 pm
Since upgrading from SEP11 MR2 to MR4, my virus alert email to admins no longer works.
As a side note, SEP11 has never allowed me to include the path and file name in the virus notifications. They did allow that in SAV10 and earlier. This is a big step back.
Before the upgrade, the email was sent as system@servername. I believe my mailserver was helpfully making the servername fully qualified. The mail had no issues.
Since upgrading, the notifications are no longer getting through. According to the Symantec Knowledgebase, they did this on purpose.
As of SEP 11.0 Maintenance Release 3 (MR 3), a “.com” suffix has been addred (sic) to the “From:” address used by SEPM (SYSTEM@computer_name.com) which should help reduce rejections by the mail server.
Help reduce rejections? Help reduce rejections! How does sending mail as system@servername.com help? That is guaranteed to be rejected by anyone who verifies the sender is a valid domain name.
I’ve opened a case with support asking for them to fix this.
Symantec does not allow you to configure your own sender address in SEP11. They suggest you lower the security posture of your mail server by accepting email regardless of how invalid the From address is. Validating the envelope from domain is a common, easy antispam technique. I dont want to change it.
Looks like I need to add %Server_Name%.com to my internal DNS as a temporary workaround.
Another “improvement” in MR4.
UPDATE 2/17/09
See the comments, there is a way to do this afterall. I’ve asked Symantec to update the KB I referenced.
February 15, 2009, 3:11 pm
I upgraded my production Symantec Endpoint Protection 11 environment from Maintenance Release 2 to Maintenance Release (MR) 4. SEP 11 MR4 MP1 has been announced but it wasn’t available on Fileconnect yet. I also didn’t want to postpone my upgrade and install MR4 MP1 in the test environment.
My upgrade to MR4 was smooth in the test environment. Or course the production upgrade was less than smooth.
I stopped the SEPM service as directed in the upgrade instructions, but the micro def builder processes continued. This locked files, and the upgrade didn’t handle that condition correctly (force retry or replace files on reboot). The SEPM console couldn’t open after the upgrade and the recommended fix is to Repair the install in Add/Remove Programs.
After Repairing the install, I was able to log in successfully to SEPM but my clients were no longer checking in.
After fiddling around a bit, we found that the port used by clients had been changed. If you do an upgrade it keeps the port on 80. But the Repair caused the port to be changed to something else. So all my existing clients were trying to connect on a port that was no longer being listed to.
Symantec has a knowledgebase article on changing the port, so I followed those instructions to change the listening port back to 80.
So a couple things to watch out for
1) kill the def builder processes when performing a upgrade.
2) the Repair option is potentially a problem
3) if after an upgrade your client check in, go into IIS and see what port you’re listening on. If its the wrong port, check the Symantec KB for exact instructions on fixing.
February 12, 2009, 6:59 pm
The last couple of weeks I’ve been paying a bit more attention to our externally accessible systems (such as systems in the DMZ or systems on our external boundary). In the past I’ve run vulnerability scans weekly, but haven’t really paid attention to the systems that come on-line and the systems that go away. I also haven’t worried about whether the systems are authorized or not.
In just a couple weeks of paying attention, I’ve found some funny things. (not funny ha ha). A phone for conference calls was plugged into a jack that put it on the external network rather than the internal network. The best part, was the default admin password on the phone. OK, lesson(s) learned.
This week, a server came online on our DMZ that I hadn’t seen online in the past 2.5 months. According to my records the approval expired in November and they reported they no longer needed access. Apparently the systems administrator turned the server off when it was no longer in production. They turned it on this week to “take a inventory.” Unfortunately the system was still connected to our DMZ. Lesson learned, when approval ends, get the network guys to go to the patch panel and unplug that drop.
Fortunately neither case resulted in a problem, but it showed to me pretty quickly the need to pay attention to the hosts on that network beyond “is it vulnerable”. Should it be there is key as well. 
February 12, 2009, 8:30 am
I must be the only Infosec blogger in America not to have blogged about the Fannie Mae IT contractor….until now
For those who don’t know, a IT contractor at Fannie Mae was fired, but he was allowed to finish out the day. An indiictment alleges that he then planted malicious code inside a script. The code was placed at the bottom of a regularly scheduled script, with a page of blank lines designed to obscure the addition of new code from anyone who happens to look at the file. If run, it would have securely erased files and critical applications from the system. It would have replaced the shadow file to prevent their password management appliance from logging in. Lastly it disabled remote power-on, and shut the machine down.
A good writeup on the incident is provided by Larry Dignan at ZDNet. The complaint is located here.
I was thinking about that article this week because of a rumored RIF (Reduction in Force) occuring where I work. I’ve heard one person was informed on Monday that Friday is their last day. It seems to me that when you are allowing continued access for people layed off or fired that it would be a good idea to keep a close eye on what they are doing. If people are disgruntled, that is when they are going to plant logic bombs, create back doors or download all company files.
Even if you know who is disgruntled (due to layoffs, promotion denial or bad performance review), how do you track them? Varonis is one product that I’m interested in. From product pitch I saw, it would do a good job of letting me know if someone is trying to download everything on the file server or otherwise acting out of the ordinary.
Real change management would catch the malicious attacks. Something like Tripwire would report on the addition/modification of a file.
