Vulnerability Reporting and Full Disclosure: Enhancing Security Practices

1. Vulnerabilities Reporting What works, and what doesn’t Black Hat Briefings, 1999 jrauch@securityfocus.com

2. 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

3. Outline... • Case studies • Via vendors • Via security vendors • Full Disclosure • Response teams • What we’ve learned • What should YOU do?

4. 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

5. The Players • Software vendors • Security vendors • Emergency response capabilities • Hackers • Security Enthusiasts • Victims

6. 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

7. 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

8. 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

9. Security Vendors • ISS, NAI, SNI, etc • Issue advisories on popular software packages • Spend $$ to find vulnerabilities • Use media exposure to sell product or services

10. Security Vendors... • Work with vendors to a degree • usually give time limitations • will release advisory as soon as patches are available

11. 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)

12. 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

13. 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

14. Problems with Issuers • Each method has good and bad points • Each has its proponents • Not all work very effectively

15. 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

16. 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

17. Problems with Security Vendor... • Rarely release full exploits or details • Hackers usually can figure out the exploits • Average, overworked administrator can’t

18. 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

19. 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

20. 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

21. 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.

22. 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

23. 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

24. 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()

25. Full Disclosure... • Vulnerabilities get the publicity they need

26. 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

27. 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

28. 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

29. Case Studies • Through Vendors • Sun SNMP • Sun getpwnam() vulnerability • Through vendor, via Security Vendor • Microsoft SNMP

30. Case Studies... • Full Disclosure • eEye IIS Vulnerability • Response Teams • Various

31. 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

32. 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

33. 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

34. 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”

35. 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

36. 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

37. 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

38. 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

39. 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.

40. 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...

41. 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

42. 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

43. What to do... • Lists continued… • Incidents Mailing list • Covers breaking threats and incidents • http://www.securityfocus.com • InfoSec News • Covers security related news • isn@sekurity.org

44. 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 • microsoft_security-subscribe-request@announce.microsoft.com • (Just about every vendor has a list)

45. 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

46. Questions? jrauch@securityfocus.com