Wednesday, December 2, 2009

Fun with URL Shortener Chaining

While trying to think of a clever way to RickRoll my friends on Facebook earlier without any sort of link previewing taking place, I started messing around with some of the shortening services. TinyURL disallows shortened URLs that are already TinyURL shortened, as shown below:


However, TinyURL DOES allow shortened URLs from other services, and other services also allow this behavior as well. If you try chaining a shortened URL through bit.ly, your users/victims will be prompted with a warning like this one:


However, there are plenty of other URL shortening services out there. You can find some other ones here. Using zi.ma, I took a TinyURL link and shortened it via zi.ma. Then, I took the zi.ma URL and shortened it via TinyURL.


I did this twice, TinyURL to zi.ma, then zi.ma to TinyURL and finally TinyURL to zi.ma again. Only by repeating this sequence twice, Facebook essentially gave up on trying to resolve the origin of the link.


My real curiousity is in how this technique would work against web malware filters such as those found within IE and Firefox, as well as what Google provides via its search engine?? Is this technique already being used heavily? What if a site KNOWN to host malware were inserted into an IFRAME on a good site, and using this technique the link was chained through multiple iterations. Would they still flag this behavior when indexing the site and making the determination as to whether or not its a "safe" site?

Thoughts??

-Jack

http://zi.ma/8ac792

Wednesday, November 25, 2009

Jack's X-Mas List

Dear Santa,

I know I'm likely to be on your naughty list this year, but I still want gifts anyway. Why? Because I'm Jack Mannino....stop asking questions. My list is short and sweet, and its for the greater good of the security community. Please see my demands below:

1- I want people to focus less on certifications, and more on learning the fundamentals behind whatever they are working on. If someone's job is to assess web applications, I don't want to hear about the 10 domains of CISSP. I also don't want to know about how he/she learned about some cool tools while taking the CEH boot camp. I want them to understand HTTP, be able to understand and manipulate Javascript, and know a thing or 2 about SQL itself. If they want to charge $200 an hour but are unable to tell me what the difference between a 302 vs 500 status code is, they deserve a big lump of coal in their stocking! If you are a "penetration tester" and you can't tell me what the TCP handshake is, you should get coal as well!

2- The world would be a better place if there was less "marketing" and more "doing" going on. Don't try to convince me that your product is better than the next guy's because its cheaper and "more mature." Show me how it is. When you send salesmen out that have zero experience in the field, I am largely unimpressed. Also, don't try to convince people that your product is superior because it helps meet compliance standards. Convince them that it ultimately makes them more secure by showing them real data and evidence, not something staged to work perfectly against Hacme Bank.

3- If you give me just 1 gift this year Santa, I'd like for it to be for people that don't actually enjoy security to find new jobs. Maybe they can come to the North Pole and work for you? When people say "nah, I don't bother with this stuff outside of work", it takes away the holiday cheer!! It demoralizes those of us that genuinely love what we do, and makes it harder to achieve progress.

Thanks Santa,

Jack

Saturday, November 14, 2009

Internal Web Server IP Leakage Via Public Crossdomain.xml Files

So this one is pretty interesting, and happens in a lot more instances than I originally thought it would. The public crossdomain.xml file for this particular server shown below has references to internal web servers via "allow-access-from-domain." What this means is that the developers have given their internal servers the ability to read data from the Flash domain of their external server. Without going too deep into the nitty gritty of Flash and crossdomain.xml, read Adobe's (much better) explanation here.

What you will see (and should take away) from this picture below is that these are internal resource addresses of very critical resources, likely internal websites.


This gives you the immediate connection that there is a sort of transitive trust likely present. As the external site trusts the internal site, the internal site likely trusts the external site. If XSS or any method exists to have users execute malicious Flash objects while visiting the external site from within the NAT gateway (where the 10.x.x.x addresses are relevant), it may be possible to easily launch attacks on internal web servers. The Flash objects could contain scripting and attack code to launch from within the INTERNAL USER's browser, with code to do things like perform SQL Injection on an internal server. Internal web servers won't typically be afforded much attention, and they often go without proper code reviews or development processes. It is assumed that because they are internal, they are unreachable. Not at all the case.

More to come...might have shifted my submission for Shmoo to this area. Lots of fun stuff to explore.

-Jack

Thursday, November 5, 2009

The Hidden Costs of Fully Outsourcing




With the boom in outsourcing and fully managed IT services as well as Software As A Service (SaaS) and "the cloud", a huge amount of debate has already taken place. Tons of cost models are out there comparing the benefits of each, but sometimes it helps to look past the raw numbers. When an organization completely outsources EVERYTHING, they do so at the cost of developing internal capabilities to mirror the exact same services being rendered. This leads to vendor lock-in, and when an organization eventually decides to begin managing their processes internally they are essentially starting from ground-zero. If 4-5 years have gone by, they've likely had a large staff turnover. In addition, anything they owned internally may be severely dated, both from a technology and best/most efficient practices perspective. The end result is that a huge investment may be required in order to maintain the same level of capability on their own.

