by Mestizo on October 30, 2007
in SBN

Today I took was dealing with one of the countless ssh
brute force grinders running wild out there on the net. I was thinking that it would be cool if I could capture all the
username/password combinations they were supplying. During a search I ran across this
nifty little patch. I downloaded and attempted to use it, but could not get the patch to apply. After a bit of investigation, I determined that this patch was written for the OpenBSD-specific version of
OpenSSH and would not work on
OpenSSH Portable. Since I wanted to use this on my
Linux box, I had modify the patch to get it work.
The next thing I discovered, is that I really didn't like the logging format... The logs record Epoch time,
username, password, and
IP address... However, these are spread across 4
separate lines. So, a sample entry looks something like this:
1193780392
root
test
10.0.6.147
Not very easy to parse. Since I was interested in using the data for other things, I also decided to modify the logging as well. The format is still all the same fields, but now in a colon-delimited format, with one attempt per line. It now looks something like this:
1193780828:root:test2:10.0.6.147
1193788608:test:test:127.0.0.1I've placed
the patch on my
Google code site for now. Its not very clean, but appears to work with the portable version of
openssh for
Linux. I tested it on version 4.7p1 on
CentOS.
I'll attempt to clean it up and refine it later.
by Tom Olzak on October 28, 2007
in SBN
SOX Television, an inexpensive file encryption utility, and using TPM, Bitlocker, and Active Directory to secure laptop data.
by Mestizo on October 24, 2007
in SBN
by Mestizo on October 22, 2007
in SBN

Last month I was contacted by a professor from a university in the midwest. He had run across my posting on
DNS Best Practices and was requesting permission to include those in his course material. This material is being included in the curriculum for a Systems Administration class he teaches.
While this is both an honor and a privilege, the real kicker is that I am extremely jealous. I really wish that these sort of courses existed back in my college days. The closest thing available for me at the University of Houston where I majored in Physics, was an intro to computers they provided as part of my Physics major curriculum. We briefly learned about hardware (486 vs Pentium, ISA cards vs PCI, etc) and then we jumped into
Mathematica and how we could use it to do our physics homework. Unfortunately, like many of my fellow UofH students that year, about the only thing I did learn was which computers could and could not effectively run the now classic
Civ I game. ;)
by Mestizo on October 22, 2007
in SBN
Just a few links for security related tools and sites that piqued my interested in the past few weeks.
Hashmaster - Have a tool or application that is encrypting data, but you are unsure what algorithm is being used? Pass your application a string to encrypt and then pass those tow values to Hashmaster. It will make compare the values and attempt to identify the algorithm in question.
HITB Presentations - All the presentations from last months HackInTheBox Security Conference in Malaysia have been posted and are available to download. Pretty interesting stuff.
fierce.pl - By far, the best tool available for enumerating hosts via DNS. I had played with the very first version when it was announced, but had never bothered to follow up on subsequent releases. I recently downloaded and played with the most current version (0.9.9 - Beta) and was wholly impressed. A must have in any pen-testers toolbox.
Knoppix-NSM - A bootable LiveCD based on the popular Knoppix distro. This one has been customized to provide almost-instant NSM capabilities. Comes with Snort, BASE, Barnyard, ntop, and Squil. Was covered in this months copy of
Information Security Mag.
by Guy Snyder, ICSA Labs on October 21, 2007
in SBN
Next Generation of VPN Products Facilitates Secure Communications Across an Enterprise’s Network
MECHANICSBURG, Pa.—ICSA Labs, an independent division of Verizon Business, today announced that it has certified four products that use the newly enhanced Internet Protocol Security (IPsec) Virtual Private Network standard that helps validate the user or device, using the new key exchange protocol IKEv2.
(...)
by Mestizo on October 18, 2007
in SBN

