**** ![](https://media.threatpost.com/wp-content/uploads/sites/103/2013/04/07055749/2ivan.jpg)In the early years of Core Security Technologies, the company not only offered security consulting services, but often was sub-contracted to do R+D for several security vendors. The first and most intellectually rewarding of such contracts came from Secure Networks Inc. (SNI), a Canadian start-up that was developing a network vulnerability scanner named Ballista Network Auditing System. Our contract work for SNI, plus a couple of local security consulting contracts, were largely responsible for the financial viability of Core in its early days and for that I will be always thankful to the SNI team.Ballista soon became the top competitor to the (then) incumbent Internet Scanner from Internet Security Systems, and in 1998 SNI was [acquired ]()by Network Associates (NAI) – known now as McAfee. After the acquisition, Ballista was renamed CyberCop Scanner and integrated into NAI’s CyberCop product line which over the course of the next three years was predictably crashed into the ground and [killed](). Despite its bitter ending, the Ballista vulnerability scanner set a milestone in the vulnerability management sector of the infosec industry. NAI’s acquisition of SNI, Cisco’s acquisition of WheelGroup Corp. which developed the competing NetSonar scanner, and ISS’ successful IPO all happened during 1998. After that year, it became clear that vulnerability assessment and intrusion detection software (WheelGroup and ISS sold IDS products also) would be a fundamental part of any enterprise security strategy. From a purely technical standpoint, I think Ballista’s focus on quality, precision, broad platform coverage and in-depth testing made it clearly superior to its competitors of the time. This is obviously a biased opinion since I worked developing that specific product along with three co-founders of Core and the world-class team at SNI – which included Al Huger, Oliver Friedrichs, [The Newsh](), Tom Ptacek, Jon Wilkins and a number of high-caliber contributors and contractors. The Core team’s work was mostly to develop software modules for SNI to check for UNIX vulnerabilities across multiple target platforms. Although we all usually self-selected and traded assignments, and worked cooperatively on specific issues, I usually leaned towards writing checks for network protocol weaknesses or for vulnerabilities in base services, particularly DNS and RPC stuff. To blow off the steam of our frenetic product development cycle and sharpen our skills we usually engaged in vulnerability research activities that resulted in the publication of [security advisories]() and [technical papers]() and/or contributed to the OpenBSD project doing source [code auditing]() and suggesting fixes to the problems that were found. Some of the bugs that I most enjoyed working on were related to Sun’s [Remote Procedure Call]() (RPC) components. In late 1997 I was working on the v2.4 release of Ballista developing a vulnerability check for the [Solaris automountd vulnerability]() (a CVE ID would be assigned to it 2 years later) which allowed attackers to remotely execute code as root on vulnerable Solaris systems. Writing a vulnerability check for this was very easy since exercising the bug only required making a legitimate RPC call from a remote machine to the AUTOFS procedure of the automountd program on the target machine. Exploit code that demonstrated the bug had already been [published]() and Sun Microsystems had issued a fix for the bug that simply made automount RPC endpoints not accessible from the network. However, because the actual functionality of the automount daemon depended on it, those endpoints had to remain accessible to local processes to be able to automatically mount file systems for local users. Thus the vulnerable RPC procedures were still accessible through local transports (which could be considered as the Solaris equivalent to Windows LPC). At the same time, I was looking into a couple of vulnerabilities in the Solaris statd RPC service as well. The [first]() was a simple directory traversal bug, the [second]() a trivial stack-based buffer overflow that apparently Sun did not fix when patching the first one. A patch for the second statd bug (it would not be the last) had already been issued by Sun as well. By then I was already very familiar with RPC, XDR and all NFS-related services since I had audited OpenBSD’s source code of those components and worked on a few other RPC-related checks, including one known problem in the portmapper service of many UNIX operating systems (rpcbind in Solaris) where a remote attacker could proxy (“bounce”) RPC calls through the target system’s portmapper server to other services using the PMAP_CALLIT procedure. [block:block=47] The combination of all these prior works coalesced and helped me figure out that the SM_MON, SM_UNMON and SM_NOTIFY procedures of statd could also be used to bounce RPC calls to any RPC service, and that since the RPC calls generated by statd would use the most appropriate transport from the perspective of the daemon process, RPC services only available through local transports were now made reachable from remote endpoints. Thus by carefully crafting the arguments passed to statd I was now able to write a remote vulnerability check for the automountd vulnerability. Yay! So, I wrote the remote vulnerability check for automount as well as a generic check for statd “bouncing” and didn’t think much of it. These checks (as well as those for the portmapper CALLIT and the statd buffer overflow) shipped to customers on April 22nd, 1998 in the Ballista v2.4 Beta2 [release](). Although at the time I was [already]() [familiar]() with the process of reporting vulnerabilities to vendors and publishing security advisories to help vulnerable users mitigate risk, I did not think my findings merited a bug report or security advisory. After all I had only combined existing knowledge or prior bugs and legitimate functionality to write a few vulnerability checks. Nonetheless, the folks at SNI reported the issue to several UNIX vendors then we agreed that a security advisory wasn’t necessary. On January 3rd 1999, eight months later, an anonymous poster to the Bugtraq mailing list [disclosed exactly the same findings]() with functional exploit code to reproduce it. Then on June 9th of the same year, six months later, CERT/CC issued an [alert]() warning about active “in the wild” exploitation of the problem and pointing to the relevant patches. The whole experience reinforced and shaped some of my thoughts about vulnerability assessment and research and disclosure of bugs: * The idea of programmatically combining multiple vulnerabilities to perform in-depth exploitation (pivoting) which would later be used extensively by Core in its flagship product, CORE IMPACT Pro. * The idea that overall risk may be a combinatorial calculation of the relationships between multiple vulnerabilities, rather than the linear sum of the risk of each individual vulnerability. * The idea that underestimating one’s own work and other people’s potential security findings, and, when in doubt, defaulting to non-disclosure, ends up as a losing strategy to help improve the overall security posture of vulnerable organizations. So there you have it, that’s why I’ll always reflect fondly on this particular research, because it helped reinforce why the research work we do today must continue, and when needed, actually see the light of day. _Ivan Arce is the CTO of Core Security Technologies. _ _This is the second in an occasional series of guest posts by security researchers, focusing on their favorite or most interesting piece of research. _

Query Builder