HP ASC Portal

News Flash: phpBB Massive Hack

Rafal Los — Tue, 13 May 2008 19:42:00 GMT

ComputerWorld is running an article from Paul Ferguson of TrendMicro claiming that there is a massive hack going on as you read this - via the phpBB bulletin-board software. Truth be told, phpBB has been known to be bug-ridden over the years (simply Google "phpBB vulnerability" and you'll get more than you wanted) but I believe that these have come to a boiling point now. If it's actually true, the number of site that was hacked stands at ~500,000, it would point to a massive problem within phpBB's code which likley hasn't been disclosed yet.

What worries me is not that these sites are being hacked (because this is a "normal" occurrence these days) but that they're increasingly effective. While a half-million web sites being broken into isn't something to sound the alarm over - and this is truly a sad commentary on the state of web security today - the precision and effectiveness of these types of attacks is scary. Furthermore, the "drive-by" installations of malware, trojans and other unwanted stuff on your computer is the stuff that security managers worry about at night. Just think of the amount of data that a half-million key loggers can pull? Think of the potential fallout of having to re-load (because cleaning isn't possible most of the time) every machine at your office... the possibility boggles the mind.

What comes out in incidents like this, and sadly people still do not understand, is that an insecure web application/site does more than just possibly damage the host. A vulnerable site leaves its visitors vulnerable, which sets off a chain of reactions that resonates back into the CISO's office at any company that allows its users to browse the Internet. More on this in a future post.

While I know it's rather un-common to have a php-facing application like this in an entierprise - it's definitely not impossible so I felt like I needed to notify and warn you readers. More as information comes in... if it comes in.

Top Five Web Application Vulnerabilities 4/28/08 - 5/11/08

mep — Mon, 12 May 2008 18:28:00 GMT

1) SAP Internet Transaction Server Multiple Cross-Site Scripting Vulnerabilities

SAP Internet Transaction Server is susceptible to multiple instances of Cross-Site Scripting. If exploited, these vulnerabilities could give an attacker the means to perform account hijacking, execute malicious scripts, or steal proprietary information. A solution is reported to be available in SAP note 1052053. Contact the vendor for further details.

http://www.securityfocus.com/bid/29103

2) Sun Java System Web Server Search Module Cross-Site Scripting Vulnerability

Sun Java System Web Server Search Module is susceptible to a Cross-Site Scripting vulnerability. If successfully exploited, this vulnerability could allow an attacker to steal confidential information and cookie-based authentication credentials, and possibly lead to execution of arbitrary code in the browser of an unsuspecting user. A fix has been released. Contact the vendor for additional information.

http://www.securityfocus.com/bid/29087

3) Sun Java System Directory Proxy Server Remote Unauthorized Access Vulnerability

Sun Java System Directory Proxy Server is susceptible to a remote unauthorized access vulnerability. An attacker can leverage this vulnerability to gain administrative access to the affected server. An advisory and fixes for this issue have been released. Contact the vendor for more details.

http://www.securityfocus.com/bid/28941/discuss

4) Sun Java System Application Server and Web Server JSP Information Disclosure Vulnerability

Sun Java System Application Server and Web Server are prone to an information-disclosure vulnerability. An attacker could leverage this issue to obtain sensitive information which could possibly be used to orchestrate more dangerous attacks. An advisory and updates which address this issue have been released. Contact the vendor for additional information.

http://www.securityfocus.com/bid/29088

5) Zen Cart 'keyword' parameter SQL Injection and Cross-Site Scripting Vulnerabilities

Zen Cart is susceptible to SQL Injection and Cross-Site Scripting vulnerabilities. If exploited, these vulnerabilities could lead to compromise of the application, the theft of confidential information and authentication credentials, or be utilized in conducting additional database attacks. A fix has not yet been released. Contact the vendor for more information.

http://www.securityfocus.com/bid/29020

Static Code Analysis Failures

Rafal Los — Tue, 06 May 2008 21:32:00 GMT

Static code analysis failures are costing enterprises money and reputation.

White-box security testing is inherently a flawed proposition for many reasons -but it all comes down to a very simple concept:

Machines do not execute source code, they execute machine code (compiled code). --Paul Anderson (GrammaTech)

If you think this through for a minute you realize that there are a few specific reasons why the above statement fundamentally changes the way that people look at white-box testing, and why this is a losing proposition. Let's analyze this in the context of a web application project for a mythical online bank. Consider that the use-case here is that we are dealing with a bank that has an online presence (currently being analyzed) which will be integrated with a series of existing legacy applications, partners, and external 3rd party components. Given this information let's analyze why white-box analysis (or static source-code analysis) is doomed to fail this project with respect to security.

Compiler Optimizers Break Things - Think of it this way, compilers are designed to make machine code from your source code. That compiler's sole purpose (in most cases) is to create machine code that will be optimized, extremely fast-executing, but not necessarily secure. Often times security functions that people build into source code can be removed by compiler optimizers and most often without our knowledge. These actions often undo many of the advanced security features that developers may consciously insert into their code. Consider the following example:

Developer is paranoid about data-persistence in memory space, and wants to be doubly-sure that variables are expired and destroyed
Developer writes a routine whereby the variable will have a null value written to it before the memory is freed
Compiler optimizer sees this as a double-work scenario, and removes the null-value portion and simply opts to free memory
A potential security vulnerability is created with variable persistence in freed memory space

This example ideally demonstrates how a security vulnerability can be inserted in spite of the developer's best efforts to write secure code. Standard static-code analysis tools which are used to "scan code" at the static-file level will fail to catch this vulnerability. Quite simply - static code analysis fails if it is not supplemented with dynamic analysis.

