Spliced feed for Security Bloggers Network |
Bad Behavior - Thoughts on the Malicious Insider [BlogInfoSec.com] Posted: 30 May 2008 06:00 AM CDT Following every high-profile insider security breach, there is usually a slew of vendors who will triumphantly point out that, had they installed their product, the victim company would have avoided the whole painful problem. The adverse publicity, the implementation of new Draconian controls, the reprimanding and firing of “my best employees,” the souring of relationships with customers and business partners, and being subjected to continuous audits - all these horrors might never have happened “if only they had had the right products in place.” But let’s be honest about it (even if only to ourselves). In the first place, nobody really knows the scope of the insider threat. Numbers of around 70 or 80 percent of total incidents are attributed to insiders. I happen to think that the number is much higher, probably of the order of 95+ percent - and here is why. If you were to look at the ways in which various incidents are reported, an interesting pattern emerges. Outsider attacks are more likely to be picked up, and stopped from turning into actual incidents, through the use of tools such as intrusion detection and prevention systems (IDSs and IPSs). Insider incidents, on the other hand, are more likely to be discovered by chance because the perpetrator got careless or greedy or both, and his or her activities were noticed by an alert employee or in the course of an audit review. Now I ask you, what percentages of actual nefarious activities are identified for external versus internal transgressions? I would guess that 50 percent or more of external attacks and only about 5 percent of internal misdeeds are captured. So let’s assume we know of 70 internal incidents and 30 external incidents, this being the approximate breakdown that one might expect. However, if you accept my guesses, the total populations are calculated to be 1,400 internal incidents and 60 external incidents. This would mean that some 96 percent of incidents are internal, but we only find out about one in twenty or so. OK, so we have tools that are really good at calling out known anomalies. But if we believe that the ratio of known to unknown internal incidents is very small, say 5 percent, then we see our problem as not being able to capture so many more suspicious internal activities. But fear not, there are many vendors appearing over the horizon, each with a particular method for resolving a particular problem. Is this bad? No, not really. In fact, it is good to see so many creative approaches. We have to start somewhere, and a number of these products are pretty good and have enormous potential. The noteworthy point is that there is no single silver bullet here. We need a variety of tools using pattern recognition and artificial intelligence (I prefer the term “adaptive systems”) in order to tease out patterns of irregular behavior from the morass of noisy data. I have seen one product that applies the brilliant technology used in the human genome project to determine the whereabouts of a few drops of sensitive data in an ocean of corporate information. Other innovative approaches learn what is considered to be normal behavior and give the alarm when that behavior changes significantly. Some products capture data in motion, others data at rest. Some track sensitive data leaving an organization, others within the organization’s boundaries. Despite these differences, the tools have many things in common. The key issues with many of these products are the following:
As we enter a new era of more difficult-to-detect exploits, we need monitoring tools, defenses and preventative methods that are up to the escalating threats. It is no longer enough to identify and act upon known exploits. Increasingly we are seeking out technologies that can second guess criminals, even when the bad guys are “trusted” employees, contractors, business partners or even customers. Such products need to understand the nuances of normal behavior in order to minimize false (or unprovable) accusations and ensure that practically all provably nefarious activities are identified and resolved. Old-line signature-based methods are becoming less and less effective against increasingly successful exploits that operate under the normal radar. While they still have a role, traditional antivirus products alone cannot do the task at hand. Hence the proliferation of more sophisticated behavioral products. However, with the latter often being more difficult to deploy, there is much work to be done before they become as plug-and-play as the marketplace is demanding. So what do we do in the mean time? First, it would be a good idea if we all shared amongst ourselves the anomalies that we find and monitor. That way we don’t all keep on reinventing the wheel, as it were. After all, the bad guys share all the time, to the extent that the (good?) hackers have even set up their own social network “House of Hackers.” Second, we should encourage those systems that prevent people from getting into trouble rather than those that catch the perpetrators after they have done something bad. The great benefit is that you avoid all the unpleasantness of investigating and punishing someone, and punishing yourself by having to fire and replace otherwise excellent workers. And third, you should invest in today’s products even if they are not quite ready for prime time, since you are likely to achieve some unanticipated advantages. If too few of us encourage this approach it will take forever to get tools to the level at which we really need them, by which time we’ll be even further behind the crooks. So buy them, try them, and perhaps you will realize some short-term benefits while waiting for the systems to mature. Copyright © 2008 BlogInfoSec.com. This feed is copyrighted by bloginfosec.com. The feed may be syndicated only with our permission. If you feel that this feed is being syndicated by a website other than through us or one of our partners, please contact bloginfosec.com immediately at copyright()bloginfosec.com. Thank you! Again, please contact copyright@bloginfosec.com so we can take legal action immediately. | ||||||||||||||||||||||||||||||
what you see is what ... wait ... not really [Belgian Security Blognetwork] Posted: 30 May 2008 05:46 AM CDT | ||||||||||||||||||||||||||||||
Belgium.be is not vulnerable anymore for SSL based attacks [Belgian Security Blognetwork] Posted: 30 May 2008 04:10 AM CDT Our friends at Scanit said that based on their research into vulnerable SSL enabled webservices in Belgium, they had found that the old belgium.be was vulnerable for such attacks. For some these middleman attacks were theoretical because they would ask a lot of resources, for others it was just a best practice to enforce a strong SSL protocol on your visitors that was even not too hard to implement. For me it is just one thing you do because you don't want to be bothered with it. There is every hour of the day other stuff that asks for all your attention. So it seems they not only upgraded the content, but also the security. Thumbs up for that. The study by Scanit.be was published here a few weeks ago. | ||||||||||||||||||||||||||||||
Hearings EVOTING in Belgium in the parliament [Belgian Security Blognetwork] Posted: 30 May 2008 03:37 AM CDT Next tuesday 10h
It will be a good thing - because to hear what has happened and is happening in Holland. We thank the parliament for taking some time to listen to those experiences and thoughts also. Vooreva will present the Belgian opposition to evoting. | ||||||||||||||||||||||||||||||
Proxy ARP by default ? [Belgian Security Blognetwork] Posted: 30 May 2008 02:57 AM CDT not a biggie but if you decide to move from any vendor to the Cisco ASA platform. You might be in for some deep digging. At least we were :-) Apparently Proxy ARP is enabled on ALL interfaces by default. In our case that resulted in ALL printing to cease on the local subnet (let me point out that was the first perceived problem). So, watch out when you fire up your ASA . | ||||||||||||||||||||||||||||||
buy all music at Russian prices on Belgian domain [Belgian Security Blognetwork] Posted: 30 May 2008 02:10 AM CDT ... over the Internet of the iSound.com materials is authorized by the license # LS-3М-06-60 of the Russian Multimedia and Internet Society (ROMS). ... All the music you want at dumping prices
with a Russian copyright
you can find them on a Russian server
It maybe interesting to not that the site isound.be looks just the same as justmusicstore.com Some people may think that it may not be safe to use your creditcard on a Russian server..... | ||||||||||||||||||||||||||||||
Who you gonna run to? [Network Security Blog] Posted: 30 May 2008 12:59 AM CDT Alan Shimel faults me for saying sometimes you just have to walk away, in reference to TJX firing Cryptic_Mauler (the upper/lower case stuff is too much for me to type again and again). Alan talks about illegal behavior, turning your employer in to the authorities, standing up for your morals to do what’s right. Of course, he ignores the fact that nothing TJX is being accused of is illegal; stupid, yes, but not illegal. And the fact is there’s no one to turn TJX in to, not in the government and certainly not at the PCI Security Council or the major credit card companies. Cryptic_Mauler was in an untenable situation: his employer was practicing the worst sort of security, they didn’t want to change, there’s no one he could report them to. Alan wishes there were someone CM could have reported TJX’s woefully inadequate security practices to, but if such a entity exists, I’ve never heard of one. The best thing he could have done was report the problem to TJX’s acquiring bank, but unless you’re really into credit card processing, the chances are you’ve never even heard of an acquiring bank let alone have any idea of who to call. I like Alan, but asking me why I didn’t list reporting TJX to the authorities as an option is like asking me when was the last time I spoke to the Easter Bunny! Neither one exists! (my kids don’t read this, so I can say that). It’s fine to talk about taking the high moral ground when you’re living in a fantasy world, but the reality I live in doesn’t have anyone Cryptic_Mauler could have gone to to report TJX. I really wish it did, I could have used them myself in the past. And why doesn’t the PCI Security Council have some way of reporting offending companies? I’ll hazard a guess and say they’ve probably talked about establishing just such a capability and decided against it in the strongest possible way. After all, if they had a way for someone to report violations to, that’d make the Council responsible for acting on those reports. And that’s something they really, really don’t want. But that’s only a guess. | ||||||||||||||||||||||||||||||
What's the deal with the Barracuda offer for Sourcefire? [StillSecure, After All These Years] Posted: 29 May 2008 11:50 PM CDT By now you probably saw that Dean Drako and Barracuda have made an offer of $7.50 a share (in cash) for Sourefire. This values Sourcefire at about 200 million dollars and is a 13% premium over the Friday closing price. Of course this is well below Sourcefire's historical highs, but than again who is worth what they were a few months ago. I have a chart on the left that shows stock prices. So what is behind this deal? I think it is all about ClamAV and the Trend Micro suit. As readers of my blog know, Trend Micro sued Barracuda a few months ago for patent violations around the way Barracuda uses ClamAV in its appliances. I think Dean was looking to Sourcefire as the owners of ClamAV to step up and help in the defense of the suit. I believe to date, that has not happened and Dean is upset with it. In fact Dean actually mentions that suit and Sourcefire's lack of response on it as one of the two reasons why Barracuda's acquisition would make sense. For the other reason Dean takes a swipe at the Sourcefire management team, saying "We believe that the recent FIRE stock price reflects the execution challenges faced by the company's management to date." I am not sure where Dean comes up with the 200 million to complete this deal, but assume he has lined up financing. However, at this price I don't think this is more than a stunt. If Barracuda goes beyond $7.50 a share to $10.00 a share or so, it gets real interesting. Maybe this puts Sourcefire in play and someone else comes forward with another offer, who knows. But right now I think Dean is just looking to stir the pot. | ||||||||||||||||||||||||||||||
When do you have an obligation to go public? [StillSecure, After All These Years] Posted: 29 May 2008 09:13 PM CDT No, not IPO public, but public about disclosing employer secrets which could provide a risk to the public. My friend Martin McKeay has written an article over the recent firing of an employee of TJX for disclosing in a public forum continued poor security practices by TJX. The same TJX I might add that as a result of slipshod security practices caused 100s of thousands of dollars, if not millions of dollars in bank fraud to occur. | ||||||||||||||||||||||||||||||
Do you have an example for FUD Watch? [StillSecure, After All These Years] Posted: 29 May 2008 08:47 PM CDT My friend Bill Brenner has landed as Senior Editor at CSOonline.com. His latest article is introducing something called FUD Watch. Bill has had enough of his mailbox being full of every chicken little saying the sky is falling with the latest security threat. He gives on of many examples but is asking for others. An obvious one is the recent Symantec call for everyone to stop using Flash. Than today, it retracted saying that in fact the latest version of Flash was not vulnerable. | ||||||||||||||||||||||||||||||
Keynote Speakers for The Last Hope Announced [Liquidmatrix Security Digest] Posted: 29 May 2008 08:46 PM CDT Just a heads up — Liquidmatrix Security Digest will be at The Last Hope. There may even be some shwag available.
… and since I’m temporarily in charge — shwag is only available to those who recognize me. | ||||||||||||||||||||||||||||||
Security Brieflet (the late edition): May 29th [Liquidmatrix Security Digest] Posted: 29 May 2008 06:57 PM CDT A couple of interesting stories over the course of the day… Comcast Defaced (for a short while) I can’t say that I’m all that saddened… it is Comcast after all. Banks don’t disclose all breaches I’d love to argue this one, but I’ve known too many bankers. Back with more Liquidmatrix Love in the morning folks, the night is young and I’ve got work-related documentation to produce. Tags: information security news, opinion | ||||||||||||||||||||||||||||||
Hack of the day : Fedis hacked since long time [Belgian Security Blognetwork] Posted: 29 May 2008 05:06 PM CDT Fedis is the official organisation that defends the interests of the distribution sector and is so busy in those turbulent inflation and inflamatory times that they forgot to secure their server and didn't see that their server has been hacked since weeks. http://www.fedis.be/index.html which gives - gave
reminder these hacks are being found in zone-h.org and by Googling, we don't hack anything, reporting it is already taking enough time from my life | ||||||||||||||||||||||||||||||
Disclosing in a public forum is not whistle blowing [Network Security Blog] Posted: 29 May 2008 04:02 PM CDT Last week TJX fired one of their employees for disclosing on ha.ckers.org that TJX is using blank passwords and other very insecure procedures. Posting in what he thought was an anonymous manner, CrYpTiC_MauleR was tracked down by management at TJX through his ISP, asked what he felt is wrong with the TJX network and fired. And as bad as I feel for him personally, I think TJX did the right thing. Don’t get me wrong, I have very little sympathy for a company like TJX. They had one of the biggest credit card breaches in history, they’ve been put through the ringer and they still have the temerity to allow such bad practices as blank passwords and running servers as admin. I’m hoping TJX’s acquiring bank, PCI assessor and Visa/Mastercard get wind of these issues and call them on the carpet for it. But I don’t excuse the actions of Cryptic_Mauler. I’ve read most of the thread on sla.cers.org, and this appears to be an issue of venting frustration, not whistle blowing. If Cryptic_Mauler was talking to federal investigators or maybe even a reporter, I might call it whistle blowing, but by disclosing it in a security forum, it was simply a way of pointing the finger at the stupidity of his employer. It’s not a case of full disclosure either, since that usually refers to We’ve all been in situations where we have employers doing stupid things. We do our best to communicate with management about the problems and hope they react appropriately. The problem is, our perception of ‘appropriately’ and management’s is often very different. What we see as a horrible security hole, they may see as another minor problem that would take major money to fix. Or just as something that they don’t want to think about right now. There’s no reporting mechanism built into the Payment Card Industry standards. To the best of my knowledge, there’s no clear cut method to report a company that has bad practices to the credit card companies or the government at all. There’s not even a press person you can talk to about the issues with to bring it to public awareness. It’s frustrating because, despite their known issues, TJX is probably far from the worst offender and there needs to be a way to make these people sit up and take notice. But that’s no excuse for posting the issues with the TJX network in a public forum. Cryptic_Mauler isn’t a security professional. He wasn’t even a part of the IT team. But he was an employee of the company and as such was held to certain expectations. Keeping internal company issues internal is one of those expectations. I don’t like how TJX is apparently handling their problems, I don’t like that they aren’t responding more positively to internal criticism, but I don’t see that they could have taken any other action in this circumstance. I’ve had to resign from a job before because the company wasn’t being responsible in my opinion. I’ve seen companies in the past that shouldn’t be allowed to have computers let alone an ecommerce site. I’ve been at companies that I wondered how they stayed in business, not even considering their security concerns. But I always tried to react ethically and within the bounds of my moral obligations. I’ve learned that I can do what I can do and sometimes I have to walk away and let someone else deal with the problem. Public disclosure doesn’t fit in my world view of ethics and morality. It’s frustrating dealing with a company that doesn’t want to change. It’s hard not having leverage to make the changes that you see need to be made. How you react to that frustration is up to you. Do you scream in public like Cryptic_Mauler, keep going until you find someone who can make the change or do you move on to another opportunity? I hope Cryptic_Mauler can find a new position somewhere else; I hope the limited notoriety this incident gives him will help him further his career. But I think he made a mistake in publicly disclosing TJX’s problems, one I hope doesn’t continue to haunt him. | ||||||||||||||||||||||||||||||
There Is No Silver Bullet ! [Belgian Security Blognetwork] Posted: 29 May 2008 02:07 PM CDT You know I earlier posted my pov on anti-malware and how it may 'disappear' in the future. I feel it still serves a role, as a feature on gateway products (talk proxy-servers, content filter solutions and/or perimeter firewalls) or as a service like it is now to be found in managed e-mail washingmachines. The question is always : how will the industry manage licensing for these services ? And will it be possible to cover the costs to maintain their global teams of analysts ? It is basically the same for most of the technology security 'solutions' today. | ||||||||||||||||||||||||||||||
online typosquat testforms are not complete [Belgian Security Blognetwork] Posted: 29 May 2008 10:09 AM CDT If you thought that you had enough by just relying on these online forms like the one from combell than you will have to think again First not all combinations of numbers are included in the examples they are giving - so you will miss some that are even more evident Secondly you must really retype your own domainname and take three typical mistakes typing erroris with the letters next to those you would type for example baby.be can become babu.be babr.be bqby.be etc the most important factor here is that it is not too evident Secondly you must take into account dyslexic mistakes for example byba.be instead of baby.be thirdly you must take into account language mistakes, especially with people who don't speak your languages or if they operate in a multi-langual environment for example béby.be
everything should be tested, and retested and for that you will have to buy them for a year - the problem is that if you buy them and set them free, they will arrive in the list of disposed domainnames which will attract the attention of domainspeculators, surely if they see that you have bought them yourselves or with your real agent You can use them for inspiration, but not as a final call | ||||||||||||||||||||||||||||||
As if you needed more reasons to use NoScript: Flash [Network Security Blog] Posted: 29 May 2008 09:50 AM CDT I’ve made no secret of the fact that I’m a big fan of Firefox and the NoScript plugin. I don’t want anything running in my browser that I don’t explicitly approve of. And now with the big rise in sites compromised with the latest Flash exploits, there are more reasons than ever to use NoScript. I don’t use Flashblock myself, but it also comes highly recommended for dealing with this issue. The interesting thing to me is that this attack is a combination of SQL injection against the servers and a payload containing the Flash exploit. If the compromised sites had made the effort to use good coding practices and checked for SQL injections, this wouldn’t be a big deal. Another alternative would have been a web application firewall. This is 2008, not 1998, SQL injection is low hanging fruit on the security tree and most of the sites compromised should have something in place to stop SQL injections. But they don’t, so we have a nice outbreak of Flash exploits. Security Focus stated that there were approximately 20,000 compromised web pages as of Tuesday. That sounds like a lot until you figure out the math and realize that this may mean 2000 or less machines compromised, depending on the average number of pages per system. I guess 2000 doesn’t get the clicks nearly as well as 20,000 does. | ||||||||||||||||||||||||||||||
Security Briefing: May 29th [Liquidmatrix Security Digest] Posted: 29 May 2008 09:19 AM CDT Wheeeeee… I’d like to take this moment to again bitch and moan about how much work this is — I don’t know how Dave finds the time and I’m not a morning person and I feel really bad and I’ve been busy and I don’t have enough coffee and… yeah. I got nothin. Have a Rockin’ Thursday! Thanks to all of our new subscribers that joined us yesterday. Welcome! Click here to subscribe to Liquidmatrix Security Digest! And now, the news…
Tags: News, Daily Links, Security Blog, Information Security, Security News | ||||||||||||||||||||||||||||||
Webinar Alert: They’re Letting Us Speak Again! [RiskAnalys.is] Posted: 29 May 2008 08:30 AM CDT Our friends at Cisco have asked Jack Jones to be part of their InfoSec Leadership Forum Webinar Series. He’ll be talking about FAIR and risk in a two part series and I really think you’ll enjoy watching. The good news is that you’ll even get a free copy of The Zero Day Threat from Iron Port just for signing up. The bad news is, they opened registration yesterday afternoon and it’s already half full. Here’s the link, get on it!: | ||||||||||||||||||||||||||||||
The Final Step in a Homegrown IDM Solution (pt. 3) - So, let’s start hammering [BlogInfoSec.com] Posted: 29 May 2008 06:00 AM CDT To recap briefly, we have identified and analyzed all our primary sources of user data and the system and service providers who consume those data. We have funding, developers, and a project plan to follow. We understand our provisioning process, have identified or built a directory of user attributes, and have generated policies and procedures to initialize and terminate users. In short, we are finally ready to build our IDM system. The key to our success is crafting a web service that generates identities and binds a user to one. Because we are going to some pains to create and assign these identities and because your associates may over time be located in different geographies, be sourced by different systems or play different roles, there is significant benefit, from operational and compliance perspectives, to reconstruct their history with the organization. A single identity is your only hope of accomplishing this aggregation. As you design your service, identify the attributes that are most distinctive about each associate. In certain instances, a government-issued identifier, like the Social Security Number (SSN-USA) or Social Insurance Number (SIN-Canada) may be available. These numbers are useful because they are unique identifiers assigned, managed, and maintained by a trusted source. Unfortunately, given the proliferation of and sensitivity to identity theft, use of such identifiers is severely constrained, even in those jurisdictions where they are available. However, as mentioned in a previous post, one of the advantages of building your own robust identity system is that you can both protect the identifier and prevent its proliferation elsewhere in your organization. Strong access controls ensure more sensitive attributes are only available on a business need to know basis. Be aware though, that even a government identifier is no panacea. In my former experience building an enterprise identity system, our analysis of source systems identified multiple instances of SSNs and SINs with the same values requiring that we include a country code field to distinguish them. Our North America HR system was not so prescient and was forced to create “fake” identifiers for our Canadian staff with the same values as an American counterpart, leading to unfortunate technological gymnastics at tax reporting time. So, use a government identifier where available. But for all the instances, particularly in a global organization or where the Privacy Office has run completely amuck, you will need more attributes. Within reason, more is better because each additional attribute, assuming it is from a trusted and maintained source, reduces the number of false positive results your service might identify. Examples of other useful attributes are:
You may have identified others but ensure that they are valid, maintained, and enduring. For example, college of attendance or current address could change over time, though place of birth would not; however, providing data integrity for the latter can be a challenge (e.g., I could be born in Dorchester, Massachusetts or Boston - the former is part of the latter and is often used by residents as their city name). Once you have gathered your attributes, determine their level of criticality. Other than date of birth, most other attributes, at least, theoretically can change. Assign a weighting to each attribute. Each source system, either in batch or transactionally (we used both approaches simultaneously, depending on the system’s capabilities), sends an agreed upon data set for each new record. Your web service retrieves the records and compares them to your data store of existing identities. Ideally you have leveraged your most complete and accurate directory for this, or have used multiple vetted sources to build your own. For each attribute matched, assign the record the point value of the attribute type (e.g.,, 10 for government identifier and date of birth, 9 for last name) and once all the matches have been made compare the score to the expected score if every attribute matched perfectly. Set a baseline for a definite match, realizing that not all attributes may be the same because of typing errors or missing fields. If using a transactional approach return as XML the existing organizational identifier for that person and provide some way - we used a dialog box - of letting the user doing the data entry to review and accept the proposed update. Give the user an “opt-out” option in case their review suggests the proposed identity is not for the record in question. For instance, consider having a capability to flag records of deceased staff and VIPs so their records are never part of a results set. An opt-out choice should also generate an alert to identity program staff that there may be an issue with the matching protocol. If there are several potential matches, rank them by score and have at least the top three to five results displayed to the data entry user and allow them to pick one or none. In this case, opting out should prompt the data entry user to create a new id, thereby initiating a new call to the identity store that returns the next incremental identifier. When no matches exist, a new identifier is automatically returned. Batch processes would work similarly but some sort of exception reporting would be necessary identifying the various types of matches and probably some sort of holding area would be necessary to ensure that source system records are not updated until proposed matches have been accepted and new identity creation initiated. We actually found that the transactional approach was more manageable assuming the source system was able to consume the XML. Those systems also need a way to ensure that their newly created records could not migrate to downstream systems until the identities are assigned. That constraint ensures full compliance with a managed identifier for all. In future columns on provisioning, governance,contractor management, and access control reviews, I will describe how to best leverage the unique identifier throughout the organization. By building our own identity management system, we were able to completely change for the better the operational and security culture of a complex global organization. I hope you experience the same benefit. Please feel free to share your stories. Copyright © 2008 BlogInfoSec.com. This feed is copyrighted by bloginfosec.com. The feed may be syndicated only with our permission. If you feel that this feed is being syndicated by a website other than through us or one of our partners, please contact bloginfosec.com immediately at copyright()bloginfosec.com. Thank you! Again, please contact copyright@bloginfosec.com so we can take legal action immediately. | ||||||||||||||||||||||||||||||
The Daily Incite - May 29, 2008 [Security Incite Rants] Posted: 28 May 2008 10:17 PM CDT May 29, 2008 - Volume 3, #52 Good Morning:
Top Security News Drawbacks or not, security will be embedded into the network
Top Blog Postings Blow chunks whistle blower | ||||||||||||||||||||||||||||||
Advisory: CiscoWorks Arbitrary Code Execution Vulnerability [Liquidmatrix Security Digest] Posted: 28 May 2008 08:56 PM CDT Summary Name: CiscoWorks Arbitrary Code Execution Vulnerability Risk: High Description CiscoWorks Common Services versions 3.0.3, 3.0.4, 3.0.5, 3.0.6, 3.1, and 3.1.1 contain a vulnerability that could allow an unauthenticated, remote attacker to execute arbitrary code with elevated privileges. This vulnerability exists due to an unspecified error in CiscoWorks Common Services. An unauthenticated, remote attacker could exploit this vulnerability to execute arbitrary code resulting in complete system compromise. Impact: Arbitrary code execution with elevated privileges. Fire bad. TimeLine Discovered: 14 February 2008 Technical Details The vulnerability exists due to an unspecified error in CiscoWorks Common Services when it processes attacker-supplied URLs. An unauthenticated, remote attacker could exploit this vulnerability through unspecified means to execute arbitrary code with elevated privileges. Fix Information This issue has now been resolved. The patch may be obtained from: Cisco Advisory I would like to thank Cisco for their professional response to this issue. Liquidmatrix Security Digest 2255B Queen Street East | ||||||||||||||||||||||||||||||
Apple also released Security Update 2008-003 [Random Thoughts from Joel's World] Posted: 28 May 2008 08:52 PM CDT
Issue: Files that are not designated for sharing may be accessed remotely Solution: Deny access to files and folders that are not inside a folder designated for sharing Credit: Alex deVries and Robert Rich
Issue: Multiple vulnerabilities in Apache 2.0.55, including cross-site scripting. Solution: Apache is updated to version 2.0.63 to address several vulnerabilities Note: This is for Mac OS X Server 10.4.x systems, since Leopard ships with Apache 2.2.x.
Issue: Maliciously crafted file, unexpected application termination, arbitrary code execution Solution: Improved validation of document files. Credit: Rosyna of Unsanity
Issue: Vulnerability to unexpected application termination, arbitrary code execution Solution: Improved bounds checking.
Solution: Additional validation of embedded fonts. Credit: Melissa O'Neill of Harvey Mudd College
Issue: Vulnerability leading to disclosure of sensitive information Solution: User prompts
Issue: Vulnerability leading to unexpected application termination or arbitrary code execution Solution: Additional validation of length parameters.
termination or arbitrary code execution Solution: Proper initialization of pointers
Issue: Lack of prompting against opening "certain potentially unsafe content types" in Automator, Help, Safari, and Terminal Solution: Enhancements to Download Validation in Mac OS X v10.4, and Quarantine in Mac OS X v10.5 Credit: Brian Mastenbrook
Solution: Validation of environment variables
Issue: Arbitrary code execution Solution: Updating to version 9.0.124.0
Issue: Vulnerability to application termination or arbitrary code execution Solution: Improved bounds checking Credit: to Paul Haddad of PTH Consulting
Issue: Vulnerability to unexpected application termination or arbitrary code execution Solution: "Improving reference counting in the affected code" Note: This issue only affects pre-Mac OS X 10.5 systems. Credit: Rodrigo Carvalho of Core Security Technologies
Issue: Disclosure of sensitive information Solution: "...replacing invalid character sequences with a fallback character."
Issue: Path traversal vulnerability Solution: Improved URL handling Issue: Privilege elevation Solution: Improved handling of temporary files
Issue: Out-of-bounds memory read leading to information disclosure Solution: Additional validation of BMP and GIF images Credit: Gynvael Coldwind of Hispasec Issue: Multiple vulnerabilities in libpng version 1.2.18 Solution: Updating to version 1.2.24 Issue: Vulnerability to unexpected application termination or arbitrary code execution Solution: Additional validation of JPEG2000 images.
Issue: Remote vulnerability to unexpected system shutdown due to undetected failure condition Solution: Proper detection of the failure condition. Issue: Local user vulnerability to unexpected system shutdown due to mishandling of code signatures Solution: Perform additional validation of code signatures
Issue: Race condition preventing MCX preferences being applied Solution: Eliminate the race condition Issue: IPv6 vulnerability leading to unexpected application termination, information disclosure, or arbitrary code execution Solution: Properly initializing variable. Credit: Derek Morr of The Pennsylvania State University
Issue: Remote vulnerability Solution: Mongrel updated to version 1.1.4
Issue: Password disclosure in sso_util Solution: Make password parameter optional, force sso_util to promp Credit: Geoff Franks of Hauptman Woodward Institute
Issue: Remote vulnerability to information disclosure Solution: Improved handling of error messages Credit: Don Rainwater of the University of Cincinnati | ||||||||||||||||||||||||||||||
Magic Security Bunnies [Liquidmatrix Security Digest] Posted: 28 May 2008 06:53 PM CDT Primarily because Brooks asked, but also because there are a whole lot of days where I face the “Magic Bunny” problem. Simply put, in any complex system - say, an application stack which has a backend database, some application servers, some presentation servers and the connecting security stuff and network stuff - there are a number of Subject Matter Experts who need to be at the table when troubleshooting. The issue is that as far as each is concerned, the other areas of expertise are the domain of Magic Bunnies. The Application folks don’t really grok the network glue stuff and so they talk about how one machine “can’t see” the other. The database guys don’t grok the need for a firewall between them and the world because it makes things difficult to administer and there is where you’ll find more Magic Bunnies. Too often when I get called in on a troubleshooting swat team, it’s because as the security dude, I’m always more aware of the entire picture (grok the whole) than the SMEs and I can walk them through the problem from foundational Layer 0 stuff (is the data centre still there?) through to the Layer 9 stuff (is there a god who cares?) And damn if every time I sit in on one of these sessions, we don’t discover that there isn’t a nice overlap between areas of expertise and there’s a huge number of Magic Bunnies infesting our applications. Do you have Magic Bunnies? Is there a spray or ointment? Chat amongst yourselves. Or the bunny gets it. |
You are subscribed to email updates from Security Bloggers Network To stop receiving these emails, you may unsubscribe now. | Email Delivery powered by FeedBurner |
Inbox too full? Subscribe to the feed version of Security Bloggers Network in a feed reader. | |
If you prefer to unsubscribe via postal mail, write to: Security Bloggers Network, c/o FeedBurner, 20 W Kinzie, 9th Floor, Chicago IL USA 60610 |
No comments:
Post a Comment