Tue, 08 Apr 2008 08:56:27 GMT
by pdp

Here is the story. The other day I was messing with some crypto. After going through some pretty interesting stuff, I've suddenly realized something which is very, very obvious when you think about it. Indeed, obvious and simple things are harder to grasp. It is a paradox, I know.

It is again another case of using security technologies for criminal purposes. Let's take HTTPs as an example. When attacking a Web server, HTTPs is the attacker's best friend because it could potentially bypasses whatever security appliances the victim might have in between (IDS, IPS, etc). I am not saying that this is universal but it works very often. In simple words, because the traffic is encrypted, the security appliance wont be able to understand what the encrypted channel holds and as such wont do anything if an attack is launched against the destination server. This is an example of a security technology which is designed to prevent attacks but at the same time turns to be a huge advantage in the wrong hands.

Ok this is boring. Let's think about SPAM and Drive by Download attacks. SPAM - harder but not impossible. Google does an excellent job to remove spam from my mail box. But what if the SPAM is encrypted? There is no way you can tell whether the message inside is worth something. Not to mention that emails and public keys which are required to encrypt the message and send it to the right people, are two types of information which are available online for free. There are many Public Key Servers which attackers/spammers can use.

If I was a malware author I would probably aim to infect key resources which could give me enough power later. I would target Corporations, Businesses, Organizations etc. I could use them for Black PR, whatever. So I would go, query PKI Servers and download emails addresses plus their associated public keys. Some companies have their own PKIs visible on the Internet. Then I would send the malware but encrypt it with the individual public keys for each email. Add a catchy title and a fake email address. Submit those to the targets and wait until the crops are ready. Then harvest. Sure, such emails will pass through mail filters as they seem to be valuable for the business and at the same time impossible to read. There you go, now you have a mechanism to break into companies in large scale attacks.

The conclusion is: encryption is good, encryption is bad.

The information security industry has built its reputation and the top of fear. Anyone who has been long enough in this field knows that any network, any appliance is hackable given enough time and a good opportunity. Therefore, buying fragmented, modularized, and very generic security tests is bogus. It wont work. You cannot go to the doctor and ask for a list of every possible decease that can happen to you. Companies who are interested in knowing about their security should specify clear objectives which needs to completed by the tiger team by any means necessary. "How can someone reach that data? How can someone steel money?" These are the types of questions you should ask, not things like: "Find me all security issues affecting my business!" It won't work for you no matter which way you look at it.

Archived Comments