3rd Party Library Integrations - There is another threat to developing and scanning static code in a white-box format. Inevitably, 3rd party libraries are used to complement features or functionality that are not natively provided by the local development effort. After all, no one re-invents the whole wheel everytime - we simply build what we cannot reuse from someone else's work, then use the publicly available libraries from 3rd parties to fill in the functionality and features that have already been written and (hopefully) tested before. White-box testing (or static code analysis) will absolutely fail in finding flaws when it comes to pulling in 3rd party libraries. By the definition of this type of issue, 3rd party libraries rarely provide you the source to be scanned and checked for weaknesses that will affect your application. What you're left with is someone else's code (in machine-compiled format!) which will be interacting with your application. Would you trust that model?
Static Code Analysis Rarely Understands Data-Flow Modeling (Data Tracing) - If you're scanning your application with a source-code-only analysis tool, you're going to not only miss things that will almost certainly come back to haunt you - but you may also be over-working yourself without a real purpose. Consider the following example to illustrate my point. Before I get into that example though, allow me to explain this idea of "data-flow modeling" for those that are not familiar with this idea.Data-flow modeling seeks to understand how data moves through your application, not just how the application code is written. After all, that's the whole pointn of the application, to work with data. Vulnerabilities lie in manipulating data either to or from the end users or the server(s). Data-flow modeling maps out the data in your appliaction from it's instantiation (maybe when the user types it in) to its resting state (maybe when it's finally written to a database, or handed off to another application or service for additional work). That being said let's consider a web application that has 1,000 forms across 100 pages written in the language of your choice, built to be AJAX. While each page does nothing individually to validate user input (the data source) all variables (data) are filtered through a central validation module deep within the application logic. A standard source-code analysis tool (I have evaluated this and can honestly say this is a real use-case but will not mention the tool) will flag on each and every input that is not validated (within the page) as vulnerable to hudreds of vulnerabilities ranging from XSS (Cross-Site Scripting) to SQL Injection and other attack types. What you are left with is a very lengthy report with hundreds of critical and high vulnerabilities that you now obviously must address... unless you do some dynamic analysis on the code and realize that *none* of those theoretical vulnerabilities are exploitable due to the fact that the application filters all data through the central validator/scrubber.

So, there you have it. Static code analysis is inherently doomed to fail. White-box testing of source-only is flawed. The sky is falling, global warming will kill us all. In my next installment of this column, I'll give you what you need to know to avoid failing in your security initiatives at the development step of the SDLC - remember, knowing is half the battle.

Stay tuned!

If this information disturbs you, and you would like to talk about it directly please don't hesitate to email me directly. I am not a sensationalist, and pride myself on presenting practical solutions to real-world problems which are realistically attainable. Thanks for reading.

Security and Compliance - Strange Bedfellows Indeed

Rafal Los — Thu, 01 May 2008 18:24:00 GMT

It's a classic problem of which came first... the chicken or the egg? politics or corruption? security or compliance? While I admit, it's not such a strange thing to see the two groups working together these days... I would like to point of some of the issues that I've come across between these two very important groups in today's enterprises.

The issue of compliance is much like the issue of legal counsel. All large enterprises, and even most small business have someone that's responsible for compliance - occasionally you'll see an entire department dedicated to the daunting task of keeping up with regulations, compliance policies, and the ever-changing landscape of procedural accountability. Oddly enough, there is not a one-to-one relationship between the compliance department and a security department. I've spent a large portion of my IT career in situations just like this and I would like to share some of my understanding with you.

Compliance, while not always a necessity in private businesses, is almost always present in larger, pubilc enterprises. The compliance department is responsible for making sure the business is in-line with self-imposed corporate regulations and policies, industry-consortium regulatory guidance, government oversight and policy even international laws too! It's amazing these groups can even keep this stuff straight, right? What's equally amazing is how often compliance relies on IT Security for guidance and implementation of compliance components. This of course begs the question - would IT Security exist in some organizations if there was no compliance stipulation for such groups? On the flipside of that... in a perfectly secure world where no one is ever malicious - what would be the need for the compliance group? So while it may be a stretch to say that one group cannot function properly without the other (I will concede that they can, albeit poorly) each is heavily dependant on the other for its very existence within a business. This is where I find some strange... interactions.

As I've stated, the security team often carries out part of compliance policy or regulations; or performs audits to ensure that the same regulations are being followed - but I feel like even in these cases the synergies between these groups are under-utilized. I can't count the number of times I've been turned down for an IT Security initiative (which made perfect business sense, by the way - but was simply under-funded) only to push that same initiative through under the guise of a compliance regulation - through the compliance team. In return... the compliance teams I've had the pleasure to work with have repeatedly called upon my security resources to be the "muscle" behind their policies.

As I travel and talk to different groups about Application Security, I am agaff at the number of times that I get an entirely blank stare when I try to explain how leveraging compliance is a sure-fire way to get security initiatives done. Here's my reasoning... see if you disagree...

Compliance is a "necessary evil" which exists to keep the business in good legal and regulatory standing
IT Security exists to keep the balance of risk/reward within the business IT as balanced as possible
IT Security should be looking to enact initiatives which work to support the business

If you take all 3 points above as truth (and I firmly believe they are) then it's a logical next-step to say that IT Security initiatives and Compliance initiatives will greatly overlap. An overlap within two very necessary units of the enterprise will always, without fail, lend more credibility to their efforts and causes. If both the security and compliance teams are pushing the same agenda, it becomes very difficult for a business owner to simply dismiss that agenda as unnecessary or frivolous.

So a lesson-learned here - if you're not already doing this... here are some very simple yet extremely effective (based on personal experience and first-hand accounts) techniques for getting things "done".

Open a regular dialogue with your complaince team. Meet once a quarter, once a month, or once a week as permissable to discuss what you're independently working on
Find overlaps in your goals from a non-technical perspective
Create a joint strategy for compliance and technical implementation of initiatives previously agreed upon
Review business requirements jointly - ensure that both groups understand each other's point-of-view

Given these very simple, and probably obvious, steps - I can virtually guarantee a more successful IT Security goal achievement. You'll work less uphill, you'll "win" more often, and you'll do a much better job not only understanding but supporting your business - that makes everyone happy.

Top Five Web Application Vulnerabilities 4/14/08 - 4/27/08

mep — Mon, 28 Apr 2008 20:08:00 GMT

1) IBM Lotus Expeditor URI Handler Command Execution Vulnerability

IBM Lotus Expeditor is susceptible to a remote command-execution vulnerability because user-supplied input is not properly sanitized. Attackers who successfully exploit this issue can execute arbitrary commands in the context of victims who follow malicious URI's. A fix has not yet been released. Contact IBM for more information.

http://www.securityfocus.com/bid/28926

2) F5 Networks FirePass 4100 SSL VPN 'installControl.php3' Cross-Site Scripting Vulnerability

F5 Networks FirePass 4100 SSL VPN is susceptible to a Cross-Site Scripting vulnerability. If exploited, this vulnerability could give an attacker the means to perform account hijacking, execute malicious scripts, or steal proprietary information. An update which resolves this vulnerability has been released. Contact the vendor for additional details.

