Panda

You are currently browsing articles tagged Panda.

Q.P. – Random bits

February 6, 2009 in misc by Daniel Nyström | No comments

All was well at IT-SecurityWorld and I got a chance to say hi to Patrik Fältström at the end of the day. That was nice even though he gave me (and Panda ;) ) a small kick for not being IPv6 ready with our services. I have a feeling that we’re not alone though and all the points he keep making in the seminars I’ve seen him hold has always been very valid. People need to begin make the shift and stop being so comfortable as soon as possible.

In other news, the European parliament is about to vote on the Medina Report, which is going to set the direction for all future IP-rights enforcement work. It suggests, among other things, censorship of uncomfortable sites and traffic throttling. It also names The Pirate Bay as a primary target and this has not been well recieved here in Sweden as it can be considered interfering with an ongoing investigation and trial.

Not very nice. More information about this report and it’s ramifications can be found here:

IPTegrity – A Net dilemma for the European Parliament
IPTegrity – Libraries call to reject Medina report
La Quadrature Du Net – Copyright dogmatism ridiculously strikes the European Parliament

In other “work news” I recieved a request for comment on the surfacing issues of states implementing laws that make it legal for police to hack into computers and plant trojans from Christian Rudolf (Swedish site) over at Mjukvara.se (Swedish site). The question was if we as a security vendor would cooperate with the police in these situations and our position in this matter was summarized nicely internally when we discussed this:

Our position is that we will always detect all trojans to protect our customers, even if they pass a law to make a legal police trojan in Germany or anywhere else. If they take us to court of justice or make any type of pressure to make us whitelist their trojan, we will fight against it.

The americans have a typical phrase that fits well into this situation: “they’ll have to pry the detection signature from our cold, dead hands!”

It’s nice to see Panda Reseach and Labs have a sober view on this. Not that I didn’t expect them to, but the silence from some vendors are speaking for itself. The only ones responding to the inquiry on Mjukvara.se was Panda Security, Symantec and Avast. All of us stating that we would not whitelist any trojans. Ever.

Worth noting though is that there has been some trouble with this earlier with some vendors involving a specialized FBI-trojan called Magic Lantern. Let’s hope that the vendors that ignored this trojan change and follow up on their current promises.

And one last thing, I’m in need of some help from someone that knows virtualization (VmWare or similar). Working on setting up a multiple host, multiple network, multiple function solution and I would like to ask someone that knows more about this than me. So if you’re skilled and feel like giving me some quick A’s to my Q’s, please drop me an e-mail (daniel dot nystrom at icmpecho dot com) or comment on this post!

Cheers,

Tags: , , , , ,

My comments on Secunia’s exploit testing

October 20, 2008 in security, work by Daniel Nyström | No comments

Warning: Panda Security/work related post. This is a personal blog but from time to time I’m posting things may realte to my employer. Read “About this blog”.

EricGjerde on Flickr - http://flickr.com/photos/origomi/
Photo: EricGjerde on Flickr.

Weren’t going to comment on this really, but after reading up on all the different posts on the issue I’m feeling that some things are being missed. Specially if looking at Secunias CTOs (Thomas Kristensen) last blog post.

What I’m reacting to are these comments:

Our point is not that Internet Security Suites are useless (they are quite useful for most users). Instead, our point is that they protect insufficiently against hackers and that it is better to prevent attacks by patching rather than relying on other security measures alone.

When have we (the anti-malware vendors) said that our users do not need to patch? Sure we have protections that will catch things pro-actively, but that is meant for 0-day exploits etc. and is not meant as replacement for patches.

Also, our products (Panda Securitys) for home-users will scream bloody murder with annoying (but configurable) pop-ups if you do not have all MS patches installed. And I know that other vendors do this as well. Our corporate products also contain MalwareRadar which by default (not configurable) does inventory of installed patches and includes it in the report.

Next comment from Secunias CTO:

In my opinion it would serve the security industry well if AV-vendors would admit that the security provided by their products rely on a reasonably updated and well administrated system. If they really could protect systems without patches, then I’m quite confident that software vendors would stop making patches and instead provide these fabulous security solutions themselves.

Again, who said we do not need patches? Let me translate this to what I’m actually reading (my parody below):

In my opinion it would serve you guys in the anti-malware business good if you could tone down the “we take all proactively”-attitude so that we could make some money out of helping people see what needs to be patched. Also, plz be quick or Microsoft will start pushing this attitude as well and then I’m pretty much screwed.

But a bit more seriously. This is a publicity stunt and there’s no point in discussing it further. A company that publishes a report promoting their solution to a problem that has been incorrectly researched.

And when it comes to the test itself I think the other commentators have been too nice.

The methods used for testing illustrates great lack of knowledge on how to test client security solutions these days, and the worst thing is that I think they knew it. I can’t imagine the testers at Secunia being so stupid, when they’ve shown such skill before, that they didn’t realise that their methodology was flawed.

I mean, testing by scanning a bunch of exploit files? What are they after? That we detect their specific exploits by signature? Who would have anything to gain from that?

They then move on to say that we should detect exploits in a more generic way… Alright, how do you want us to do that? Look for shellcode in the files? Look for format exploit strings in the files? This is a false positive waiting to happen.

