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