http://www.securityfocus.com/bid/28902

3) HP OpenView Network Node Manager Running Apache Multiple Vulnerabilities

HP OpenView Network Node Manager when running Apache is vulnerable to multiple vulnerabilities including Cross-Site Scripting and Denial-of Service attacks. If successfully exploited, these vulnerabilities could allow an attacker to steal confidential information and cookie-based authentication credentials, possibly lead to execution of arbitrary code in the browser of an unsuspecting users, and be used to deny access to legitimate users. Patches which resolve these issues have been released. Contact the vendor for more details.

http://www.securityfocus.com/archive/1/491026

4) Novell GroupWise HTML Injection and Denial-of-Service Vulnerabilities

Novell GroupWise is susceptible to HTML Injection and Denial-of-Service vulnerabilities. HTML Injection can be leveraged to add content into a web server’s response, which can then be used to steal cookie-based authentication credentials, execute arbitrary code in context of the site, or simply alter how the site appears. Denial-of-Service attacks can be exploited to crash the application and deny access to legitimate users. A fix has not yet been released. Contact the vendor for additional information.

http://www.securityfocus.com/bid/28944

5) RSA Authentication Agent for Web URI Redirection Vulnerability

RSA Authentication Agent for Web is susceptible to a remote URI-redirection vulnerability because inadequate data sanitization is performed on user-supplied input. Exploitation of this vulnerability could aid in phishing-style attacks. RSA Authentication Agent for Web 5.3.3.378 resolves this issue. Contact the vendor for specific upgrade information.

http://www.securityfocus.com/bid/28907

Navigating the PCI DSS Standards...

Rafal Los — Tue, 22 Apr 2008 16:18:00 GMT

For those of you who keep up with the PCI DSS standard, the coucil today has issued an update titled: Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified.

The standard item 6.6 has been further clarified in one of two options, as before, being either Application Code Reviews or an Application Firewall. I'll address the first option, since that is the more logical one, but will briefly talk about the Application Firewall as well - just to clear the air a bit. While the Standards Council continues to add clarification, which makes the standard more usable, more opportunities for compliance surface with less cost and effort. No doubt the IT manager feels like this is a good thing because now the cost of compliance won't necessarily be astronomical - and thereby make it viable. As we all know, the issue of compliance to a non-government regulation is always a balancing act. Compliance, as with most security components, is an equation balancing risk against spending and business value. We all know the results... if the equation balances just right, the business benefits from the added security and sees value while not spending more money than the risk is worth - and security feels worthwhile because risk has been decreased by some factor which affects the business in a positive manner. Granted, it doesn't always work out quite so rosy - but the PCI DSS standard is going a long way to make sure that these equations that happen every day, in many businesses throughout the world - balance.

Now - on to the meat of the standards update. First off, let me address the Web Application Firewall issue. While this is a topic that deserves a whole article onto itself, the short version is this - web app firewalls are very expensive, complex band-aids. That's the reality. While many of them work phenomenally well, and in fact I can name a few that do, they are difficult to implement into an existing production environment, they are primarily signature-based (remember how well we stop "unknown" viruses?), or have some other architectural quirk that makes them an impossibility in your enterprise. Personally, at my previous company I started to implement a particular WAF ... but it took over a year and a half of research, testing, approvals, and more testing to get them into a newly built environment... not even into a legacy production environment where they would have provided the most value. Anyway... the point is - a WAF is a tool you use when you don't have the resources to "do it right"... fix the code itself.

Section 6.6 of the PCI DSS standards, option 1 (the Application Code Reviews) now has 4 basic alternatives. Candidates are urged to implement at least one of the following...

Manual review of application source code
Propse use of automated application source code analyzer tools (static code scanners)
Manual web application security vulnerability assessment
Propse use of automated web application security vulnerability assessment tools

First, a few things of note. The above does not necessarily call for a "penetration test" which exploits vulnerabilities by an ethical hacker... only an "assessment" (which identifies but does not exploit) vulnerabilities is required. The distincion is important because it means that you can now do this on production code, or a production environment without the risk of damaging your applications by necessity to prove their vulnerability.

I find it interesting that the update goes and directly says "In all cases, the individual(s) must have the proper skills and experience to understand the source code and/or web application, know how to evaluate each for vulnerabilities, and understand the findings". The fact that the DSS requirement 6.6 now specifically addresses competence in the assessor should mean that there was some ... question... over the competence of assessors or possibly a need to specifically stamp out that only qualified people should be doing assessments. Interesting, at either angle. The same statement goes for assessors using automated tools - but now we have an interesting proposition. Do you (a) hire an extremely qualified application vulnerability tester, or (b) hire a knowledgeable user, and give him a software testing/scanning tool and some training... and are those even the same? Obviously the dollar amounts for the two are different... or are they? There is also the point about the testers having to be (the authors use the word "should be") organizationally separate from those writing the code... well that makes sense. No one wants the fox guarding the hen-house, right? You don't want the same developers that are potentially churning out insecure code to then review it and give themselves gold stars. So far so good.

So now we have 2 options for doing this internally - which will help our bottom line (external 3rd parties are typically very, very expensive)...

First option is to do an SDLC-integrated code review... actually reviewing the application code before it gets compiled and leaves the development group's control. We have the option to do it manually, or with some tools - using only highly trained and knowledgeable people.
Second option is to do a post-development analysis of the code. Once the code is written, built, and tested for usability issues it's time to security-test it with, again, either a human being, or some black-box testing tool(s) - but again, you must use trained and knowledgeable people here as well.

Well, if I'm a security manager...this is great! Thinking logically - you always want the security expertise in-house, and why in the world wouldn't you want to do application security throughout the application lifecycle? The DSS update also goes on to remind us of requirement 6.3, and the need to have an effective change-control process such that the security reviews are not bypassed, at any level. While the final sign-off must be done when the code is ready for production - it's imperative that the effectiveness of the application security policy be enacted to push as far back into the development (pre-development planning? requirements gathering?) lifecycle as possible (more on that in a separate article).

As a final note - the update talks about the need to stay current and abreast of new developments in application security testing. It's essential that whatever tools are purchased (whether they be the full SDLC suite from HP/ASC, or some other vendor) - that these tools and their users be continually updated from the brightest minds in the field. This is unfortunately a one-up battle against the "bad guys"... if you're behind you're sunk.

