This device presents a telnet prompt on the standard port (23/tcp). This instance of telnet allows local users to login without authenticating. This gives the user access to the file system where they are able to manipulate files or grab the administrator password for the web interface. A fix is in development.
There’s a vulnerability in Oracle Siebel SimBuilder that could allow for remote system compromise. This vulnerability is related to a vulnerability in NCTAudioFile2.dll. The vulnerability affects version version 7.8.5 build 2635. Other version have not been tested so they may be vulnerable as well. Users should disable the affected ActiveX control. If you are affected by this and would like more information please feel free to contact us.
Tivoli Storage Manager Express is vulnerable to a heap based buffer overflow. This can be exploited by a malicious user on the network to cause code execution under the SYSTEM user. Versions of the software prior to 5.3.7.3 are affected. Administrators of this software should apply the updates available at ftp://service.boulder.ibm.com/storage/tivoli-storage-management/patches/express/NT/5.3.7.3/
Also, Oracle will be releasing critical patch updates Tuesday, January 15th. Several critical vulnerabilities in database software and application servers are expected to be announced. We will provide more details as they are made available.
There is a SQL “worm” spreading through the internet taking advantage of sites vulnerable to SQL injection attacks. The attack injects javascript in to all fields in the database that attempts to exploit browser flaws on clients that visit the infected website. Web developers should be aware of the increasing attacks using input validation errors as their attack vector.
We have received word of a working MBR rootkit that works on modern systems. Not a new concept, but one that hasn’t had attention for several years. Windows Vista allows users to edit the MBR from userland. A MBR rootkit has been discovered in the wild at the end of 2007. Keep an eye on this for more information coming in the future.
Today, I am putting my money where my mouth is. I have been talking about thinking differently about infosec as being a powerful tool in the future for several months now, but here are three concrete examples of how security folks need to think differently than they do today. (Note that some of you may have already begun to embrace these ideas – if so, awesome, you are ahead of the curve!)
#1 – Think like attackers AND defenders – We as infosec folks often get so caught up in our statements of ethics, credos and agreements about behavior that we get trapped inside them and become blind to the methods and ways of attackers. Many security folks I meet have taken such steps to distance themselves from attackers and they often show utter disdain for attackers, tools and techniques that they are essentially blind to the way attackers think. This is a dangerous paradox. If you don’t understand your opposition, you have no way of being effective in measuring your defensive capabilities. If you can’t think like an attacker, maneuver like an attacker and understand that they are not bound by the rules that you attempt to impose on them – then you will likely have little success in defending your organization against them. To better defend our assets, we have to be able and willing to understand our enemies. We have to have a realistic knowledge and capability to replicate, at the very least, their basic tools, techniques and attitudes. Otherwise, we are simply guessing at their next move. Essentially without insight and understanding, we are playing the “security lottery” in hopes of hitting the big defensive jackpot!
#2 – Deeper defenses are better defenses – We must extend defense in depth beyond an organizational approach to a data-centric approach. The closer to the data the controls are implemented, the more likely they are to be able to add security to the core critical data. (Of course, normal rationality applies here. The controls have to be rational, effective and properly implemented and managed – as always!) This is why security mechanisms like enclaving, data classification and eventually tagging are the future of enterprise security. If we start to think about our security postures, deployments and architectures with these ideas in mind today, we will be able to leverage them in their present state and eventually gain the maximum from them when they are fully ready for integration.
#3 – Think risk, not compliance – I am going to continue to talk about this, no matter how much heat I get from the “compliance guru set”. Striving for compliance with various regulations or standards is striving for the minimum. Guidance, regulations and law are meant to be the MINIMUM BASELINE for the work we need to do to separate liability from negligence. Compliance is a milestone, not a goal. Effective understanding and management of risk is the goal. Don’t be deceived by the “compliance guru set’s” argument that meeting baselines if effective risk management. It is NOT. Regulatory compliance, ISO/PCI compliance pays little attention to and has little management for attacker techniques like vulnerability chaining, management/analysis of cascading failures or zero-day/black swan (Thanks, Alex!) evolutionary capabilities. This step requires upper management education and awareness as well, since those that control the budgets must come to see compliance as a mile marker and not the end of the race ribbon!
I hope this helps folks understand more about what I am saying when I assert than in 2008, we have to think differently if we want infosec to improve. Of course, thought has to precede action, but action is also required if we are going to change things. What is clear, from the problems of 2007 and further back, is that what we are doing now is NOT WORKING. It should be very clear to all infosec practitioners that we are losing the race between us at attackers!
There’s a buffer overflow in RealPlayer 11. We don’t have much detail at this time, however it is reported that this can be exploited with a maliciously crafted file opened with a vulnerable version. Opening a malicious file will result in the execution of code under the context of the user running the application. The issue is reported in RealPlayer 11, other untested version may be vulnerable.
ClamAV version 0.92 contains multiple vulnerabilities. The first vulnerability is a race condition, where an attacker could generate a file with a specific name that would be called by a ClamAV function. This could allow the attacker to overwrite arbitrary files. The next issue is in the handling Base64-UUEncoded files. Attackers can create certain packed files that can bypass the scanner itself. The consequences of this should be self evident, and the possibility to occur is very real, due to the success rate of socially engineered emails and links.
More articles are emerging on the Nugache Trojan. Briefly, the Nugache Trojan is a very sophisticated piece of P2P controlled malware. Using decentralized management, nodes that can attach/detach, and encryption, this malware is a professional job. The authors of these articles seem to feel that the Storm and Nugache authors are the same, or share similar tactics. Once we see a full write up, we’ll post the details.
Everyone else seems to be blogging about it, so why not a “me too” blog from a different angle?
The main security questions people seem to be asking over the last few days are “Why are data theft and compromise rates souring? I thought that regulations like GLBA, HIPAA, various state laws, PCI DSS and all the other myriad of new rules, guidelines and legislation were going to protect us?”
The answers to these questions are quite complex, but a few common answers might get us a little farther in the discussion. Consider these points of view as you debate amongst yourselves and with your CIO/COO/CEO and Board of Directors in the coming months.
What if compliance becomes another mechanism for “doing the minimum”? The guidance and legal requirements are meant to be minimums. They are the BASELINES for a reason. They are not the end-all, be-all of infosec. Being compliant does not remove all risk of incidents, it merely reduces risk to a level where it should be manageable for an average organization. This absolutely does NOT mean, “have some vendor certify us as compliant and then we are OK.” That’s my problem with compliance driven security – it often leaves people striving for the minimum. But, the minimum security posture is a dangerous security posture in many ways. Since threats constantly evolve, new risks continually emerge and attackers create new methods on an hourly basis – compliance WILL NOT EVER replace vigilance, doing the right thing and driving defense in depth deep into our organizations. Is your organization guilty of seeing compliance as the finish line instead of a mile marker?
Not all vendors “do the right thing”. Vendors (myself included) need to sell products and services to survive. Some (myself NOT included) will do nearly anything to make this happen. They will confuse customers with hype, misleading terminology or just plain lie to sell their wares. For example, there are some well known PCI scanning vendors who never seem to fail their clients. Ask around, they are easy to find. If your organization is interested in doing the minimum and would rather pass an assessment than ensure that your client data is minimally protected, give them a call. They will be happy to send you a passing letter in return for a check. Another example of this would be the “silver bullet technology” vendors that will happily sell their clients the latest whiz-bang appliance or point solution for fixing an existing security need, rather than helping clients find holistic, manageable security solutions that make their organization’s security posture stronger instead of the vendor richer….
Additionally, many compliance issues reinforce old thinking. They focus on perimeter-centric solutions, even as the perimeter crumbles and is destroyed by disruptive technologies. Since regulations, laws and guidance are often much slower to adjust to changes than Internet-time based attackers and techniques, the compliance driven organization NEVER really catches up with the current threats. They spend all of their time, money and resources focused on building security postures and implementing controls that are often already ineffective due to attacker evolutions.
Lastly, I would reinforce that there are still many organizations out there that just simply will not “do the right thing”. They believe that profit surpasses the need to protect their assets and/or client data. They do not spend resources on real security mechanisms, fail to leverage technologies appropriately, remain careless with policy and processes and do little in terms of security awareness. There are a lot of these organizations around, in nearly every industry. They do security purely by reaction – if they have an incident, they handle that specific issue, then move on. Since consumer apathy is high, they have little to no incentive to change their ways. The only way to enhance the security of these folks is when everyday buyers become less apathetic and veto insecure organizations with their spending. All else will fall short of causing these organizations to change.
So there you have it. A few reasons why regulation is not working. I guess the last one I would leave you with comes from my 16+ years in the industry – good security is hard work. It takes dedication, vigilance, attention to detail, creative AND logical thinking and an ability to come to know the enemy. Good security, far beyond compliance, is just plain tough. It costs money. It is rarely recognized for its value and is always easier to “do the minimum” or nothing at all…
First it was Trojan firmware on network routers, firewalls and other network appliances. That was followed by attackers installing trojans and malware on USB keys and then dumping them back into those sale bins by the registers. Now, SANS is reporting that a number of digital picture frames sold by retailers were pre-infected with malware, just waiting to be mounted on a PC during the picture loading process.
As we have been predicting in the State of the Threat presentations for more than a year, the attackers have found new and insidious ways to turn the newest and seemingly most benign technologies into platforms of attack. Now that just about everything from refrigerators to washing machines and from toasters to picture frames have memory, CPU and connectivity – the vectors for malware introduction and propagation are becoming logarithmically more available. As computers, mesh networks and home automation continue to merge, we have to think differently about risk, threats and vulnerabilities.
Until we as security folks can get our head around overall strategies for securing the personal networks and tools we become more dependent upon each day, we have to rely on point tactics like wiping drives when we get them, reloading firmware on all devices – even new ones – from trusted vendor sources and doing the basics to secure home and business networks and systems. Hopefully, one day soon, we can build better, more proactive solutions like integrated hashing, malware identification and other mechanisms for alerting users to basic tampering with our devices. While we geeks are getting the wired world we always dreamed of, we are learning all too quickly that it comes with some unexpected risk…
Since MSI is a PCI scanning vendor, we are often included in various RFP/RFQ processes for the purchase of network scanning and assessment services. Over the last couple of years, one problem continually seems to raise its ugly head in RFP after RFP.
That issue is the lack of clarity in the RFP. Usually, the RFP issuer does not want to clarify the number of systems, applications, IP addresses or other relevant materials to the vendors. They want to keep that information private until after they award a contract. Below is a response I wrote this morning to a particular RFP issuer who is following this same pattern. Please read it and feel free to comment on the process, my response or any other items. I truly believe that only through communication, debate and eventual education can we find ways to take the customer and vendor pain out of these processes. Here is what I wrote in response to their posting about not wanting to reveal the number of IP addresses, except to the winner after the contract is awarded:
*Paste*
While I appreciate your process, I would suggest to you that your approach is not likely to achieve the best value for your organization.
Since you are choosing not to disclose the number of IP addresses to be assessed until after the winner is chosen, you essentially remove the very metric that the majority of scanning vendors use to create pricing models.
Thus, you force vendors to either respond with an hourly rate, or you force them to estimate the work and resources required. There is a risk to them and you in this estimation process. Their risk is that they could under estimate, thus causing themselves undue financial burdens. Your risk is that they will consistently overestimate, thus raising the prices that you get for a comparison and increasing the overall cost of the services you receive.
Of course, another possibility exists – that some vendors with ethical issues might respond to your lack of information by attempting to footprint your network and IP spaces to gather the relevant information themselves. Depending on their skills, tools and moral compass could cause a myriad of problems ranging from network congestion to denial of service attacks (inadvertent) as the various vendors who fit this model identify and map your visible Internet presence.
In our experience, the more information and clarity you can achieve in your requests for pricing information, the better. The clearer the scope of work, the more focused and relevant the responses will be and the more “real world” the costs. In every situation where we have seen prospects use the RFP process as a veil, the resulting engagements are damaged by scope creep, misunderstandings, miscommunications and higher than average costs in money AND relevant resources.
The most often quoted reason for RFP ambiguity that we have heard over the last 15 years is that the issuer did not want to “expose details to attackers”. After more than a decade and a half in this business, I have learned from experience that attackers already have exposure information. If they want it, they will simply map the network and gather it. They will also do so in ways that have little to no respect for your business processes, customer uptime commitments, maintenance schedules and other potential impacts to your business.
All of this said, again I respect your process and your right to proceed however you choose. Perhaps your intentions or requirements are not as presented above – which is fine. I simply wanted to address RFP/RFQ processes at large and I hope this information sparks discussion and comment among vendors and end-customers of security services alike.
*End Paste*
I went on to thank them for their inclusion in the process and to invite them to comment on this blog about the content. I hope they, and others do so. Please let me know your thoughts on this and other issues around RFP ambiguity. I would love to create a discussion between both vendors and customers about their ideas and feelings on the process!
Please remind teens, kids and adults who might receive computers for the holidays this year to patch them before general use. They should ensure that software and network firewalls are in place before connecting them to ANY network.
They should also ensure that they have anti-malware software that is up to date for any and all operating systems (even Linux and OS X) and that they follow other general guidelines of safe computing.
Remember, fight the urge to save the safety speech for another time. If the system gets compromised while they are using it for a test drive – being safe later will likely not help them be protected against bots, identity theft and other illicit computing dangers. It only takes one moment of exposure to compromise the system on an irreparable scale.
Happy and safe holidays to everyone. Have a joyous, peaceful and wonderful holiday season!
On Wednesday, 12 December, we posted about a vulnerability in HP software installed on laptops. Well, we now have reports that a working POC exploit that grants remote access exists. HP has provided a workaround by disabling the HP Info Center. More information, including the workaround, can be found at the following URLs:
ftp://ftp.hp.com/pub/softpaq/sp38001-38500/
ftp://ftp.hp.com/pub/softpaq/sp38001-38500/sp38166.html
Clam AntiVirus is vulnerable to remote exploitation of an integer overflow. This error is in the processing of PE files packed with the MEW packer. Exploitation of this vulnerability can result in execution of code in the context of the application running libclamav. If the clamd process is exploited, code can be executed under the context of the clamav user. This vulnerability exists within ClamAV 0.91.2. There is a workaround available by setting –no-pe when starting the clamscan. There is also an update available, which is version 0.92.
Multiple vulnerabilities have been reported in Adobe’s Flash Player. These affect Adobe Flash CS3, Adobe Flash Player 9.x, Adobe Flex 2.x, Macromedia Flash 8.x, Macromedia Flash Player 7.x, and Macromedia Flash Player 8.x. The vulnerabilities can result in a variety of outcomes, including Denial of Service and compromising users systems. There are updates available for each of the Flash players affected. Note that this will be the last update for Adobe Flash Player 7.
Additionally, there is a vulnerability that could allow system compromise in AIX 5.2, 5.3, and 6.1. The vulnerability is related to Perl Regular Expressions Unicode Data Buffer Overflow. There are interim fixes available here ftp://aix.software.ibm.com/aix/efixes/security/perl_ifix.tar.
Citrix Web Interface is vulnerable to an unspecified cross site scripting attack. The cross site scripting is in the online help portion of the software. More information can be found in the original advisory http://support.citrix.com/article/CTX115283