(This is a bit more of a personal post than security related, but I will try to tie it in as much as possible.) I have a blogging policy that I don't mention my employers by name in my post or talk about issues directly related to them. However, today I am going to violate my own policy. ;) As of today, I have resigned my position here in the US as Director of Security Operations for
Revolution Health and have accepted a new role with a Thailand-based company.
Aware Corporation is a premier IT services, headquartered in
Chiang Mai, Thailand. This is an truly exciting company that I have been communicating with and tracking for 3+ years and the opportunities are practically endless. In my 10-year IT/ Security career, I can't recall ever being as excited to work for a company as this one!
I will be leaving the US later next month and beginning in my new role the first part of December. For those of in the industry and traveling to the region or already working in the region, please feel free to
contact me. I'm hoping to start occasionally attending
BangSec,
HITB, becoming active in the SE Asian security community, and building up my network of contacts on that side of the world.
Wish me luck!
by rudolph on October 16, 2007
in SBN
I was reading my buddy Alex Smolen's post the other day on Java Applet Security and figured I would see his post and raise it with a post on ActiveX control security. Actually, as you can probably see I have been slacking on the posting front so figured it is about time and this specific issue – ActiveX control security has been something I have been seeing a lot of in assessments but it doesn't seem to be covered enough in both the testing literature out there or indeed in secure development guides.
As it turns out, ActiveX controls are at the end of the day C++ or C# or (pick your favorite language) code so much of the guidance on secure application development continue to apply as you would expect. However, ActiveX controls obviously add another interesting dimension – they are mobile code and execute not on the server like typical web applications do but on the client machine. That means any vulnerabilities in this control place each and every one of your customers at risk. In fact with some popular ActiveX controls this is such a rampant problem given that they are installed on hundreds of thousands if not millions of computers across the globe. What perhaps exacerbates the risk even more is these ActiveX controls typically provide very powerful functionality by leveraging deep access into the client computer. This in turn can mean you are putting your users at risk even if you have no stereotypical vulnerabilities in your control code. Let me explain, why just not having buffer overflows and the like is not enough to protect your customers.
Well it all really comes down to the trust model and the sandbox built for ActiveX controls in the browser – Internet Explorer for the most part. Enter the notion as being "safe for initialization and / or scripting". The relevant MSDN documentation on this is shown here:
Initialization Security
When a control is initialized, it can receive data from an arbitrary IPersist* interface (from either a local or a remote URL) for initializing its state. This is a potential security hazard because the data could come from an untrusted source. Controls that guarantee no security breach regardless of the data source are considered safe for initialization.
There are two methods for indicating that your control is safe for initialization. The first method uses the Component Categories Manager to create the appropriate entries in the system registry. Internet Explorer examines the registry prior to loading your control to determine whether these entries appear. The second method implements an interface named IObjectSafety on your control. If Internet Explorer determines that your control supports IObjectSafety, it calls the IObjectSafety::SetInterfaceSafetyOptions method prior to loading your control in order to determine whether your control is safe for initialization.
Scripting Security
Code signing can guarantee a user that code is trusted. However, allowing ActiveX Controls to be accessed from scripts raises several new security issues. Even if a control is known to be safe in the hands of a user, it is not necessarily safe when automated by an untrusted script. For example, Microsoft Word is a trusted tool from a reputable source, but a malicious script can use its automation model to delete files on the user's computer, install macro viruses, and worse.
There are two methods for indicating that your control is safe for scripting. The first method uses the Component Categories Manager to create the appropriate entries in the system registry (when your control is loaded). Internet Explorer examines the registry prior to loading your control to determine whether these entries appear. The second method implements the IObjectSafety interface on your control. If Internet Explorer determines that your control supports IObjectSafety, it calls the IObjectSafety::SetInterfaceSafetyOptions method prior to loading your control in order to determine whether your control is safe for scripting. |
When it comes to ActiveX controls designed for the browser, it is more likely than not that these are marked as safe for scripting.
The problem is this approach is very binary – or in other words you can either mark an ActiveX control as never safe for scripting or always safe. Like we just said most developers will mark the object safe for scripting and all seems well. This is where it begins to get really interesting from a security perspective. A control marked as safe for scripting can be loaded by any and every web page developer whether they work for your organization or are the teenage, blackhat hackers down the street or in some dark basement half way across the globe.
Consider, now a familiar use case for an ActiveX controls – a control that lets you browse your local file system and add or delete files from / to the server. Developing this control just gave your company the award for most usable site on the entire World Wide Web and as they say business is good. Joe Hacker down the street is an avid user of your site and hence your ActiveX control realizes he might have a way to create a nice little botnet for himself through your ActiveX control. So here is what he does:
Creates a phishing site that looks perhaps just like yours or indeed anything else.
Within this site he loads your ActiveX control using the object tag he noticed in the HTML source of your website
Uses the interfaces, methods, events exposed by your ActiveX control within his fake website
You see where this is going, the more powerful your control the more power Joe Hacker has in his evil, evil hands …. Sigh L
So what is the solution you ask? As tempted as I am to leave that for another day and build on the suspense … I shall not J.
This is where the SiteLock template comes in. From the download page:
"The SiteLock ATL template enables an ActiveX developer to restrict access so that a control is only deemed safe when used in a predetermined list of domains. This limits the ability of Web page authors to reuse the control for malicious purposes."
Essentially SiteLock allows the developer to define a set of website domains (or Internet Explorer Zones) that are allowed to load this control. This information is built into the control itself and each time the control is loaded, it checks the site that is loading it to make sure it is part of the white list defined by the original developer. If not it will refuse to load. In fact SiteLock can also support "expiring" an ActiveX control after a certain time period. The idea being here is that functionality present in the ActiveX control can be disabled after a certain date. Both of these measures provide risk mitigation both against malicious (innocent as well actually) repurposing of your control as well as possibly lowers risk if the control were to have an unpatched vulnerability such as a buffer overflow. It is thus an excellent example of defense in depth and risk mitigation which is easy enough to code into the system and thus there is little reason for not doing so.
For the technically inclined the SiteLock template functions by providing its own custom implementation for the aforementioned IObjectSafety – IobjectSafetySiteLockImpl. This implementation provides the magic security sauce which does all the checking described in the previous paragraph.
References:
Designing Secure ActiveX Controls
Best Practices for ActiveX Control Updates
New Version of SiteLock Template
P.S. It is important to note that what has been discussed here bears no relation to whether the control is signed or unsigned which is what Alex's
post talked about. Instead it focuses on the properties of a legitimate ActiveX control. The browser will still show the regular warnings whether the control is signed or unsigned depending on how your browsing security policy is defined. It will however NOT let you know if the site attempting to use an ActiveX control is legitimate or malicious – it really has no way of doing that. So as a developer your action item is to make sure all your controls that will be hosted in a browser are protected using SiteLock. If your controls are never intended to run in a browser do not mark them as safe for scripting. Internet Explorer does not load such controls so problem solved!
If you are a end user then make sure the controls you use have this protection or hound the developers if you can until they provide this protection. In the meantime, refuse to load ActiveX controls whether signed or unsigned from untrusted websites!