So what have we learned from the new Section 6.6 update?

There are at least 4 ways to interpret the "Application Code Review" guideline
You can have your code "reviewed" internally, as long as your assessor is trained and competent (but to who's qualifications?)
You can use automated tools, either static code analysis or black-box testing software, if you have your people trained in those tools, and application security
Your testers/assessors have to be organizationally separate from the development organization (but at what level?)
Your organization should absolutely integrate application security as early into the SDLC as possible, using "tools and rules" in combination
Your testers should always be up-to-date on the latest developments, techniques, and methods... otherwise you're bringing a knife to a gunbattle

Thanks for your attention!

Top Five Web Application Vulnerabilities 3/31/08 - 4/13/08

mep — Mon, 14 Apr 2008 21:16:00 GMT

1) F5 BIG-IP Web Management Interface 'NEW_VALUE' Parameter Remote Code Injection Vulnerability

F5 BIG-IP Web Management Interface is susceptible to a remote code injection vulnerability. Attackers who successfully exploit this vulnerability could execute arbitrary code with the privileges of the user of the affected application. A fix has not yet been released. Contact the vendor for additional information.

http://www.securityfocus.com/bid/28639/

2) Cisco Unified Communication Manager Multiple Vulnerabilities

Cisco Unified Communication Manager is susceptible to multiple remote vulnerabilities including instances of SQL Injection, information disclosure, and unauthorized access. If exploited, these vulnerabilities could lead to compromise of the application, leveraged to gain unauthorized application access, or utilized to obtain sensitive information. A fix has not yet been released. Contact Cisco for further details.

http://www.securityfocus.com/bid/28690

3) Drupal Menu System Security Bypass Vulnerabilities

Drupal is susceptible to multiple security-bypass vulnerabilities via the menu system because the application fails to properly control access to certain pages. Successful exploitation would give an attacker access to sensitive information which could likely be utilized in orchestrating more damaging attacks. Updates which resolve these issues have been released. Contact the vendor for more information.

http://www.securityfocus.com/bid/28714

4) Microsoft SharePoint Server Picture Source HTML Injection Vulnerability

Microsoft SharePoint Server is susceptible to an HTML Injection vulnerability. HTML Injection is used to add content into a web server’s response, which can then be used to steal cookie-based authentication credentials, execute arbitrary code in context of the site, or simply alter how the site appears. An attacker needs to utilize a user account with page editing privileges to successfully exploit this vulnerability. A fix has not yet been released. Contact Microsoft for additional details.

http://www.securityfocus.com/bid/28706

5) SAP NetWeaver Filesystem Feedbacks Cross-Site Scripting Vulnerability

SAP NetWeaver is susceptible to a Cross-Site Scripting vulnerability. If exploited, this vulnerability could give an attacker the means to perform account hijacking, execute malicious scripts, or steal proprietary information. Note that this issue can be resolved by activating 'Secure Editing' in the Portal. Contact the vendor for more information.
http://www.securityfocus.com/bid/28699

In "cyberspace"... no one can hear your database scream

Rafal Los — Wed, 09 Apr 2008 16:01:00 GMT

It's 2:34am, local time. You're snoring up a storm after a hard day at the office. You've patched all your servers, your lockdown scripts have been verified, and your IDS is humming along perfectly. Oh, and by the way, someone named "R0kk1t" just stole your customer database. A quick check of the "Security Dashboard" when you get in at 8:00am will show everything is green... You have a serious problem.

Sound like anyone you know? This is a serious concern, and the problem is - it's pervasive. It's scarry that 7 out of every 10 people I talk to about Web Application Security don't have any defenses. When I ask what their defenses are they mention things like firewalls, IDSes, and patch policies - all have absolutely nothing to do with (and will do little for) Web Application Security.

Houston - we have a problem. Even if you're trying to build a program geared towards protecting your web apps - how are you going to justify it? Inevitably someone is going to ask you the daunting question - "So, have we been attacked? How many times?" Odds are you're going to have no idea. All hope is *not* lost though... I have some suggestions from years of this happening to me. Here are some tips on building self-defense mechanisms into your web applications - and how to use them as rudimentary alerting triggers...

