Day 3: ITSM Vulnerability Assessment techniques
Lesson 3: After the first few days, we've covered securing WiFi, as well as basic software assurance tools to get you started with a web browser and crawler. This is just the beginning.
Part 1: Information assurance vulnerability assessment — Sandboxing insecure defaults and unnecessary services
Sandboxing is often referred to by many things, such as exploitation countermeasures, trusted paths, secure attention keys, and chroot jails (OS-level virtualization). Ruby on Rails, Java, and the .NET CLR provde virtual machines very similar in effect to OS-level virtualization, but at the application-level.
It is unfortunate that many operating systems include quite a lot of services, applications, and functionality that isn't required or properly sandboxed from other applications. There are also basic issues such as updating OS and applications while scanning networks for known vulnerabilities (widely described as vulnerability management).
Laying out kernel options, as well as disks mount options at build/install time are two major ways of sandboxing applications. One of my favorite ways to reduce the attack surface to Linux is the versatile GRSecurity. GRSecurity must be compiled into the Linux kernel. It allow Low/Medium/High security settings.
In the low setting, GRSecurity improves a few things, including race conditions on temporary directories, as well as improving chroot sandboxing. Medium security places restrictions on all sorts of insecure defaults, as well as improving chroot even further. The high security feature of GRSec is the most advanced, and includes PaX code. PaX is an implementation of ASLR. Some programs are broken because they require executable memory addresses, but PaX can be controlled with the `paxctl' command line utility.
If you're not familiar with GRSecurity, but have used SELinux -- then you might be familiar with access control concepts, such as the differences between discretionary and mandatory controls. GRSecurity controls role-based access controls (RBAC) using the `gradm' command line utility. SELinux can turn a discretionary system into a mandatory access control system (MAC), hardened by domain and type enforcement. We'll cover access control, sometimes referred to as authorization, much more in later posts.
Windows does have equivalents for these -- at least if you're using Windows XP SP2 or Window Server 2003. Other versions of Windows may support these concepts a bit differently. Instead of changing mount points, Windows cannot do much here -- but temporary file directories can be encrypted and the paging file can be cleared on shutdown. Access controls can be locked down further with CORE Force (a strong firewall and access control system from CORE Security).
Other operating systems have some equivalents, such as the BSD/MacOSX ports of systrace. There even exists SEBSD and SEDarwin projects that implement stronger access controls in similar ways as SELinux. Spending a few hours on a hardening guide when you install your OS can be extremely worthwhile in the long-run. This improves security exponentially when you're using a install server and standard images.
Recommendation: Deciding when and how to sandbox which applications should be based on measurements from past vulnerability management experiences. Using Nessus and patch management (e.g. OVAL-Compatible solutions from MITRE) will give you this information over time. I recommend a system to track vulnerability management reports such as Inprotect or Simpleness.
CVE, NVD, OVAL, and OSVDB information can also lead you to discovering potential places you would like to sandbox more functionality or find out more about these vulnerabilities. Applications seen as "at risk" can be handled by binary analysis to determine areas needed for secure inspection. Instead of using only bugreport and IDA/HexRays/BinDiff/ImmDbg -- I suggest moving highly critical (or high at risk) applications to a CWE-Compatible full-solution service such as Veracode. As the CWE-Compatible program expands to include CWE-Effective, medium-risk applications can move to the standard program while high-risk applications can move to the more effective solutions.
Running Nessus + Nikto, as well as using the CIS benchmarking solutions can augment measuring the success of a vulnerability management program. They can help you find out if you're missing a critical sandbox (or just need to tweak the configuration a bit), or have not hardened your standard images (and maybe not in a standard way). Combine with various hardening guides, found all over the Internet.
For more information via books, however, you could also read, "Network Security Hacks, Second Edition" from O'Reilly Press, "The Craft of System Security", or any of the various books on SELinux.
As a final note: whatever you do, make sure you get a safe channel/sandbox for your patch management delivery system. Which is why these tools need review such as OVAL, and probably multiple, third-party review (or first-party review through one of three CWE-Effective/Compatible solutions such as Veracode). Good application risk analysis also goes a long way.
Part 2: Software assurance vulnerability assessment — HTTP
Since we already mentioned Nikto today in the information assurance section of this post, I might as well introduce all of the good tools for learning HTTP. If you thought using your browser as your primary security tool was over, it has only begun. There are various great tools, and most of the best ones are available as an add-on.
Best HTTP request tampering tools
Tamper Data, Burp Proxy, Paros, OWASP WebScarab, Hunting Security Bugs' "Companion Content" Web Proxy Editor, OWASP Pantera, w3af, curl
Best HTTP request tampering helper toolsmetoscan, Syhunt Sandcat, N-Stealth Scanner Free Edition
You also may want to check out RFC 2616 and 2617, in addition to others you may come across (ie. the HTTP specifications). There is also an httpbis Working Group within the IETF and possibly even with some detectable activity.
It should be said that parameter (GET) and form-based (POST) tampering is 98% of web application security testing. All of the other vulnerabilities/attacks come from one of these two. Ever want to learn the difference between HTTP Splitting and HTTP Smuggling? Well, you best understand HTTP GET and POST attacks, including at the very least, concepts of header injection and knowledge of ASCII characters.
blog comments powered by Disqus