by Tom Olzak on October 14, 2007
in SBN
Security enhancements in XP SP3, review of native data encryption, properly classifying security tests, Swiss move quantum cryptography into production, and DHS releases IT Security Essential Body of Knowledge.
by Mestizo on October 12, 2007
in SBN

When setting up a secure website, system administrators and webmasters often fail to perform very basic tasks that would greatly "shore up" the webserver. Here are 4 and half simple tips to secure your webserver, make it easier to monitor, and prevent it from sticking out like a sore thumb during a security audit.
1.) There are known security vulnerabilities and weaknesses in some SSL versions and encryption ciphers. SSL2 along with all weak and export grade SSL encryption ciphers should be disabled. In addition to being a good overall security practice, this is also mandated by the PCI Data Security Spec. (4.1). This can be easily done in apache by adding the following line to your config file:
#Disable SSLv2 and weak/ export grade ciphers
SSLCipherSuite ALL:+HIGH:+MEDIUM:!SSLv2:!EXP:!eNULL2.) When hosting a secure portal'ish site where the landing page is simply a login page, I like to force SSL only without requiring the user to remember that the site is SSL only. This can be easily accomplished in Apache by using a rewrite rule. This allows my server to still listen for regular http requests, but automatically rewrite those to https. Adding the following to your Apache config file will achieve this behavior.
#Redirect to SSLRewriteEngine OnRewriteCond %{HTTPS} !=onRewriteRule ^/(.*) https://%{SERVER_NAME}%{REQUEST_URI} [R]3.) TRACK and TRACE are not very well-known HTTP request methods that allow you to debug HTTP problems. These methods are very seldomly used (if ever) and there are a few known Cross Site Scripting (XSS) vulnerabilities related to them. This is a very common vulnerability that will be reported by almost every automated security scanner in the world and can also lead to failed security audits. Because of this, its best to disable them. Again we can use Apache rewrite rules to do this by adding the following lines to the apache config file:
#Disable TRACE & TRACK MethodsRewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)RewriteRule .* - [F]4.) Monitoring application logs is an essential part of any security program. Often time your access and error logs will be polluted with error messages that "robots.txt" file is not found. Essentially all this really is, is a list of rules that a search engine spider should follow when crawling your site. Each time an automated crawler visits your site, this file is the first thing they request. To prevent this error from filling your logs, you should create a simple text file named "robots.txt" and place it in the root of your web directory which will still allow crawling of everything. The contents of the file should be:
User-agent: *Disallow:4.5) The next thing you will see constantly polluting your error logs are failed requests for a file named "favicon.ico". This file is the small little logo you see in your browser's address bar when you visit some sites or in your bookmarks when you bookmark that same site. This file is requested by the users browser at the beginning of EVERY visit to your site. Because of this, the failed request can quickly fill up your log files! An easy way to fix this is to copy a
blank favicon.ico in to the root of your web directory. Alternatively, if you are feeling especially creative you can create a custom favicon
here or
here.