Kick out the troublemakers - A well-built web application has to know when someone is just being stupid. If your're tracking logged-in users it's even easier. Track the per-user incidence of "bad data" and if it reaches a specific threshold - expire the session and send that user to a page warning them that they've been bad and must re-login. It's basic, and not hard to do - but rarely implemented. Of course, you'll have to figure out those thresholds and what "bad data" is - but at least you have a start here.
Whitelist - In the point above I said you should track "bad data" or bad user-supplied input but how do you know what is good versus bad? Simple, you first have to define what you should expect from the user. An application should, on a per-page and per-input basis, know exactly what input is allowed and what data sets are in play. You can use regular expressions to validate these lists! For example, if you've got a field that expects social security numbers (don't we all) then you can have this simple bit of JavaScript to validate (obviously you'll want to do this on the server side!)

function isValidSSN(value) {
var re = /^([0-6]\d{2}|7[0-6]\d|77[0-2])([ \-]?)(\d{2})\2(\d{4})$/;
if (!re.test(value)) { return false; }
var temp = value;
if (value.indexOf("-") != -1) { temp = (value.split("-")).join(""); }
if (value.indexOf(" ") != -1) { temp = (value.split(" ")).join(""); }
if (temp.substring(0, 3) == "000") { return false; }
if (temp.substring(3, 5) == "00") { return false; }
if (temp.substring(5, 9) == "0000") { return false; }
return true;
}

Log, Log, Log - Your web applications should always have a separate log file for "unexpected input". In fact, where I've had input into the development process I've required there to be at least 2 log files. First log file logs all "unexpected actions" in a web application, the time/date, the logged-in user, the source, user-agent and all other pertinent details of the "unexpected action" whether it be an exception, a crash, or whatever. The second log file is just a dump of all the weird input people submit - some malicious, some not, to better help write regular expressions to filter the garbage.
Fire Alerts - All the things I've mentioned previously are great - but if no one looks at them, or gets an alert when they fire - they're worthless. Make sure you create actionable alerts from with your application framework. Combine all the loggins, white-listing, and self-defense into something that you can understand. Be careful of the information Monster though... if you're not careful in the way you set this up you'll end up with 10,000 emails/hour and won't be any more effective than having nothing. It's a difficult balance but with practice you'll be one step closer.

Well - I hope you find those useful. If you're willing to share, I would love to hear of some other methods that YOU are using in the real-world! Leave them as a comment here, share with the community - remember we're all smarter when we share information.

The Politics of Getting Hacked

Rafal Los — Sun, 06 Apr 2008 07:07:00 GMT

It's the words that keep IT Security Managers up at night - "We have a problem, I think we've been hacked". Of course, there are few possible responses...

Acknowledge Responsibly - You can acknowledge what has happened, open an investigation, and communicate with the public and your customers. While this may be initially bad PR, in the end it shows responsibility and maturity of process and management
Acknowledge Irresponsibly - You can acknowledge the issue but attempt a campaign of mis-direction and cover-up. Redirect blame to partners, vendors and even former employees, release mis-leading information about the magnitude of the issue and do not publicly investigate the breach.
Bury It - Re-direct blame, issue no statements or official information

The problem is this - you know which you want to do, but which option will your lawyers allow you to take? There are many IT Security departments which are run more by the company legal counsel than the IT Security manager or CISO. Why is this you may ask? Lack of planning and initiative. If a CISO has no strategic, pre-planned response plan for that dark day - the lawyers will more often than not take over and try and guide the company out of trouble (and in the process create a bigger problem). Responsible breach disclosure isn't easy to plan for, and if executed poorly will potentially cause a catastrophic end. This game isn't for the faint of heart.

The purpose here isn't to poke at the legal counsels, in fact, they're entirely necessary and should be your allies. They should not; however, run your crisis management process. Crisis management should be left up to those who are trained for it, and not to the CEOs, the lawyers, or the PR department. Litigation should be a component of your crisis-management process but if you lose control of the situation as the "security" function - you're in for a rough ride.

As the title of this entry suggests, there is a political component to every "incident" that must be carefully navigated. Leave room in your response strategy (crisis management process) for all those previously mentioned folks to do their part - but make sure you understand that you have to control the situation. You're only going to accomplish any semblance of control by planning in advance, working your plan through the ranks, and making sure you have buy-in long before the call comes. This is really a case of failing to plan means planning to fail.

Politics is a dirty business, but unfortunately you cannot escape it, even in IT Security management. Remember, make allies, plan ahead, and get buy in and you'll weather the storm. Otherwise... I need to tell you a story about 3 envelopes...

What's the point of "penetration testing"?

Rafal Los — Fri, 04 Apr 2008 18:45:00 GMT

Over the last 8 years in IT Security, I've had at least a professional interest in the idea of penetration testing and the opinion of this service has evolved as the IT Security market niche matures and grows. I wanted to take a minute to discuss it with the readers out there, and maybe solicit some opinions on the topic if you're willing to offer yours. I'll reserve my personal opinion for the end, but wanted to present some thoughts, rebuttals and commentary on these here. I'm going to address penetration testing in the context of web applications - but this can be allied virtually to any technology out there.

Let's first look at the arguments for penetration testing:

Penetration testing provies a hackers-eye view of your web application attack surface
Penetration testing provides an outsider's view of your web application attack surface
Penetration testers will often find ways to manipulate your applications in ways your developers never thought possible
Penetration testing offers the client an opportunity to get a snapshot picture of your security posture
A penetration test goes more in-depth than a "security scan" by identifying and exploiting real weaknesses

Those are some compelling points, to be sure. Security is a very strange f1sh, it changes so drastically so often it's almost impossible to be entirely up-to-date all the time, unless that is your sole job. This is precisely what penetration testers are great at - they focus their entire energy on researching, identifying, and exploiting security weaknesses in, in this example, web applications. There really isn't any amount of "scanning" that an automated tool can do which will match the power and adaptive capability of the human mind - I don't think anyone will argue that - so the value of employing someone who is extremely versed in this sort of thing is akin to having your transmission looked at by a transmission-only specialist... you do it because you want to go to the expert. There are varying degrees of expertise; of course, and let's not even try and disagree that you get what you pay for. If you want a top-notch security expert, you're likely going to be hiring someone with a shady past, and it's going to cost a lot - but at least you know you're getting the top talent matching wits with your pro-active security measures. But what about the other side of the coin?

Let's look at arguments against penetration testing:

Penetration testing can be argued to be a test of the 'tester' not the target
Penetration testing isn't an exact science, and rarely standardized
Penetration testing results are inconsistent
Penetration testing is too expensive
Penetration testing is only a snapshot in time

With those arguments against penetration testing - how can one reasonably conclude it's a good idea? Well, the fact of the matter is that penetration testing is expensive, inconsistent and rarely an exact, standardized process (unless you pick one of the top firms which have standardized). Yes, sometimes the results are inconsistent and a mere snapshot in time, not an accurate assessment of your stategy as a whole. The argument has also been made that a penetration test result is often a test of the "tester's" intelligence and hacking prowess, and not necessarily of the defenses... however I would say think twice about that argument. Isn't that the point? You hire the best, they put their mind to the test against your defenses? So now the pros are weighed against the cons... and the money issue is always on the forefront of the decision to go one way or the other. I will only offer you these words...Strike a balance in your strategy - but do not fail to test yourself.

Remember, the right balance when it comes to penetration testing is in moderation. You can't reasonably have a penetration test done once a week, as it would destroy your budget. You also shouldn't do it once a year - as that's probably too rare. The right balance is a combination of automated tools which you and your security team can use to self-assess plus a seasoned expert tester to check your sanity and environment. Heed my warning... find your vulnerabilities because if you're not testing the security of your web applications - rest-assured someone else is.

Top Five Web Application Vulnerabilities 3/17/08 - 3/30/08

mep — Tue, 01 Apr 2008 21:03:00 GMT

1) Webutil 'webutil.pl' Multiple Remote Command Execution Vulnerabilities

Webutil is susceptible to multiple command execution vulnerabilities which remote attackers can leverage to execute arbitrary commands. Successful exploitation can lead to a complete compromise of the affected application and underlying system. A fix has not yet been released. Contact the vendor for additional details.

http://www.securityfocus.com/bid/28393

2) IBM Rational ClearQuest Multiple Parameters Multiple Cross-Site Scripting Vulnerabilities

IBM Rational ClearQuest is susceptible to multiple instances of Cross-Site Scripting. If successfully exploited, these vulnerabilities could allow an attacker to steal confidential information and cookie-based authentication credentials, and possibly lead to execution of arbitrary code in the browser of an unsuspecting user. Patches which resolve these issues have been released. Contact IBM for further information.

