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
02.22.08
Posted in IT, Operating Systems, Security, Windows at 10:45 am by Tyler Reguly
Today there are a lot of people talking about the release of the Windows Server Protocols and the Windows Communication Protocols. They are series of specs defining various proprietary Microsoft protocols. There are plenty of them and they are rather in depth. These are being released right on the heels of last week's release of the Microsoft Office file format specs. The release of these is, of course, tied to the EU decision that Microsoft has to be more open to interoperability.
Most people, who are talking about the protocol specs so far, are security researchers. This plays a major role in the research game for us. I can remember a few MS Tuesdays that were spent with IDA Pro attached to some listening service, trying to figure out how to generate valid data that would traverse the service to a specific breakpoint. In a lot of ways this will make that research quite a bit easier... and this is what most people are talking about.
While researchers are sitting saying, ‘WOW, this is amazing.' There are a few things that we need to remember:
The improvements we'll see in open source projects. Projects like Samba, mod_ntlm and others will most likely undergo changes to implement portions of the protocols that were never properly understood, or never properly implemented. Someone did point out, however, that developers on some open source projects who enjoyed reversing the protocols may fade away from the projects, bringing in new developers who ‘just want to code'.
Another interesting thing will be the updates to packet analysers and protocol dissectors. I'm sure that we'll see some impressive updates out of Wireshark... but I'm also guessing we'll see the introduction of several small protocol-dependant sniffers. The specs are there, so why not write them?
While security researchers are excited... I'm willing to bet that will stop on the first or second MS Tuesday following this release. Something tells me that this will lead to better fuzzers and more vulnerabilities. This will create a lot of work for those of us in Vulnerability Management, IDS/IPS, etc.
We may also see malware authors looking at various services for new covert channels in which to hide their phone home capabilities... I guess we'll just have to wait and see.
In the end this is really exciting... I will probably spend my entire weekend staring at my new 22" wide-screen monitor reading some of these specs. It'll be interesting to see what the next few months hold.
Does anybody have any thoughts or concerns over these protocols opening up? Any project ideas they are willing to share or propose?
Permalink
Digg this post
02.11.08
Posted in IT, Security at 2:30 am by Tyler Reguly
An article from the NY Times entitled, 'Scanning Your Money to the Bank' recently came to my attention. The gist of the article is as follows: There's an Act (Check Clearing for The 21st Century) that allows for the exchange of electronic images of checks rather than the physical checks... Numerous banks and big business are already doing this, and one bank, which serves the US Military, has also implemented this. A company called Fiserv has recently announced that they have a way to bring this ability to online banking customers. I find this to be very, very frightening...
Someone can submit an image of one of my checks and they will get the money for it? It seems to me like we're making check fraud easier... The company claims that the software will detect if the image has been modified, but I'm guessing it won't be perfect... a lot of digital edits are difficult to detect, especially when done by pros.. and I'm betting even more so when done by pros who stand to make some money.
Let's say that someone has been out mailbox fishing and they've collected a check that I've sent to the utilities company for $250.00. They have an account with the same bank (or have stolen blank checks from the same bank)... They write their name in the Payee field and scan it. They now select a perfect square around the Payee field and cut it, pasting it into the scanned copy of my check. Since the checks are from the same bank, and are (for arguments sake) of the same style... the paste can be done flawlessly... no need to edit signatures, no need to modify names and make the edits look normal... it's nice and easy.
Now what if Pay Day loan companies start using this technology... they are already more lax than your standard bank... what will be allowed to slip through and be cashed now.
Another example... What happens if someone gets one of my checks and I put a stop payment on check #10 (the one I lost)... the criminal, before cashing the check, simply modifies the check number and payment proceeds.
There are definitely some things that should exist online... even related to banking... and email money transfers are a great example of this... but scanning checks... that seems slightly ridiculous to me. What happens if I give someone a check and they scan it over a network printer... or they store the check in a shared folder... or a worm browses their hard drive and uses OCR to recognize check images and forward them on? My check information (which includes my account information, full name, phone number and email address) now falls into the hands of someone who is malicious.
I've always thought that in this day and age, checks were an out-dated and antiquated method of handling monetary transactions... This just makes it worse... and it's not something I'm looking forward to seeing made available to the mass market.
Permalink
Digg this post
02.04.08
Posted in IT, Security, Tools at 4:27 am by Tyler Reguly
The other day I posted the Port Scanner Challenge, and a follow-up article declaring a winner.
This lead to a couple of things...
First, Robert E. Lee (who is associated with UnicornScan) started a blog to perform his own independent tests. I encourage everyone to look at the results... but I remind everyone that Robert is tied to UnicornScan and therefore you may have to take some of the results with a grain of salt.
Second, Fabian, of Recurity Labs (Author's of PortBunny), contacted me regarding the results I had seen, specifically the Vista results. They had reproduced the results in their lab, and ended up releases an update to PortBunny. The updated version showed significant improvements. On the Vista host, with default settings, PortBunny scan times were reduced from ~18.3 seconds to ~1.2 seconds, and on a full port scan (1-65535), scan times were reduced from ~642.5 seconds to ~30 seconds. The updated version of PortBunny can be downloaded here.
Additionally, Fabian included an explanation of how packet retransmission works with PortBunny, which I found rather interesting:
PortBunny sends so called packet-batches which consist of a couple of
probes (usually 9) and a trigger-packet. If a trigger-drop is detected
either because a timeout-clock is hit or due to the fact that 3 later
trigger-responses have been received, all probes which did not get
responses are retransmitted. This is done to acknowledge that, when
firing at this rate, the trigger dropped, so its possible that any other
packet of the batch may have dropped as well.
However, retransmission is not done straight away: That wouldn't be too
wise because the response may just be a couple of milliseconds away.
Instead, we just add the port to the back of the list of ports to scan.
As a result, we can wait the maximum amount of time for the response to
still reach us before we resend.
We only assume that a port is filtered if no response is received for
the probe but the trigger-response for the batch the probe was in was
received.
Now, we do this until all ports have results and then we check whether
the total amount of filtered ports is smaller than 30% of the total
number of ports. If this is so, we perform two rounds of rescanning of
the filtered ports.
Lastly, Fabian also included some of the more interesting changes in this updated version of PortBunny:
(1) The Python-UI contained a Bug which drastically decreased
performance on gigabit-ethernet: To query the device-file, a python
FileObject was used and its read-method was called without specifying a
buffer-size. In fast networks (such as gigabit-ethernet) this lead to
the situation were a huge amount of results was delivered to userspace
in a single read. The information was then parsed using a regular
expression which, due to the size of the buffer, took way longer to
complete than the actual scan 
(2) The development-version now discards bad triggers as soon as better
ones are found. This means that ICMP or UDP-triggers as well as
TCP-SYN-triggers which produce TCP-SYN-ACK responses are discarded as
soon as a single closed port is found (in which case we can use this
port for triggering). This increases performance on the one hand (when
ICMP-traffic is limited which is quite frequently the case for
destination-unreachable messages) and accuracy on the other hand because
triggers are preferred by the scanner which are handled just like the
probes so rate-limitations on TCP-SYNs are detected correctly.
(3) Scans were too "bursty" for many setups which included
burst-limitations. Especially when the round-trip-time was small, the
target would feel like it was processing an (almost) never ending burst
of data. We've made some changes to reduce the "burstiness" as you can
see in the Vista example.
(4) TCP-Reno was taken a little to literally: Reno says that the initial
congestion threshold should be close to infinity so that the sender can
find the limitations of the network quickly (and "muscle" itself into
the connection). NMAP chooses 50 as an initial congestion threshold,
PortBunny chose 80000. While 80000 was closer to infinity than 50, it
doesn't seem like a good choice in many environments when using Reno for
port-scanning because the accuracy of the start-phase of the scan is
reduced drastically. NMAP was totally right to choose a lower number so
we've changed that as well.
(5) We've included a new trigger: The TCP-ACK trigger. This works in
many situations where we had to use fallback-triggers such as the
UDP-trigger in the past.
Permalink
Digg this post
01.14.08
Posted in IT, Reviews, Security, Software, Tools at 11:33 pm by Tyler Reguly
The other day I posted raw data comparing nmap, PortBunny and Unicornscan... I thought today I'd provide some of my thoughts on what the data shows us.
In the end I scanned 5 hosts running a variety of operating systems and I think I gave a fairly decent small scale spread and one initial comment I'd like to make is on the scanning of the HP LaserJet 4MV... While not all scanners found all the ports, they were all able to scan it... which I found fairly impressive... especially considering I've crashed it numerous times in the past playing with advanced options in port scanners and packet creation programs.
Now for the anlysis... Was there a winner? At first I didn't think so... but once I created the graph it became fairly evident that there was. Before I declare the winner... let's take a look at what we saw.
Unicornscan
I was fairly impressed with unicornscan the first time it ran... at least from a speed standpoint. That is until I ran nmap and PortBunny. While unicornscan (on a standard scan, default ports) was able to provide consistent speeds... it was clear that on systems with fewer open ports... there was a huge disadvantage in the design of unicornscan... The consistent speeds were still occurring. If we look at my shell box for example (Ubuntu 6.06 PPC on an old 350Mhz iMac), we see that unicornscan took what appears to be a respectable 9.2 seconds. However, nmap took only 1.5 seconds and PortBunny was less than a second at 0.7 seconds.
The full port scan also didn't bode well for unicornscan. On two hosts, the printer and the gateway, it failed to find any open ports... These are both slower systems (the older printer, and a soekris 486 for the gateway) so perhaps they couldn't keep up with the speed of the scan... or perhaps unicornscan was scanning too fast even for itself.
In the end, after seeing the results of nmap and PortBunny I was rather unimpressed with unicornscan.
nmap
I was quite impressed with nmap. During the default scan it tied PortBunny with lowest number of missed ports (of course this is due primarily to the various scanners default port list) and on a full port scan, it was the only scanner to find all open ports. In addition to having the lowest miss port rate... it boasted the fastest times... coming in 17.5 minutes faster than PortBunny on a full port scan, and 16 seconds faster on a default scan.
Additionally when I provided nmap with the '-T5 --max-retries 0' options, it blew PortBunny out of the water... it missed two additional ports over PortBunny on one of the 5 hosts, however the time difference was 5.3 seconds to 74 seconds... nmap was 68.7 seconds faster.
PortBunny
Given all the hype surrounding PortBunny and the fast that is is a "Linux Kernel-Based Port Scanner" (which is supposed to work to it's benefit), I was expecting great things... instead I was seriously disappointed. There wasn't a single scan where PortBunny fully out performed nmap... You have to set nmap to get ridiculous scan speed (scanning "almost too fast") in order for PortBunny to even manage to find more ports than nmap and then it takes ~15 times longer to find those 2 extra ports... Without those "almost too fast" options, nmap still performs faster than PortBunny and with more accuracy.
There was one host where PortBunny was able to outperform nmap, however that was with nmap doing a default scan... when timing options were adjusted, once again PortBunny failed to beat nmap.
Decision
When I started this challenge, I wasn't sure what the outcome would be... the only prediction I had was that unicornscan would be defeated by both PortBunny and nmap. This proved to be true... Between nmap and PortBunny, due to the hype around PortBunny and the claims that I had seen... I really wasn't sure. I expected it to be a close battle between the two... at most a TKO... but in the end it was a straight-up KO and in reality PortBunny was never really a contender.
Winner: nmap
Permalink
Digg this post
01.13.08
Posted in IT, Reviews, Security, Software, Tools at 11:33 pm by Tyler Reguly
There's been quite a bit of mention lately of PortBunny, the new port scanner from Recurity Labs. The scanner is Linux kernel-based and provides a TCP SYN Scan. I figured that I'd put the scanner to the test against nmap and Unicornscan.
Here's the rundown of the setup used:
Software + Version:
Scanning Host:
OS: Ubuntu 7.10
Kernel: 2.6.22-14-generic
Processor: Intel Pentium M 2.13Ghz
RAM: 1GB
Install Process:
- Obtain archive
- Extract archive
- ./configure *No custom config options used for any of the software*
- make
- make install
Tested via Python:
Test Script (Note: I can't get my lines to tab properly, so tab over the four lines following def test):
import time, os
def test ( prog ) :
startTime = time.time()
os.system( prog )
endTime = time.time()
print ( 'Execution Time: %f' % ( endTime - startTime ) )
Targets:
- vista - Vista Home Premium
- shell - Ubuntu 6.06.1 LTS (2.6.15-28-powerpc)
- minibox - OS X 10.4.11
- printer - HP LaserJet 4MV
- gateway - m0n0wall 1.231
Scan Notes:
- PortBunny requires an IP Address, it won't run against hostnames.
- PortBunny doesn't sort the results list.
- Unicornscan missed all ports on printer and gateway when scanning ports 1 - 65535.
- PortBunny missed a port on printer when scanning ports 1 - 65535.
- nmap missed 2 ports on printer when scanning with -T5 --max-retries 0.
Results:
Raw Data, including ports found, after the jump.
Read the rest of this entry »
Permalink
Digg this post
01.10.08
Posted in IT, Security, Vulnerabilities at 12:51 pm by Tyler Reguly
By now many people will have seen this, it appeared on Slashdot and Halvar posted it to his blog, but for those that haven't... this is a pretty cool flash to watch. MS08-001 Disassembly.
Permalink
Digg this post
Posted in IT, Security, Tools at 12:40 pm by Tyler Reguly
This is actually pretty cool... It's a new tool (Web-based) that came across the Web Application Security Consortium mailing list. Let's take a look at the tool in action first, example with ComputerDefense.org.
Showing records 1 - 13 out of 13 for www.computerdefense.org (82.165.158.149).
| capri-beauty.com |
computerdefense.org |
| hometownssm.com |
hometowntoronto.com |
| htregz.com |
korahgrads.com |
| numerophobe.com |
pythongod.com |
| reguly.org |
securitybloggers.net |
| spammailbag.com |
themoviegeeks.net |
| topsykrett.com |
Those are indeed the domains I own, that reside on the same IP as ComputerDefense.org. Currently the database is restricted to .com, .net and .org but it's still fairly impressive. A method of determining vhosts is a great asset to penetration testers and security researchers.
The tool is available from a group called CRUSH. It requires that you validate you aren't a bot via a text / colour based CAPTCHA, however after the first time, you are good to make subsequent requests.
I'm going to have fun playing with this tool, taking a look at certain companies / websites and seeing what other domains they host on the same server...
Permalink
Digg this post
01.07.08
Posted in IT, Security at 12:25 am by Tyler Reguly
First off... I wasn't dead... I took some holidays around Christmas and went up north to visit the family... Two weeks and I spent less than an hour in total touching a computer... it was great.
Anyways, I'm back and I looked at my bloglines, well over 2000 articles to read... I skimmed a few but basically just ignored them all (in IT/IS news really does change that quickly)...
One blog post that did catch my attention was Kurt Wismer's post over at Anti-Virus Rants.
Background: In 2005, two eEye researchers presented BootRoot, a PoC boot sector-based NDIS backdoor. Much of this PoC code is now being seen in an 'in-the-wild' attack.
So Kurt dislikes the fact that the eEye team released a PoC... apparently it is irresponsible and fundamentally wrong. I have to say I fully disagree with Kurt. The PoC has been modified, which means the individual knew what they were doing to some extent and simply reused code... on top of this, the research was published over 2 years ago... in 2 years, someone should have been able to develop a defense against this... instead people chose to ignore it.
I have to ask you this Kurt... How do you feel about the following:
All of the above either release proof of concepts, or discuss them... Are you against all of these as well? Should we boycott OWASP because they have PoC demo's of various web-based attacks? Should we ignore the legit uses of Metasploit because of the malicious users?
Take a look at the talks given at BlackHat 2005. A large number of them contain information that, at the time, could give attackers the upper hand... So why pick on eEye, two years after the fact... just because someone decided to reuse some code from their Poc?
Permalink
Digg this post
12.10.07
Posted in IT, Interesting Stuff, News, Security at 11:51 am by Tyler Reguly
In a previous post, I had reviewed a SecTor presentation done by Johnny Long. I had also mentioned on Hackers for Charity, a charity started by Johnny to link up hackers with charities that require IT/IS assistance. I see this as an incredible contribution and was looking forward to getting involved myself, but at the same time I was receiving feedback from readers who were interested based on the brief mention I had made of it. I decided the best way to follow up was to contact Johnny for a brief interview. I sent him a few questions, in hopes of getting a bit more information out to everyone that reads it, and I've basically inserted the email responses below.
Who is Johnny Long? While most that read this will know who you are, there may be a few that don't...
I'm a hacker by trade, a pirate by blood, a ninja in training, a
family guy and author.
How did you first get involved with charity organizations and what drew you to the IT side of their operations?
My wife went on a mission trip to Uganda last year, and I joined her
in her research about what was going on in Uganda. This led me to
Invisible Children. I mentioned them in my talks, raised some support,
etc but when my wife returned from Uganda, I felt drawn to do more
than raise money. This past may, she returned to Uganda and I went
with her. Several corporations and the hacker community chipped in to
fund our trip. We worked with an organization called AOET (aoet.org)
who is working to help orphans left in the wake of the HIV/AIDS
pandemic.
What is Hackers for Charity?
We exist to connect the skills of the hacking community with charities
that need those skills. We aim to empower charities through the use of
information technology.
At SecTor you had mentioned that it was for 'unemployed hackers', is this true... Does an employment restriction exist?
Not at all. But generally we tend to attract those looking for work.
We have some senior members that are very well-set career-wise, and
those folks are looking for a positive outlet for their skills. We
provide that.
Could you provide an explanation / description of how the "references for work completed" 'thank-you/reward' system works.
It's pretty simple. Successful completion of a project results in a
LinkedIn connection and resume reference from myself and other
professionals that can vouch for the work. The professionals are
well-known in the industry, and their recommendations carry real weigh
to potential employers. Those that are already gainfully employed
receive the same benefits, but can add our organization and the
charity name to their list of professional accomplishments. We're also
working on a link/referral system that provides exposure for companies
that donate time or money.
How successful has Hackers for Charity been so far?
We have a mailing list of 80+ members. We've successfully completed
three projects: a reusable mail system, a reusable blogging system,
and our largest project-- an online child sponsorship system for AOET.
The child sponsorship system is amazing. It was developed by Paul
Madoff in the span of about two weeks, and will literally save the
lives of children in sub-Saharan Africa. Designed for AOET, this
system replaces their old cumbersome system with a streamlined system
that allows potential child sponsors to browse a gallery of children
in need, and select one for sponsorship. The old system was so
cumbersome that many potential sponsors got lost in the process and
often went to more popular and more technically advanced child
sponsorship programs. It could be argued that sponsoring a needy child
anywhere is better than not helping at all, it's heartbreaking to see
the AOET sponsorship system crippled because of technology issues.
This system addresses that, and once it passes a vetting process, it
will be released for public use through the AOET.org web site. Last
but not least, we've raised over $2000 for AOET, most of which went to
supporting their work in Kenya.
Hackers for Charity currently uses a Google Groups mailing list (which is becoming more common) which requires a Google email address. Have you considered moving away from that to a standard mailman list to allow for more accessibility? (Note: This question was asked due to comments received when I had previously mentioned Hackers for Charity)
Uhm, yes.
Hackers for Charity is still young... are there any planned next steps?
We plan on growing. =) Honestly, this thing has taken off so fast that
it's difficult for me to keep my head above water. We won't be able to
do much without some sort of (corporate?) sponsorship that will help
pay the overhead associated with running the organization. There are
only so many hours in the day, and I'd like to devote more of them to
the organization.
Has there been any thought to Hackers for Charity stepping towards a Doctors Without Borders type approach. Where in additional for volunteering to help a charity from the comfort of your own home... volunteers could be sent to third world countries or disaster areas to help implement or rebuild an IT
infrastructure?
Absolutely. I can't go into too much detail right now, but we're in
the planning stages of making that happen next year (2008).
Any words, advice or thoughts for people who have been thinking about volunteering but haven't taken any action yet... for either procrastinators or people who they might not be the type of person (or have the type of skill set) that Hackers for Charity is looking for?
Forget your skills. Come with an eagerness to help those less
fortunate. Heck, just come if you could care less for all that
altruistic crap and are just looking for a bump up on your resume.
Some of the most needed skills are those you may think are useless.
Soft skills, such as business, marketing, management, accounting, etc
are all needed.
Permalink
Digg this post
« Previous entries · Next entries »