Looking at it from that angle completely changes the outlook on the overall dollar amount. While it may have been cheaper while things were good (no benefits to pay, 401k matching, etc), upon a messy breakup they end up investing roughly the same amount of money. So does that mean outsourcing is a terrible idea? Not at all. A certain level of external expertise is an absolute requirement. These services should be used in a way that compliments their existing capabilities rather than replaces them. The ability to maintain flexibility and freedom can often be cheaper, as well as a lot less of a headache.

And the debate rages on.......


-Jack

Friday, September 11, 2009

Commoditized Security Is Optional




So after watching Bruce Schneier's hour long sales pitch for outsourcing all of your IT solutions, it really made me wonder what standards most companies are using nowadays to truly evaluate who they outsource to. Just because a company is large, "reputable", or acknowledged by Gartner does not mean that they can 1-cater to ALL of your needs or 2-offer you the strongest technical solution. In fact, in my opinion the larger a company gets the less likely it will be that their service offerings will be tailored upon to what you ACTUALLY NEED. While a company may excel in software development, or data center virtualization, it doesn't have any bearing as to whether or not they can provide solid web application security services. Similarly, if a company is well-known for their security services, it doesn't necessarily mean that they'll do well at IT help desk management.



Since security is obviously a highly lucrative field for many companies to pursue, naturally they've flooded the market with their services....everyone wants to make a buck. There are companies that "do everything", and there are companies that are highly specialized. Something each and every one of you with procurement power should ask yourselves is "Would I take my car to someone for repair that is well-known for fixing boats, or should I take my car to the guy that fixes cars (and more specifically, Toyota's)." The same concept applies here. One could argue in defense of the do-it-all types that their solutions may have a more "worldy" view of the security field vice looking at knowing a lot about a specific niche. The main argument against these do-it-all companies would be that as a result of their business model, the skills that their consultants bring to the table might be very diluted. Using web application security as an example, rather than knowing a ton about Javascript, Flash, and various server-side web technologies and frameworks, they know a little about each, in addition to knowing how to lock down routers, firewalls, operating systems, and spam filtering. So what you are essentially paying for in the end is just a little bit of what you need, and a lot of what you really don't need. This is the same concept as going to the store and buying a variety pack of underwear that comes in different sizes...so while all you needed was 3 pairs of large underwear, you are now the proud owner of small, medium, and extra-large underwear that you really don't need.



This isn't to say that all companies offering highly specialized services are perfect. In the end, you really need to do your homework on them, what they do, what they've done, and ultimately, what they plan to do for you. If they offer you an in-depth application assessment, but upon asking them what their "methodology" is, they say its a 4 step process: step 1- blindly run a scanner, step 2-validate scanner noise, step 3-send you a bill, step 4- repeat steps 1-3 again and again...then it may be time to evaluate another vendor. If you are using a SaaS vendor that says "we scan, don't really tweak our scanner, don't really look at the output, and we just hand you a report loaded with stuff", keep looking for the right vendor. Price is always important, but receiving top-notch services for that price is more important in my opinion. While the price of an in-depth assessment will differ greatly from what a SaaS provider offers, you should also understand the differences in levels of effort put forth. Both have their place in the overall security process (a discussion for a rainy day), but again do your homework!! Ask them what differentiates them from their competitors, aside from price and what their public relations people have branded them upon. If their proposals are made up of marketing fodder, generic contract speak that doesn't even remotely pertain to you, and an overall "solution" that seems like its a template with your name on it, this might be an indicator of what their services will be like. Ask them what they've done to improve the broader state of security, how they plan to address any complexities in your environment, or even better: ask to speak to the security person that will actually be performing the work, instead of a sales person who will tell you exactly what you want to hear. If the person who you'll ultimately be paying for can't answer questions that they weren't coached on or prepared for in advance, has no clue about your specific technology, and can't name at least 1 online resource they use to remain current with their respective field, it might be time to look elsewhere.



Getting back to the beginning of this post, while a lot of organizations may indeed be increasing their level of outsourcing over time I don't feel that they should simply "bow" to the larger companies that would love for nothing more than to push all of the smaller companies out of the market (or acquire them). What you get is what you pay for, and if you don't do your own due diligence prior to breaking the piggy bank, it may end up costing you a lot more than you realize. Outsourcing is here to stay, but companies that choose to drive innovation will avoid commoditization, no matter how badly Bruce Schneier wants you to believe it =)



-Jack

Tuesday, September 1, 2009

Up Next: More Blogging!!




I'll be posting much more often in the coming weeks and months. For those of you that still haven't deleted me from your RSS feed lists, look for some web application security posts that'll hopefully be informative and inspire some healthy debates.

-Jack

Saturday, June 20, 2009

My Response to a Dangerous Idea

This post is in response to Jeremiah Grossman's latest entry titled "Legalize It (Hacking GOV and MIL websites)". Before reading the rest of my post, please read his first, which is here.

So to sum it up, such an initiative as the one he has described would be far from free, and I intend to explain my theory within the next few paragraphs.