http://www.securityfocus.com/bid/28296

3) Imperva SecureSphere Cross-Site Scripting Vulnerability

Imperva SecureSphere is susceptible to a Cross-Site Scripting vulnerability. If exploited, this vulnerability could give an attacker the means to perform account hijacking, execute malicious scripts, or steal proprietary information. An update which addresses this issue has been released. Contact the vendor for additional details.

http://www.securityfocus.com/bid/28279

4) Joomla! and Mambo Components Multiple SQL Injection Vulnerabilities

Multiple Joomla! and Mambo components are susceptible to SQL Injection vulnerabilities. SQL Injection can give an attacker full access to a backend database, and in certain circumstances can be utilized to take complete control of a system. No fixes have yet been released. Contact the vendor for more information.

http://www.securityfocus.com/bid/28410

"Security Vulnerability" != "Defect" ; why?

Rafal Los — Tue, 01 Apr 2008 15:18:00 GMT

It's one of those obvious things. A defect is a defect, right? Whether the airbag is faulty, or the gas cap doesn't hold pressure... a defect is a defect. The strange thing is - it hasn't been that way, and still isn't that way, in most of the IT shops I've been in. Why?

The reason is simple. Historically, security vulnerabilities have been in a class all their own. In an attempt to put some urgency to the matter, security professionals have labeled defects in the security of their projects (in this case I'm talking about web applications) as an entirely different thing than a functional defect. What we didn't realize is that we were actually doing a dis-service to ourselves and the security cause. You may not agree with me right now - but I'll explain this more clearly, and I think you'll be on board with my thought process.

Let's talk about defects, in general and then apply it to the matter at hand. First, let's identify what a defect is... A defect is, in the dictionary sense (cut from dictionary.com):

de·fect [n. dee-fekt, di-fekt; v. di-fekt] Pronunciation Key - Show IPA Pronunciation

–noun

1.	a shortcoming, fault, or imperfection: a defect in an argument; a defect in a machine.

2.	lack or want, esp. of something essential to perfection or completeness; deficiency: a defect in hearing.

OK, easy enough right? So the first meaning is clear; a defect is a shortcoming, fault, or imperfection. It is reasoned that a defect in a web-based application results when functionality X doesn't work as required. Say you have a button, and the functional specification (we'll get back to this gem in a minute) calls for the button to perform some action, A. During the testing phase of the application, before release to production, a tester or tool is utilized to test the functionality of that button, but instead of action A happening, some other action B happens. This is a defect. There is no doubt in anyone's mind that this immediately gets classified as a defect, put into the defect tracking system and sent back to the developer for remediation. The defect is classified as a higher-priority defect if the function happens to be one that is showcased, or important to the overall functionality of the application. Those of you that already use the HP Quality Center tools know exactly what I'm talking about, and know how this process works. Here's the strange twist though - why is quality testing only done with good data? I understand that you want to make sure that the test cases work properly - but why are the testing options limited? The issue at hand here is a very narrow view of defects, and defect testing.

Back in college, I took very basic programming class and had to write a program that was a calculator. It would ask for two inputs of numbers, and then give you an option to perform either an addition, subtraction, multiplication or division of the inputs. Generally, it was assumed that these would be numbers, but what if they weren't numbers? Most of the students in the class, myself included, never thought about ... "What if someone enters a letter or some other unexpected input?" Well, luckily, the professor chose my application, put it up on the screen for the whole class to see, and promptly entered a and b for the two inputs and tried to add them. When my application core dumped, he explained to the class why I had gotten my first F on a project. I learned a very valuable lesson that day - developers must brace their applications for unexpected input. "Why would anyone want to enter something other than numbers?" wasn't a good enough answer to explain why my application failed. Let's apply this lesson I learned back in college to today's application programmers and functional testers.

Here are the reasons why I think security vulnerabilities aren't seen as "defects" in general...

Security professionals have insisted that a vulnerability is its own separate category - While it is true, some security vulnerabilities are a whole new level of "bad" they should be considered just like any other defect in the application for the sake of tracking and remediation. Web platform managers are generally concerned with meeting the demands of their customers and producing code that is defect-free - and it's our own fault that "vulnerabilities" of the security variety have become some ethereal, magical issue for security nerds to worry about. This matter can only be fixed by changing the naming back... a vulnerability is a defect, period. Security vulnerabilities must be explained as "high-criticality defects" to developers, managers and customers otherwise this situation will never change.
Functional specifications rarely, if ever - call for for security validation - Functional specifications aren't written by security professionals, generally. At best, security professionals have a chance to review the functional specification way too late into the process, while the code is being written and readied for production. This is, once again, our own fault most of the time. The answer to this dilemma is a two-pronged attack. We as security professionals must educate those that write functional specifications, and enlighten them to the need for security features. At the same time, we must work hard to have an active input in the writing and release of functional specification documents. These two vectors are critical to getting secure code as an end-product.
Programmers don't typically think about malicious users - While it would be great to think that one day all developers will inherently write secure code because they will have "learned" what security is, and how important it is to the application - the fact is that it's a pipe dream. Developers care about one thing... meeting functional specifications in the least amount of time possible, and moving on to the next project. Developers like to write optimized code that accomplishes the required tasks in as little time as possible. Solving #2 above will also partly solve this problem. In addition, developers must be given the tools (such as static and dynamic code analysis tools as plug-ins to their IDEs) to make their jobs easier. It is not reasonable to expect developers to be security experts in all aspects, so we must arm them with the tools to be experts, without having to do too much extra work or they won't use those tools.

So what have we learned today?

Security vulnerabilities must be re-classified as easily-understandable "functional defects"
Funcitonal specifications must be written to include provisions for security validation
Quality professionals must be given the tools to test for "security defects" in web applications to close the loop in the lifecycle
Developers must be educated and also given the tools to write more secure code with minimal additional effort

-- I welcome your comments!

DevInspect 5.0 is now available.

patrickwolf — Tue, 01 Apr 2008 04:09:00 GMT

Introducing HP DevInspect 5.0

HP DevInspect extends the reach of HP’s Application Lifecycle Optimization portfolio into product development. Combining our award-winning dynamic application scanning technology with static code analysis, HP DevInspect is the only tool available that performs true Hybrid Analysis – both white-box and black-box testing. HP DevInspect is seamlessly integrated with the Integrated Development Environment (IDE) – Visual Studio for .NET or Eclipse or RAD for Java – minimizing the training required to learn a new tool and eliminating any disruption of the development timeline. The release of HP DevInspect 5.0 further enhances Hybrid Analysis and increases development efficiencies with the following features:

