security

From akeg on Flickr.

From VNUNET via Packetstorm:

H D Moore, who crafted the original DNS exploit module, said in a blog posting that an attacker managed to run the cache-poisoning attack on a server belonging to AT&T’s internet service in Austin, Texas.

As a result of the attack, servers at BreakingPoint Systems, the network security firm which employs Moore as director of security research, redirected employee machines from Google.com to a third-party site loaded with advertisements.

Apparently no real damage caused by it for them, but there must be loads of other users on AT&T’s DNS-servers.

I’m all for full disclosure but this is really affecting a lot of people. We are seeing a big increase in infected computers and the DNS flaw might be what’s behind this (but I have no concrete proof of it).

Anyhow, admins at larger ISP’s better get patching now if they haven’t started already.

Cheers,

is without doubt the hands-on management aspects of the whole suites.

Every month I read news, blogs and press releases from both vendors and independents on detection effectiveness. Sometimes these news are about the accuracy of the vendors signatures, sometimes about the files the sig’s missed, sometimes it’s about the vendors brand new and shining behavioural analysis engines. But it is almost never about the technical management features of the products. What eventually makes the news in this aspect is either the new administration consoles that pop up every two to three years or if something fail in a spectacular fashion.

That kind of information is not really as newsworthy as a remedy to the latest threat, but one thing is for sure and that is that it doesn’t matter how good the detection ratios are if the client protections remain unmanaged, defunct or unlicensed.

Most of the time this is not a problem in larger networks where the appropriate funds and technical resources has been allocated, but if reviewing smaller companies or organizations (<500, sometimes larger) without dedicated security management you will often find problems.

