Monthly Archives: December 2008

A Web Application Cheat Sheet & More

Posted on by
Reply

I got a lot of response from folks about my last cheat sheet post. Here is another one that many folks might find useful.

This one, from Microsoft, describes quick references for the Microsoft Web App Security Framework. This is a pretty useful sheet and one that our techs use a lot.

I also find this one for Nessus and Nmap to be pretty useful.

I found this one for you CISSP study folk.

This one for PMP study folk.

And, lastly, for all the new waxers of armchair economics, this one about sub-prime mortgages…

OK,OK, I could not resist this one, THE INTERACTIVE SIX DEGREES OF KEVIN BACON CHEAT SHEET!

Hope you enjoy these, and now back to your regularly scheduled infosec blogs… 🙂

Welcome, Twitter Folk

Posted on by
Reply

If you’re reading this, it’s most likely because you’re curious if it’s worth following Brent or Mary Rose. Brent is the CEO and Chief Security Evangelist of MicroSolved, Inc., an information security company, and he’s an all-around great guy. He is passionate about safeguarding companies from all those nasty intruders out there like bots and phishing scams – not to mention all the inventive social engineering that is going on. (Please. No matter how much someone whines to you about having a terribly, bad, rotten day and giving your password to them will make it all go away – don’t do it!) Brent is always up to something interesting like creating Apple apps or battling evil in cyberspace. Definitely somebody you want to know.

Mary Rose had a posse of Italian uncles who made it very “desirable” for Brent to hire her as his MarComm girl or be pummeled into submission by a truckload of cannoli. He made a wise choice. Meanwhile, she’s busy figuring out the whole social media dealio when not working on updating the website design (Yes. Change is Coming), blog, marketing slicks, podcasts, videos and an unwieldy “customer relationship management” system. 

To follow Brent, go here.

To follow Mary Rose, go here.

I’m keeping count. So far, I’m beating Brent in followers. My Italian uncles are pretty effective.

Webcollage Agent Proxy Scans – Likely a Bot

Posted on by
2

Here is a quick example of a scan that we have been seeing a lot of lately, especially in our HoneyPoints deployed around consumer ISP networks. The example is about month old, but proxy scans are a very common occurrence.

HoneyPoint shows the following aler (some data modified for privacy)t:

XXX received an alert from 92.240.68.152 at 2008-11-08 09:57:07 on port 80
Alert Data: GET http://www.morgangirl.com/pics/land/land1.jpg HTTP/1.0
User-Agent: webcollage/1.135a
Host: www.morgangirl.com

Now, the XXX replaces the HoneyPoint location, so it remains obscured from the public.

This is a web server emulating HoneyPoint and it is listening on port 80.

The Alert Data: field shows the request received, which appears to be a proxy attempt to get a graphic.

The source of the request was 92.240.68.152 which the whois plugin shows to be (trimmed):

% Information related to ‘92.240.68.149 – 92.240.68.159’

inetnum: 92.240.68.149 – 92.240.68.159

netname: ADDIO-LTD-20080414

descr: ADDIO Ltd.

descr: Server farm Daype.com

country: LV

admin-c: AS11278-RIPE

tech-c: AS11278-RIPE

status: ASSIGNED PA

org: ORG-IOMA1-RIPE

mnt-by: lumii-mnt

source: RIPE # Filtered

organisation: ORG-IoMa1-RIPE

org-name: Institute of Mathematics and Computer Science of University of Latvia

org-type: LIR

Interesting in that the agent is likely faked as webcollage, a screen saver type application for displaying random graphics from the web. Another possibility on this event is that a previous scanner took the bait of the 200 return code from the HoneyPoint and added it as an open proxy. If that is true, then we may be on a proxy list and get to see many requests from people attempting to use open proxies. Getting a HoneyPoint added into these lists has given us great insight to web attacks, scams and phishing attacks in the past.

Now you have a variety of actions, you could block the source IP address to kill further scans and probes from that host. You could report the suspicious activities to the ISP in question. If a review of the web site that was the target showed illicit activity, you could also analyze and proceed to take actions to alert its owners as well. Many times these quick investigations have identified compromised hosts on both ends or compromised web hosts that are spreading malware. Plugins are available or can be created to automate many, if not all of these activities.

In this case, since this is simply a quick proxy attempt, and a cursory review of the target web site does not show any overt malicious activity, we will pass on this one and just use it as an example.

HoneyPoint can be used in a variety ways. Internet exposed HoneyPoints can give you deep insights into the types of targeting and exploit activity your networks are experiencing without the need to troll through immense log files or dig through noisy NIDS event patterns. HoneyPoint is great at collecting black list hosts, scanners and bot patterns. The longer clients use HoneyPoint, the more they discover that they can do with it. It becomes like a security swiss army knife to many clients.

Check out more information about HoneyPoint here. Follow me on twitter here to learn more about HoneyPoint, the threats we capture and other security and non-security info.

3 Improvements for Financial Applications

Posted on by
Reply

Our tech lab reviews several financial applications every year from a variety of vendors that are focused on the financial institution market space. The majority of these applications perform poorly to some extent in either security and/or usability. Here are three key tips for vendors to keep in mind when they or their clients ask us to do an assessment of their application.

1. Make sure the application actually works as it would in a production environment. Make sure it is reasonable in terms of performance. The idea of performing our lab assessment is to model risks in a real world simulation. Thus, if the system is not configured and working as it would in a real deployment, then the validity of the test is poor. Many of the applications we test simply do not function as expected. Many times, their performance is so slow and horrible that it impacts the availability metric. Basically, by the time it is submitted for the complete application assessment or risk assessment, it should work and be installed in a QA environment just as it would be in production. If there are any variances, be prepared with a document that explains them and their anticipated effects. Be ready to discuss and defend your assertions with a team of deeply technical engineers.

2. Do the basics. Make sure you meet an established baseline like PCI, ISO or some other basic security measure. That means ensuring that controls are in use to provide for confidentiality, integrity and availability. That means that you are protecting the data properly during transit, storage and processing. That means that you and/or your client have an idea about how to provide preventative, detective and responsive capabilities around your product. Make sure your documentation clearly explains any security assumptions or add-on products required.

3. Be ready to handle issues. If/When we find a security issue, be it overflows, input problems, and/or best practice variances, be ready to mitigate the issue and submit a fix. Many times it takes months for vendors to handle the issues we find and this is certainly NOT good for their relationship with the client. Almost every full assessment our lab conducts involves some kind of deployment timeline and crunch from the customer. Nothing seems to go worse for vendors whose products we test as when an issue is found and they become unresponsive to us and/or their client. Seriously, JUST DON’T DO THIS. Be prepared to apply resources to fix issues when we test the application. Very few applications (less than 2%) pass through the lab process without some sort of issue. This is NOT a basic process, it is a seriously deep, complex and heavily leveraged process for finding holes and measuring impact. Be prepared.

I hope this post helps both clients and vendors be better prepared for their testing. I think it gives the basic ideas for the approaches that we know do not work. We really want your applications to be secure, thus the level of detail we apply. Let us know if you have any questions. We are also about to open the lab registration window for 1Q09, so if you have applications you would like tested, let us know and we will try and get them on the schedule.