Visual Studio 2008 Support

HP DevInspect for .Net now supports Microsoft Visual Studio 2008 and Visual Studio 2005. Businesses can now test for vulnerabilities with Hybrid Analysis regardless of the Visual Studio IDE preferred by their developers even in mixed environments.

Struts 1.x MVC support

Struts is one of the most popular java frameworks used for web application development. HP DevInspect for Java 5.0 fully supports integrated security testing within Eclipse or IBM RAD for applications using the Struts framework. Corporations using industry standard design practices can now take full advantage of the Hybrid Analysis inherent in HP DevInspect.

Hybrid Analysis

HP DevInspect is the only product to combine static analysis of all byte-code (both Java and MSIL) with dynamic black-box vulnerability scanning in one. The static analysis and dynamic scan engines have both been upgraded in HP DevInspect 5.0 to increase the accuracy, performance, and repeatability of our Hybrid Analysis. The time and money spent finding and fixing security vulnerabilities can now be dramatically decreased by equipping developers with an IDE with built-in Hybrid Analysis.

Vista Support

HP DevInspect for Java and HP DevInspect for .Net are now fully supported on Microsoft Vista. IT organizations looking to upgrade their existing desktop environments can transition their developers without risking their ability to perform Hybrid Analysis on their applications.

Ready for Download today!

QAInspect 5.0 is now available.

patrickwolf — Mon, 31 Mar 2008 20:02:00 GMT

Introducing HP QAInspect 5.0

HP QAInspect completes the third pillar of Application Lifecycle Optimization. Does it work? Does it perform? Is it secure? Built on the foundation of the award-winning application scanning technology in HP WebInspect, QAInspect enables quality professionals to fully manage the process of finding and fixing security defects early in the application lifecycle. This ability to manage security defect testing early in the application lifecycle mitigates risk in the application, saves money on revisions over the life of the application, and produces more holistic data for a Go/No Go decision. The upcoming release of HP QAInspect 5.0 extends the already robust integration with Quality Center with the following new features:

Defect Staging

New in QAInspect 5,0 is a staging area to vet vulnerabilities before they are added to the defect table within QC. Users can fully test and validate all vulnerabilities found by the scan to ensure that application developers are only spending development cycles fixing confirmed defects.

Defect Consolidation

Vulnerabilities found during a scan can now be viewed as a consolidated list, grouped by application page or defect type. For example, a user may view all vulnerabilities found on the login page of an application. Similarly, a user may view all Cross-Site Scripting vulnerabilities or all SQL Injection vulnerabilities grouped into a single pane. The ability to group vulnerabilities allows users to more quickly log specific defects and assign defect tasks to developers with greater accuracy.

Folder Restrictions

Restrict the crawl and audit of a scan to a particular folder. This allows much more granular control of the testing allowing for better targeted security testing. Once a particular application section has been audited and all security issues mitigated to an acceptible degree it can be moved to regression; focusing new security testing and fixes on new functional areas of the application.

Parameter Highlighting

As the size and complexity of web application pages grow the ability to quickly find a specific parameter within a vulnerable page becomes a greater burden. In order to eliminate the time wasted by developers searching a page for a particular vulnerability all defect reports now highlight the specific vulnerable parameter within the HTTP Request/Response pair. Developers can easily find the vulnerable part of the application and apply a fix with limited downtime.

Trial License Now Available (Click Here)

This release includes a trial license allowing Quality Center customers to download and evaluate QAInspect for 15 days; enabling them to make better purchase decisions. Talk to your sales representative for more details.

Welcome!

Rafal Los — Thu, 27 Mar 2008 14:18:00 GMT

First, let me say thanks for clicking and taking a minute to read my column. I hope to keep your attention while teaching you something you hopefully already don't know so come back often, bookmark me, or feed it into your RSS reader.

Let me use this first article to explain the types of content you'll find in this column, and some of my thought process when choosing what to write. My column typically includes the following:

High-level discussions of security topics relevant in today's world - too many times the small stories are the big news and they don't get enough coverage
Semi-technical pieces on important issues which you should care about - it's a shame how the message of an article can get lost in the technical details. Not everyone reads in binary and I understand that, and write my column accordingly.
In-depth analysis of specific headline-grabbing issues with a not-just-for-nerds spin - We'll take deeper dives into topics which grab the headlines with technical talk, explanations, and as always the "Why you should care" section.
Articles relevant to the business manager, the executive, and the aspiring CISO - Have you noticed how few columns there are written in an intelligent, technical and business-relevant way that you the manager can read and understand?

You, my readers, are always invited to reply with your opinions, thoughts, and debate. I thik a one-sided conversation is boring so I welcome your replies. My only request is that you keep your comments and replies professional and work-safe; this is, after all, a column you would share with your manager.

As a final disclaimer, the thoughts, opinions, and views shared here are my own - not anyone else's. If you don't agree - write a rebuttal. If you don't like it, don't read it.

Thanks, I look forward to having you as a regular!

Top Five Web Application Vulnerabilities 3/3/08 - 3/16/08

mep — Mon, 17 Mar 2008 20:52:00 GMT

1) Dokeos Multiple Remote Code Execution and Cross-Site Scripting Vulnerabilities

Dokeos is susceptible to multiple remote code execution and Cross-Site Scripting vulnerabilities. Exploitation of these vulnerabilities could lead to a complete compromise of the affected application and underlying system, and also be used to steal cookie based authentication credentials. Dokeos 1.8.4 SP3 has been released to address these issues. Contact the vendor for further information.

http://www.securityfocus.com/bid/28121

2) Adobe ColdFusion Multiple Cross-Site Scripting Vulnerabilities

Adobe ColdFusion is susceptible to multiple instances of Cross-Site Scripting. If successfully exploited, these vulnerabilities could allow an attacker to steal confidential information and cookie-based authentication credentials, and possibly lead to execution of arbitrary code in the browser of an unsuspecting user. Adobe has released advisory APSB08-06 and APSB08-07 to address these issues. Contact the vendor for additional details.

http://www.securityfocus.com/bid/28205

3) F5 BIG-IP Web Management Interface Console HTML Injection Vulnerability