One thing I'd like to state upfront is that I acknowledge similar activities are ongoing as we speak. I am not taking a naive and utopian view of how this stuff wouldn't happen regardless of whether or not it is legalized or encouraged. My underlying theme should be interpreted to be that opening this stuff up to the general public from legality and encouragement perspectives may not be the most cost-effective solution afterall, nor the safest, which I will tie up with recommendations for better solutions at the end of this post.

So why is this both a dangerous suggestion and an irresponsible one at best? First, Department of Defense systems aren't Paypal. They aren't intended to drive profits, but rather intended to support the needs of warfighters. It really all starts off with understanding the needs of the organizations in question, before making recommendations for what they need. Unlike Paypal, who can allocate as much funding as possible to tolerate increased loads being placed on their systems (downtime = lost revenue), many groups within the government survive on shoestring budgets, believe it or not. As someone who has been around the DoD for quite some time in his career, I can attest to the fact that legalizing such behavior would likely require many entities to upgrade their infrastructures to even come close to handling the likely volume of traffic that would be generated. Every script kiddie, and every researcher trying to make a name for himself, would be throwing tons and tons of traffic at targets that were never intended to handle such a considerable load. So rather than finding a few holes and smiling at the end of the day, you'll be denying legitimate and in many instances, critical applications, from being utilized for their original intent. An alternate solution to this would involve tons and tons of red-tape being placed around the initiatives in order to maintain some type of positive control, which in government terms = sucking the value out of the process. The very first time someone messes up by either testing during off-limit production hours, testing from an alternate source address that isn't registered, or DoS'ing a site, it'll be a real nightmare.

Secondly, consider what the ramifications would be for both legal and incident handling personnel. Imagine being an incident handler on an already undermanned team that was already overloaded with say X unique and credible leads to follow per day. Suddenly, you have X plus a million daily, with most of them being the result of loud and obnoxious traffic generated by automated tools. So should these groups simply say "ok, its legal...better not investigate this", or should they still do their jobs, which is to determine what may or may not be live and ongoing attacks, or what may or may not be pre-attack probing? Wouldn't this lead to attack identification efforts being increased exponentially? If this were to occur, what would be a definite side effect? INCREASED MANNING REQUIREMENTS!! The last time I checked, adding team members wasn't free.

Surely it isn't feasible to think that opening up and encouraging pentesting efforts by the general public would be without the risk of questionable entities going above and beyond the "engagement rules" set forth by the respective agencies. So instead of being able to state with confidence that any incidents that may occur are inherently true incidents, there would be a sudden blurring of what is real and what isn't. As if it wasn't already borderline impossible to keep up with pre-attack probing and actual attacks in the average security operations center (SOC), it would only get much worse. The result would not only increase the loads placed on incident handling groups, but also on legal personnel as well. Each case could have its own set of unique twists and turns based on the type of technology in use, and could quickly become very costly to pursue offenders.

There are some companies in this world that I'll agree that this type of open environment is well suited for. Twitter, Facebook, Google's myriad of online services....yes. These "big 3" are all in existence for the sole purpose of generating revenue. They are also very homogenous organizations in comparision to the government and DoD, which have very intricate reporting structures both within, and to external agencies as well. The "big 3" do not deter anyone from accessing them, and never will do so, because they are all profit-driven. Therefore, it wouldn't make sense to discourage this behavior. For government systems, it pretty much will never be the intent for the general public to have a want/need to access them. Public companies encouraging researchers and anyone else in between to test their applications, enable a collaborative community in doing so. It results in publicity, both good and bad. Publicity = garners interest. This is exactly what profit-driven companies want.

Government systems do not exist for these same reasons. The information contained within them is often classified or considered "sensitive","for official use", or "secret" and above for a reason. The collaborative communities putting forth research efforts and pentesting efforts should therefore come from within as well. Rather than opening pentesting and security initiatives up to the general public, it should be done in a controlled manner, such as paying for the talent to perform the work. In doing so, the work can be coordinated and optimized, so that testing is not detrimental to critical operations. My view is that if there is a considerable cost associated either way, it might as well be invested in a way that will ultimately lead to better processes being created internally, vice the same widespread dangerous coding and general lack of security that exists today. It doesn't make sense to spend a ton of money developing an application, only to place it online and then get knocked over 3 hours later by a script kiddie. The cleanup efforts are enormous, and the wasted time and resources in fixing bugs that should have been identified in development, is downright sinful. Bringing the true talent in, and paying for it, could prevent this stuff in the development lifecycle, as well as in pre-deployment testing. Repeatable processes lead to greater cost savings, as opposed to leaving it in the hands of the unknown and simply hoping for the best.

I do not disagree with Jeremiah's point that too few organizations within the government have the capability to perform rigorous testing on their applications. In fact, I praise him for making this point, and reiterating it many times through his blogging, Twittering, and press statements. It is certainly an issue that affects everyone, whether we realize it or not. You certainly don't have to be a warfighter to benefit from the increased security afforded to the ones keeping us safe day in, and day out.

-Jack