Awesome AnDrEwAwesome AnDrEw
I'm quite sure Ronald said something along the lines of "security is dead" on several occasions, which I would definitely agree with in conjunction with your statement regarding any device being vulnerable to attack "given enough time and a good opportunity". Technically and theoretically speaking one has infinite amount of time in which an attack can be perpetrated against a network, server, web application, et cetera. The overall goal of security is to be as locked-down as physically possible while taking into account that it is very likely that there are unforeseen vulnerabilities which may affect the device. That being stated there really are two sides to each issue, and both positive and negative usages for every technology found within the security spectrum.
Agree 2 u. Security is not an xploit, vulnz etc. Security is a process, sometime paranoia :o))
Yep, this story is like egg of Columbus. (http://en.wikipedia.org/wiki/Egg_of_Columbus if someone does not know this story) The answers are wandering around us and someone only need to pick up one of these and security hole is ready, well in hacking case. It might sound obvious or trivial but someone has to be first one :) I just read one block post today and saw nice picture of javascript which uses quite same idea. I mean, encrypting "bad code" bypassing security checks. (http://bp0.blogger.com/_wICHhTiQmrA/R-xO8l280_I/AAAAAAAABgI/lxphF6tu7LQ/s1600-h/seo_poisoning_obfuscated.jpg)
That's just too weird PDP...a fellow analyst and I were just talking about PGP and not making your public keys available in common key repositories, just for this reason.
Time is a limited ressource (in several ways) for an attacker. Bugs getting crushed by disclosure, opportunity to attack ,etc. "The overall goal of security is to be as locked-down as physically possible while taking into account that it is very likely that there are unforeseen vulnerabilities which may affect the device." Security is the anticipation of compromise?
Adrian 'pagvac' PastorAdrian 'pagvac' Pastor
The exception of HTTPS *not* hiding the attacker's vulnerability probes is the IDS/IPS being hosted on the target server itself, as opposed to an intermediate server/appliance.
Awesome AnDrEwAwesome AnDrEw
Physically time is indeed a limited resource, which is why I stated it as being theoretical, however I do believe to an extent security is as you have put it the anticipation of compromise. Several months ago Ronald had made a post, which I believe was on sla.ckers, stating that we must come to grips with the fact that such events are inevitable no matter how well you believe something to be secured. Oddly enough last week Ronald's website, 0x000000.com, was hijacked to which he responded, "I told about it before, I can secure myself to the bone, I could have a 256 char NASA password, but if my host password == 'QWERTY'..." We really must take into account the fact that security is very broad, and not simply limited to being application-oriented. Vulnerabilities exist within every layer whether they're physical, hardware-based, found within the O.S., in the application, or the weakest-link, humans. As pdp said, "These are the types of questions you should ask, not things like: Find me all security issues affecting my business! It won’t work for you no matter which way you look at it." Both theoretical improbabilities and possibilities need to be weighed.
this is where proper consultancy comes into place. you have to think like an attacker in order to identify the weakest links. and you don't secure them by enforcing these links, although you could do that if you want to. you secure them by designing a good plan which outlines what to do when you get compromised. or you even layer the security in a sensible way.
These are good points, and another reason to ensure whomever your security guru is, also has a good background in network administration. VPN's are another device which can be used against you; which is why you should never allow the use of "host-to-host" VPN's. Ensure VPNs always terminate just inside your gateway (but before security devices), and ensure a IDS/IPS is monitoring them. If there is any management of servers allowed via VPN, ensure the IPS/IDS logs are reviewed fully to detect any misuse. I've found mail to be the biggest pain. To be affective, you have to set up your mail sweep systems to flag and hold anything with an attachment; If the attachment meets certain criteria it can go through to the owner; if it meets other criteria it is either deleted or gets placed into a holding area for further review. This adds to cost, and in our case it is worth the damage it saves. However, I can see for most companies, it may not be within their budget. In fact, having a mail sweep program may be outside many budgets, which is unfortunate. -Aodhhan-
It seems you want to attack the problem of security from a logical standpoint first? I guess it comes down to a matter of laziness. As in your stated frustration in blanket solutions for security. Tools are tools. Guns don't kill people, people kill people. Same with anything else. I think you and mrj, parrallel on some things. and, even if you dont think so, its an interesting read. :-) http://www.ranum.com/security/computer_security/editorials/dumb/index.html
Well, for what it's worth, it's only a matter of time & resources. I can't afford proper webhosting, So I use a vitual box because it's what I can afford. Which in terms result in a quicker compromise, because in the end anything can smashed. It is something that I think we must accept, it doesn't involve skills, but mere common sense. In the real world any doorlock can be picked under 2 minutes. 2 minutes is for the strongest lock, most of the time it's 20 to 30 seconds for any common lock. So a better lock buys you time, not security.
This actually would not always work. Many systems have the SSL fronting a series of web servers, and can (DO) put the IDS/IPS inside the web server farm, so you would hit the site unencrypted and visible to the IDS. The SSL (HTTPs) gateway would be just behind the router and the data would travel unencrpyted on the LAN behind that. In order not to fall into that trap, you would have to know that there is not a gateway but a server to server SSL system (which is more rare than you think).
The solution to this problem is pretty simple on an enterprise scale. You force all encrypted mail to encrypt the message to both the recipient and the mail server to allow it to be scanned for malware and or spam. If the mail server is not included in the chain you simply reject the mail with a message telling the sender they need to include the mail server as well. While this solution is less than ideal for extreme privacy concerns it is a quite workable solution for corporate environments where users can/should have no expectation of privacy. In an environment where extreme privacy is a concern, then you must assume the risks of receiving such messages but you could still choose to only accept encrypted messages on a white list basis to separate the messages you want from the messages you don’t.