F5 BIG-IP is susceptible to an HTML Injection vulnerability. When exploited, this vulnerability will allow an attacker to execute arbitrary script code in the browser of an unsuspecting victim in context of the affected device. This could possibly lead to theft of cookie-based authentication credentials or be utilized to launch other attacks. A fix has not yet been released. Contact the vendor for more information.

http://www.securityfocus.com/bid/28151

4) Adobe LiveCycle Workflow Management Login Page Cross-Site Scripting Vulnerability

Adobe LiveCycle Workflow is susceptible to a Cross-Site Scripting vulnerability. If exploited, this vulnerability could give an attacker the means to perform account hijacking, execute malicious scripts, or steal proprietary information. Adobe has released advisory APSB0-10 to address this issue. Contact the vendor for further details.

http://www.securityfocus.com/bid/28209/

5) Ruby WEBrick Remote Directory Traversal and Information Disclosure Vulnerabilities

Ruby WEBrick is susceptible to directory traversal and information disclosure vulnerabilities. Remote attackers can leverage these vulnerabilities to access the contents of arbitrary files, gathering information which will likely be utilized in orchestrating more dangerous attacks. Fixes which resolve these issues have been released. Contact the vendor for additional details.

http://www.securityfocus.com/bid/28123/

Top Five Web Application Vulnerabilities 2/18/2008 - 3/02/2008

mep — Mon, 03 Mar 2008 22:21:00 GMT

1) IBM Lotus QuickPlace 'Main.nsf' Cross-Site Scripting Vulnerability

IBM Lotus QuickPlace is susceptible to a Cross-Site Scripting vulnerability. If exploited, this vulnerability could give an attacker the means to perform account hijacking, execute malicious scripts, or steal proprietary information. A fix has not yet been released. Contact IBM for additional details.

http://www.securityfocus.com/bid/27871

2) PHP Nuke Multiple Modules SQL Injection

Multiple PHP Nuke modules contain SQL Injection vulnerabilities. Successful exploitation could give an attacker the means to access or modify backend database contents, or in some circumstances be utilized to take control of the server hosting the database. No fixes have yet to be released. Contact the vendor for further information.

http://www.securityfocus.com/bid/27863
http://www.securityfocus.com/bid/27879
http://www.securityfocus.com/bid/27894
http://www.securityfocus.com/bid/27897
http://www.securityfocus.com/bid/27909
http://www.securityfocus.com/bid/27912
http://www.securityfocus.com/bid/27886
http://www.securityfocus.com/bid/27932
http://www.securityfocus.com/bid/27930
http://www.securityfocus.com/bid/27930
http://www.securityfocus.com/bid/27930
http://www.securityfocus.com/bid/27952
http://www.securityfocus.com/bid/27958
http://www.securityfocus.com/bid/27955
http://www.securityfocus.com/bid/27957
http://www.securityfocus.com/bid/27980
http://www.securityfocus.com/bid/27991
http://www.securityfocus.com/bid/28030
http://www.securityfocus.com/bid/28063

3) Joomla! and Mambo Components Multiple SQL Injection Vulnerabilities

Multiple Joomla! and Mambo components are susceptible to SQL Injection vulnerabilities. SQL Injection can give an attacker full access to a backend database, and in certain circumstances can be utilized to take complete control of a system. No fixes have yet been released. Contact the vendor for more information.

4) Spyce Sample Scripts Multiple Input Validation Vulnerabilities

Spyce Sample Scripts are susceptible to multiple input validation vulnerabilities including Cross-Site Scripting and Path Disclosure. An attacker could possibly execute arbitrary script code in the browser of an unsuspecting user in context of the affected site, and could also retrieve the server's web root path. A fix has not yet been released. Contact the vendor for more details.

http://www.securityfocus.com/bid/27898

5) Drupal Multiple HTML Injection Vulnerabilities

Drupal is susceptible to multiple HTML Injection vulnerabilities. HTML Injection can be leveraged to add content into a web server’s response, which can then be used to steal cookie-based authentication credentials, execute arbitrary code in context of the site, or simply alter how the site appears. An update that addresses these issues has been released. Contact the vendor further details.

http://www.securityfocus.com/bid/28026

Top Five Web Application Vulnerabilities 2/4/2008 - 2/17/2008

mep — Tue, 19 Feb 2008 21:43:00 GMT

1) Microsoft Internet Information Services ASP Remote Code-Execution Vulnerability

IIS is susceptible to a remote code-execution vulnerability that can be exploited via malicious input to vulnerable ASP pages. Attackers who successfully exploit this vulnerability could execute arbitrary code in context of the Worker Process Identity, which has Network Services privileges by default. Security bulletins which resolve this issue have been released for both IIS 5.1 and 6.0. Contact Microsoft for additional details.

http://www.securityfocus.com/bid/27676/

2) WordPress 'wp-admin/options.php' Remote Code-Execution Vulnerability

WordPress is susceptible to a remote code-execution vulnerability due to a failure of the application to properly sanitize data. A remote attacker can leverage this vulnerability to execute arbitrary PHP code in context of the application, possibly leading to a complete compromise of the affected system. WordPress MU 1.3.2 has been released to correct this issue. Contact WordPress for further information.

http://www.securityfocus.com/bid/27633/

3) Cisco Unified Communications Manager 'key' Parameter SQL Injection Vulnerability

Cisco Unified Communications Manager is susceptible to a SQL Injection vulnerability. Successful exploitation could give an attacker the means to access or modify backend database contents, or in some circumstances be utilized to take control of the server hosting the database. An advisory which addresses this issue has been released. Contact Cisco for more information.

http://www.securityfocus.com/bid/27775

4) IBM Lotus Quickr Unspecified Cross-Site Scripting Vulnerability

IBM Lotus Quickr is susceptible to a Cross-Site Scripting vulnerability. Successful exploitation of Cross-Site Scripting could give an attacker the means to perform account hijacking, execute malicious scripts, or steal proprietary information. Fixes which address this issue have been released. Contact IBM for additional details.

http://www.securityfocus.com/bid/27840

5) Joomla! and Mambo Components Multiple SQL Injection Vulnerabilities

Multiple Joomla! and Mambo components are susceptible to SQL Injection vulnerabilities. SQL Injection can give an attacker full access to a backend database, and in certain circumstances can be utilized to take complete control of a system. No fixes have yet been released. Contact the vendor for more information.