If we were to look for exploits (still, KNOWN EXPLOITS) we would have to first include a lot of new crap in the signature (as if it were not enough) and then implement detection routines that span whole files as we do not know where the crap might be. Good-bye CPU and memory, I’ll see you when your done…

The report really shows a total lack of understanding on how AV’s work today and the problems that we face with signatures.

What we and other has done INSTEAD is to create protections that “see” when an application does something it shouldn’t do or if it does something suspicious. These protections also monitor network traffic and can pro-actively detect and block traffic that shouldn’t bee there.

This is why a test against 300 files lying on your hard-drive do not give any accurate results whatsoever. Our protection stops genuinely active malicious code or applications that are being actively exploited by looking at the system and stopping things that does not look normal.

Ah well… Long story short this kinda ruins Secunia for me as an information resource.

For several years I’ve been using their web-based resources for unbiased information, but I guess that’s over now.

PS. Tired as hell now, so please excuse any linguistic or grammatical errors in the text above. ;) .DS

Tags: , , , , ,

Panda AdminSecure version 4.03 to be released…

September 8, 2008 in malware, security, work by Daniel Nyström | No comments

Panda Security - From Press graphics kit
Warning: Panda Security/work related post. ;)

… this week.

The main news in the 4.03 release is:

* Optimized console performance
* Reduced installation package size
* More auto-uninstallers for competitor products
* Improved update features for mobile users
* Full support for XP SP3 and Vista SP1
* Full support for Exchange 2007 SP1
* Full NAP support in our desktop protections

A lot of other news and bugfixes also included.

Ask you local Panda office for the complete document of changes.

If you’re a client you can download the upgrade here.

Cheers,

Tags: , , , , ,

Panda RAR-problems and n.runs

November 22, 2007 in malware, security, work by Daniel Nyström | No comments

WARNING: PANDA SECURITY CENTRIC / ANGRY RANTING POST -> See “About this blog”. ;)

Earlier on this month a potential “bug/security implication/design flaw/non-issue?” (the definition is not totally clear in this particular case) was reported to Panda Security by the security firm n.runs.

The issue at hand is that if a RAR-file header is formatted in a specific way, the contents of the archive cannot be analyzed by the antivirus kernel and as such might pass through perimeter defenses and actually be written to disk. Due to WinRar being extremely tolerant to illegally formatted archive headers (steganography someone?) this archive can still be opened with WinRar.

However, if the archive is extracted or if a file is run from it, Panda will have no problems catching it with either the signature based engine or the behavioural analysis engine. Of course there is also the possiblity of us not being able to detect the malware, but then why evade us? Our perimeter products would also catch these kinds of files if not reconfigured from default (content-filter->Files with inconsistent format, extension or MIME-type). However, if these settings have been changed, I see the attack vector more clearly. And of course, even if this is correctly configured it is not good that something possibly can slip by the signature engine.

This issue being reported is not a problem to us. It is a good thing and it enables us to provide better protection as we eliminate potential bypass vectors. What is a problem though (not only for us I think) is irresponsible disclosure. You can see Pedro’s thoughts about this here, but I’d like to share some of my own views as well.

As Pedro points out, most of the security problems reported to Panda by researchers or security companies are handled seriously and in a timely manner. This was also the case this time. In return for the diligence in response time and issue resolution, we do expect the reporting party to follow common policies for public disclosure, especially if the discussion and investigation of the flaw is still in the lab. This is for several reasons including (but not limited to) the security of our customers, the security of our customers (yeah, I wrote that twice), the continued cooperation with the security community in these issues and the open communication style used in these cases.

What n.runs did next while this issue was being investigated and its impact clarified was to publicly disclose the issue complete with technical details. As pointed out in this post by Kurt Wismer there are other issues with the document, but I’ll try to stay out of that discussion. I do however recommend reading his post as he is making some very good points not only in the article but also in the comments that followed.

The timeline for this issue was described in the Panda Research blog as:

Nov. 6: n.runs initial vulnerability report and PoC to Panda
Nov. 7: Panda acknowledges receipt and starts investigating
Nov. 13: n.runs publicly discloses Panda as vulnerable
Nov. 16: Panda sends comments on vulnerability and PoC to n.runs
Nov. 16: n.runs responds to Panda comments (fails to mention the issue is already public)
Nov. 21: Panda sends final response to n.runs

I understand that if you do not have a final response from the vendor in a reasonable time (that not being less than two month’s if initial contact is established), you might want to release an advisory or two highlighting the issues to pressure the vendor to provide a fix, but come on. That was surely not the case here.

Anyways, after seeing this behaviour I can’t help but wonder what motivated this line in their presentation referenced above:

“The solution developed by n.runs under the code name “ParsingSafe” will build on and work together with the customer antivirus products that are already in place or that are planned to be put in place ….. Based on this, the antivirus vendors are very important technology partners for our solution. The goal of the customer is still primarily to have the highest rate of virus recognition possible …..”

Could someone please explain to me how prematurely disclosing an issue like this can help our customers have “the highest rate of virus recognition possible” because I do not get it. Of course, the statement was regarding the goal of the customer. Not n.runs.

Whatever, my own opinions are probably just being clouded by me working with security professionally for such a long time. I remember back in the days when I was a kid and me and my “31337 h4×0rcr3w” threw out our newfound vulnerabilities as soon as we even saw a wiff of them. That was fun :)

Point made. Have a nice night :)

Tags: , , ,