46
| Date post: | 14-Dec-2015 |
| Category: |
Documents |
| Upload: | shea-lampshire |
| View: | 214 times |
| Download: | 1 times |
Outline
• Goals
• Who are the players?
• What do they do?
• What are the problems?
• What works?
• Full Disclosure: The critic’s view
• Full Disclosure: The proponents view
Outline...
• Case studies– Via vendors– Via security vendors– Full Disclosure– Response teams
• What we’ve learned
• What should YOU do?
Goals
• Figure out what the state of vulnerability reporting and disclosure
• Determine the pro’s and con’s of each
• Determine what works and what doesn’t
• Figure out how to use this knowledge to improve your security
The Players
• Software vendors
• Security vendors
• Emergency response capabilities
• Hackers
• Security Enthusiasts
• Victims
Software Vendors
• What they do– Design and develop software– Sell it to you– Includes all types of software -- OS’s,
network utilities, word processors, etc
Software Vendors...
• What they think of security vulnerabilities– Don’t like them– Don’t want them to be found– Don’t want them to be publicized in the
event they are found– Want them to be quietly fixed
Emergency Response Capabilities
• CERT/CIAC/AUSCERT/FIRST, etc, etc
• Tend to be non-profit, and funded by government, educational, or vendor grants
• Limited budgets
• Tend to be reactionary
Security Vendors
• ISS, NAI, SNI, etc
• Issue advisories on popular software packages
• Spend $$ to find vulnerabilities
• Use media exposure to sell product or services
Security Vendors...
• Work with vendors to a degree– usually give time limitations– will release advisory as soon as patches are
available
The Hacker
• Wants to break in to your network
• Will typically not report a vulnerability to a vendor
• Might talk too much, give out exploits, and vulnerability will trickle to surface (someday)
Security Enthusiast / Full Disclosure
• Publish vulnerability to security “community” at large
• May or may not contact the vendor, or give long enough time for patch to be developed
• Disclose all details needed to exploit the vulnerability, sometimes even actual exploit
Full Disclosure...
• Embodied in mailing list like Bugtraq, Usenet security groups, NTBugtraq (to a degree)
• Motive is interest/desire to fix problems– Idealistic– Often, motive is personal publicity too
Problems with Issuers
• Each method has good and bad points
• Each has its proponents
• Not all work very effectively
Problems with Security Vendor Initiated Vuln’s
• Profit/Publicity motivated– Typically will use vulnerabilities to their
advantage, marketing wise– May sit on vulnerabilities for marketing
reasons– May cover up their own product
vulnerabilities
Problems with Security Vendor...
• Will sit on vulnerabilities for vendor relations– Usually want to be positively viewed by
vendors– Usually give time for patches
• Time delays lead to exposure– Often, bugs will trickle to the surface
while they’re being worked on
Problems with Security Vendor...
• Rarely release full exploits or details– Hackers usually can figure out the exploits– Average, overworked administrator can’t
Response Teams
• Report on vulnerabilities found in wild, or by others
• VERY slow– Will always work with vendor, to their
schedule– up to 6 months behind current
vulnerabilities
Response Teams…
• Primary function is to alert end users to known problems
• May be too late– 2 days may be too late, 2 months is deadly
Hacker
• Wants to break into your network
• Doesn’t want vulnerabilities fixed
• Doesn’t want you or the vendor to know about the vulnerability
• You never find out
• Tell their friends
• Usually results in big incidents
Security Enthusiast /Full Disclosure
• May give limited time to vendor
• Wants problem solved, but may not wait for an official patch
• Everyone gets the “exploit,” including the hackers
• May create a larger problem where none previously existed.
Full Disclosure: Why it’s Good
• Levels the playing ground– Everyone finds out about the vulnerability– Workarounds and temporary fixes are
almost always available, and are discussed.
• Vulnerabilities are exposed quickly– Prevents holes from being quietly
exploited– Allows for quick fixes
Full Disclosure: Why it’s Good...
• Large percentage of vulnerabilities caught prior to them being a problem– In any given week, as many as 15 new
vulnerabilities are exposed in forums like Bugtraq
• Keeps pressure on vendors– Many attribute full disclosure to new
proactivity on the part of some vendors
Full Disclosure: Why it’s good...
• Discussion of program flaws has led to better programming– No longer are there dozens of buffer
overruns being exposed every week– Same old mistakes aren’t being made– Introduction by many vendors of safer
versions of functions• snprintf()
Full Disclosure...
• Vulnerabilities get the publicity they need
Full Disclosure: What the critics say
• Full disclosure creates problems where they otherwise didn’t exist– Vulnerabilities always exist– Never assume they aren’t already in the
wrong hands• Vulnerabilities may exist in the wild even
prior to their disclosure– Irix buffer overruns
Full Disclosure: What the critics...
• Full disclosure amounts to little more than hackers legitimizing their exploit trading– Large % of those involved in full
disclosure are security professionals– Many are system administrators merely
trying to help others
What the critics say...
• Working with vendors is the quickest and best way to get things done– Vendors *have* to be slow
• Release cycles
• testing
• regression
– Usually try to limit disclosure of bug
Case Studies
• Through Vendors– Sun SNMP– Sun getpwnam() vulnerability
• Through vendor, via Security Vendor– Microsoft SNMP
Case Studies...
• Full Disclosure– eEye IIS Vulnerability
• Response Teams– Various
Through Vendors
• Sun SNMP vulnerabilities– Found and documented vulnerabilities in
April, 1998.– Allowed for remote users to gain local and
remote root access via undocumented, and non-removable community name
– Full details forwarded to Sun– Agreed to not publicize, allow Sun to
quietly fix in Solaris 7, and issue patches
Sun SNMP...
• What worked:– Vulnerabilities weren’t used in the wild– Solaris 7 was not vulnerable– Patches were issued
• What didn’t work– Fix took over 4 months to reach users, as
did news of the vulnerability– Patch was insufficient
Sun Solaris getpwnam()
• Vulnerability discovered in November, 1996
• allowed for local and remote root access
• Sun was informed, and given exploit
• Vulnerability was quietly fixed in a libc patch, 6 months later
Getpwnam()...
• What worked– Limited public exposure
• What didn’t work– Vulnerability was never publicized– Remained in wild for 6 months– Dozens of machines still vulnerable– Known in the “underground”
Via Security Vendor: Microsoft NT SNMP Agent
• Vulnerabilities discovered January, 1998
• MS reported immediately
• Work “began” to address the problem
• Advisory released by NAI in October, 1998
• Fix available in Service Pack 4
Microsoft SNMP agent...
• What worked– Patch was issued prior to widespread
problems
• What didn’t work– SP4 default setting for SNMP still allowed
for problems– SNMP fix was not a publicized part of SP4– Patch took 9 months
Full Disclosure: IIS Buffer Overflow
• eEye releases advisory to Bugtraq, June 15 1999
• Microsoft given 1 week prior notice
• Full exploit details released
• Workaround supplied
• Official patch/hotfix available within a couple of days
MS IIS Overflow...
• What worked:– Vulnerability got extensive media
coverage• ZDNet, Associated Press, Forbes, Wired...
– Patches quickly available
• What didn’t work– Machines that may have been otherwise
been ignored may have been attacked
Response Teams
• Not usually finding new vulnerabilities
• Days of 6 month delays are gone
• Still don’t issue advisories until vulnerability is already public, and patched.
Affects of Full Disclosure
• Vendors attempting to be proactive– Sun fixes numerous bugs in Solaris 7– MS fixing flaws in network security model
• Response Teams acting quicker
• OS’s getting more secure– Well, maybe not just yet...
Lessons to be learned
• Vendors tend to be slow unless the proverbial cat is out of the bad
• Hackers have the exploits
• Ignorance is *not* bliss when it comes to security
• Better to know and have to work around than to not know at all
What You Can Do
• Mailing Lists– Bugtraq
• Full Disclosure
• Covers all varieties of operating systems, network appliances, firewalls, etc
• http://www.securityfocus.com
– NTBugtraq• Pretty much full disclosure
• Covers only the Microsoft NT OS and apps
• http://www.ntbugtraq.com
What to do...
• Lists continued…– Incidents Mailing list
• Covers breaking threats and incidents
• http://www.securityfocus.com
– InfoSec News• Covers security related news
What to do...
• Summary lists– ISS
• Summarizes previous 2 week’s vulnerabilities
• http://xforce.iss.net/mailinglists
– Microsoft Security• Publishes security information from Microsoft on
security issues
– (Just about every vendor has a list)
Summary
• Vendor’s tend to hush security issues
• Security vendor advisories work, but have limitations
• Full Disclosure is the best way to know what’s going on prior to it becoming an issue