The problems range from client communication malfunctions to management servers dropping dead for no particular reason. Often, these issues requires human interaction to resolve and this in turn increases the IT-services overhead. Sometimes this happens with our (Panda Security's) solutions and sometimes some other vendors (I consult for another company in the PCM Group and meet a lot of different environments).

I’m not saying this is the AV vendors fault, as it often turns out to be erroneous customer configurations and/or secondary system malfunctions (thank you Microsoft for your most excellent AD/DHCP/DNS solutions, thank you).

My point is that these problems, from a software point of view, should be a calculable risk.

People will make mistakes. People will be incompetent. People will be lazy. People will “install and forget”. People will be People. And we should be better at understanding and counteracting these factors.

The latest versions of Panda AdminSecure has some of this in functions that repair failing client protections automatically, but it surely is not enough. People should not be able to set permissions or deactivate polices that might be a danger to the protection functioning without some serious alarm bells going off. People should not be able to setup firewall policies that cripple the communication required and by that degrading the level of protection without the central management consoles showing large red flashing screens. If something is done by a Microsoft patch which might or do disrupt the correct functioning of any server components, the management tools should be able to tell the administrators this in a reliable fashion.

Surely there are those that think that this is complete bullshit and have the “if they’re morons and fail, plz let them burn” attitude. These people are ignorant of the overall picture and do not understand the underlying problem.

If there were no unprotected (not installed or malfunctioning protection) clients, there is a much smaller market for “corporate” malware creation. One effect of this is less money for the bad guys. Less money for the bad guys means they have less money to spend on maintaining developing new malware.

And of course, Less malware development => good for all.

In conclusion,

Security systems is all about reliability. How come AV’s are lagging on this particular point?

Users and less experienced technicians are unpredictable, but how hard can it be? We have built engines that can detect hostile code based on behavior, why not do the same to the admins

Geeks.com, certified as “hacker-safe” by ScanAlert (McAfee), has been hacked.

From ComputerWeekly.com:

Reports say Geeks.com sent out a letter at the weekend to its customers, admitting that customer information, including names, addresses, telephone numbers, e-mail addresses, credit card numbers, expiration dates, and card verification numbers, may have fallen into the wrong hands.

As a comment in this article mentions, this incident once again highlights the issue of encrypting customer data. Not “only” to secure the customers creditcards but also to stay clear of lawsuits and other liability issues.

I think I read somewhere about this being a requirement for this kind of vendor/merchant:

3.2.2 Do not store the card-validation code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions

Well well, this is yet another wake up call for those that are not yet handling their data the correct (secure) way.

Cheers,

so did a lot of serious security incidents.

During last week, we saw…

- The largest newspaper in Sweden get their e-mail systems hacked

Apparently, the intrusion was made by initally hacking the newspapers intranet (which was connected to the internet!) and once the attackers had access to the intranet users names and passwords, they just tried those against their webmail system. Apparently people use the same passwords in different systems The group claiming the hack was “Vuxna Förbannade Hackare” (In english: Mature Pissed-Off Hackers) and apparently it was motivated by the fact that the newspaper did not have any coverage of their previous attack on the TV channel TV3’s website.

During the past week the hackers has been releasing more and more internal details from Aftonbladet such as e-mails and user details for partner websites etc. and they have stated that they will continue until the newspaper admits that they have been hacked on the front page of the website.

- The Largest ISP in Sweden looses 2 weeks worth of e-mail for 300 000 customers

This was an OMFG experience. Apparently, according to the information now available, there had been no backups taken (or they had been corrupt), monitoring or maintenance of the affected systems since the 14 December. Telia are now offering 20£ vouchers (only usable in Telia stores) to all affected customers and are also going to handle more serious data losses on a case-by-case basis.

And why did this happen? Well, apparently the guy that was monitoring the systems quit. (Period.)

Nice way to follow routines and policies guys…

- A USB stick containing hundreds of pages of US NATO reports left in a library

Some of the material found had the classification “secret“, but this has not been verified by the newspaper reporting.

Apparently this information was left in one of Stockholms largest libraries on an unencrypted USB stick.. heh.. I mean, encrypted USB sticks are soooo hard to come by these days, so why use them?

This has also been reported on by “The Register“:

According to Swedish daily Aftonbladet, the stick contained material on NATO’s ISAF peace-keeping force in Afghanistan, as well as an intelligence report on the attempted assassination of Lebanon’s defense minister and the murder of Sri Lanka’s foreign minister.

Word of advise, do not trust anyone else with your data people

Cheers and good luck in this 20£ corporate voucher world!

Seems like Orkut (the google social networking site) got hit with a pretty nasty XSS worm.

It did not do anything malicious (fortunately) to the users whose profiles were infected, but probably caused a quite high load on the Orkut systems and joined all infected users into a group called “Infectados pelo Vírus do Orkut“.

The description of that particular group described the motivation for the hack and the main point seems to be the illustration of the insecurity in web applications such as Orkut.

For more information, including source code for the virus, see: Antrix.net or GNUCITIZEN’s posts on the subject.

These kinds of issues are raising serious concerns over services such as “Google Docs” (online office applications) and the upcoming gDrive and one might pose the question:

Do you trust Google with your data?

** Update **

More reading regarding this incident:

Sylvan von Stuppe - Orkut Worm
Arbor Networks - Orkut XSS Worm
SophosLabs - Large scale Orkut virus outbreak not cool
TrendMicro - Orkut/Google worms Compromise over 400,000 accounts

Cheers,

… reported by Dan Shumow and Niels Ferguson about 4 months ago?

I did a quick post about it here after reading about it at Bruce Schneier’s blog.

The problem is that NSA submitted an elliptic curve algorithm for inclusion in a new NIST standard for random number generation which contains certain constant values whose origin is unknown. Might not sound as something important but as discovered earlier this could open up the possibility for a “secret key” which could allow for unlocking of encrypted data. The fact that NSA submitted this (much slower than the others) algorithm also helps stir up the crypto community.

Not much has since been reported on the issue, until yesterday (by Schneier again).

The big news is that the flawed PRNG is to be shipped with SP1 for Windows Vista. It is not going to be the default PRNG, but it is still going to be included as an option to developers.

Why is this a problem? Well,

First, you are damn sure going to have to look real close at any application you employ to secure your data as you are in the hands of the developers of the applications. More or less, you will have to request the source code if you really want to be sure, and even then it can be a real hassle to find any references to the offending algorithm.

Second. Why did they implement a flawed algorithm found by their own analysts? Yes, Dan Shumow and Niels Ferguson is employed by Microsoft. Specially as they have been urgently patching other PRNG flaws in their OS’s recently. Some say this is to meet the whole NIST standard, but come on, who would implement a crypto technology that is flawed. I mean, that kind of breaks the whole idea of cryptography in the first place.

Third, what if Microsoft issues a patch or security update which silently sets Dual_EC_DRBG to the default PRNG ? Then all your data could be read by “someone”. Do you trust MS? This leads me to the…

Final point. Who has the skeleton key? NSA? Microsoft? Someone else?

but “L O L” at Microsofts latest security debacle

I think their own advisory from 1999 (!!!) explains the issue pretty well:

Well,

too bad they only protected their customers from this if their domains ended in .com, and that this issue has persisted through eight more years of code (how much new code did they say there were in Vista?). This little function seems to have remained unchanged for almost a decade anyhow…

Now let’s hope that Microsoft are faster than the bad guys… And in the meantime:

• If you have a webfilter, block all adresses containing “wpad.” in them.
• On most Windows operating systems, stopping the service “WinHTTP Web Proxy Auto-Discovery Service” would also do it, but some people have been having problems with this.

In other words, keep an eye on your network the next couple of weeks until MS produces a patch.

Cheers and browse safe!

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

After my post mentioning the PCI DSS I got some questions like “PCI D..what?” and “What is that anyways? I’ve heard of it but never read anything about it”. Well, after reading this, you people should feel a bit enlightened. Hopefully, CISSPs and similar will not find this as new information, but you might enjoy the refresher. So, read on folks, this is gonna be a (…another) long one.

PCI DSS stands for “Payment Card Industry Data Security Standard” and it was created by the larger players in the credit card business to ensure that those little 1’s and 0’s, that usually reside on your physical magnetic-strip card, does not end up in the hands of a criminal.The first version of the standard was developed and agreed upon in late 2004 and was (still is) intended to provide guidance for organizations that transfer, store or process credit card information in computer security related issues. The first standard was revised in 2006 to make it more up-to-date and more relevant to the current situation.The use of the word “Guidance” is used a bit freely in the description according to me, as if a requirement in the standard is not met by the merchant he might lose his right to handle the kind of data described in the standard, effectively shutting down their business (this is not a bad thing, btw).Before the PCI DSS was widely agreed upon, many of the CC companies had their own standards and recommendations regarding data security, such as: CISP/AIS (Visa), SDP (MasterCard), DSOP (AmEx), I&C (Discover) and DSP (JSB). The above mentioned was also the primary participants in the discussion that later led to the standard. Most of these financial actors still have their own security programs but they have aligned them so that they all have the same objective, help merchants become PCI DSS standard compliant.

The PCI Data Security Standard consists of 12 topics in 6 different categories. These are called “control objectives” and are:

• Build and maintain a Secure Network
  • Requirement 1: Install and maintain a firewall configuration to protect cardholder data
  • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
• Protect Cardholder Data
  • Requirement 3: Protect stored cardholder data
  • Requirement 4: Encrypt transmission of cardholder data across open, public networks
• Maintain a Vulnerability Management Program
  • Requirement 5: Use and regularly update anti-virus software
  • Requirement 6: Develop and maintain secure systems and applications
• Implement Strong Access Control Measures
  • Requirement 7: Restrict access to cardholder data by business need-to-know
  • Requirement 8: Assign a unique ID to each person with computer access
  • Requirement 9: Restrict physical access to cardholder data
• Regularly Monitor and Test Networks
  • Requirement 10: Track and monitor all access to network resources and cardholder data
  • Requirement 11: Regularly test security systems and processes
• Maintain an Information Security Policy
  • Requirement 12: Maintain a policy that addresses information security

In order to verify whether or not the merchants/service providers are really compliant they have to undergo self-assessments, quarterly PCI Security Scans and possibly PCI Security Audits (Depending on the size and amount of sensitive information handled).

The PCI Security Scans are to be performed by a ASV (or, Approved Scanning Vendor) and is non-intrusive in their nature. This means that the scans should not interrupt day-to-day business or cause any damage to the systems evaluated. After one of these scans the ASV compiles a report detailing the different issues found, the associated risk (you will need a CISSP for this ) and also provide some guidance on how to remedy the issues. Every weakness found should also be categorised in a scale from one to five, five being worst case scenario. The PCI DSS considers level 3 to 5 as a failure to comply and a direct danger to cardholder data. This type of scans was the topic of discussion in the webinar that I based my previous related post on.

If you are a large merchant or service provider you might also be the subject of a PCI Security Audit which consists of a review of internal policies & documentation, internal penetration-testing & security evaluation and also interviews of selected personnel. This is done to actually verify that all guidelines in the PCI DSS has been implemented as they should.

One very interesting document regarding both types of audits was written in late 2006 by consultants from the German security company SRC. In that document (which contains a lot of good info) they listed the top 10 types of vulnerabilities found for both methods (internal/external). What’s very serious about the ones they listed are that they are very old. For example, I used one of them to compromise a network in 2002! This kind of vulnerability should not be present in any company that seriously tries to be secure. No matter the size. They are easily scanned for and can be exploited in under one minute. You can find the whole document here.

Other references on this subject:

PCI Security Standards

PCI Answers - This post was very interesting.

PCI Answers PCI Forum

PCI DSS News and Information

IT Governance PCI DSS information

Google…

That’s it for me now. If I’m mistaken about something or if someone has any questions please drop me a comment or an e-mail!

Cheers,

I’m not an advocate or fan of Microsofts technology, implementation of standards or politics. That’s for sure. However this is actually really interesting for us that are stuck in our corporate environment with Windows:

I was recently visiting a larger company in Sweden that is in the testing stage of a large deployment of Windows Vista. This deployment will be done on a pretty big userbase that has somewhat special security demands and for that reason they are following the SSLF (or SS-LF) baseline presented by Microsoft in the Windows Vista Security Guide. In that same guide you will also find information about a lighter security model called Enterprise Client (EC). The EC-baseline provides a more simple and less intrusive security baseline but it did not fill the requirements for this particular company.

I was quite impressed with the work they had done and how well it seems to have fallen out and decided to read up on these baselines. I mean, more security for Windows systems is not a bad thing and if you can do this easily then it would be great.

The definition of the two baselines in the Windows Vista Security Guide are:

• Enterprise Client (EC). Client computers in this environment are located in a domain that uses Active Directory and only need to communicate with systems running Windows Server 2003. The client computers in this environment include a mixture: some run Windows Vista whereas others run Windows XP….
• Specialized Security – Limited Functionality (SSLF). Concern for security in this environment is so great that a significant loss of functionality and manageability is acceptable. For example, military and intelligence agency computers operate in this type of environment. The client computers in this environment run only Windows Vista…”

The whole process of securing the clients are done via Active Directory group policies and the implementation of these can be very much simplified by using pre-made scripts (also included in the security guide).

The main downside for me with this policy (SSLF) is that it might cause a minor conflict with the brand new “Panda For Desktops” (formerly known as ClientShield) but there is an easy remedy for that particular problem. Guess why I was there btw hehe…

Here is a short list of resources for more information:

• Windows Vista Security Guide - The whole guide, including everything.
• Lou Bolanis blog with links related to SSLF - More interesting links.
  
• Technet Security Guidance Center - Security information regarding all MS products.

And as a bonus, the delicious, the enormously useful (as not many run on an SSLF baseline) but also quite CTO friendly:

• Fundamental Computer Investigation Guide for Windows

This should be an prerequisite for all administrators running a +100 user network. Sure would make my life a hell of a lot easier during intrusion investigations

Cheers and drive safe (winter in Sweden now) !