Shaken-Not-Stirred Technology Mixed Right!

Over the last few years I have gone through making several web servers pass
PCI security scans. It seems that each company that provides the
service has a different take on what passes and what fails. It also
seems that they count on their automated scans doing the right thing,
but it would seem by looking at the output of their scans that who ever
wrote the scans has little or no systems administration knowledge and
the programmer in question was probably a very junior person.

The last server I had to "make secure" had gems such as this in the
report:

THREAT REFERENCE

Summary:
Apache vulnerabilities on Apple HFS+ filesystem

Risk: High (3)
Port: 80/tcp
Protocol: tcp
Threat ID: web_server_apache_machfs

Details: CVE 2004-1083
Two Apache vulnerabilities arise from the Apple HFS+
filesystem. Firstly, the HFS+ filesystem is case-insensitive,
while Apache file access restrictions are case-sensitive.
This allows an attacker to gain unauthorized access to
.htpasswd or .DS_Store files
by changing upper-case letters to lower-case or vice-versa
in an HTTP request. These files could contain encrypted
passwords or other sensitive information.

CVE 2004-1084
The second vulnerability arises because the HFS+ filesystem
allows access to the data stream associated with a file
using a special file name. A remote attacker is able to
access this special file name in an HTTP request, thus
gaining direct access to file data or resource fork content
without going through the normal Apache file handler.

CVE 2004-1082
The fix for these vulnerabilities also fixes a replay problem
in mod_digest_apple due to insufficient
verification of the nonce of a client response.

Information From Target:
Service: http
Sent:
GET /blog/.HTPASSWD HTTP/1.0
Host: www.example.com
User-Agent: Mozilla/4.0
Connection: Keep-alive
Cookie: CUSTOMER_INFO=deleted; frontend=deleted; CUSTOMER_AUTH=deleted;
CUSTOMER=deleted


Received:
HTTP/1.1 200 OK


The server in question is running FreeBSD-9, not Mac OSX. It seems they tried to
grab .HTPASSWD and decided the server must suffer from the case
insensitive HFS file system and is not properly protecting .HTPASSWD.
Did they do a simple content check to see if they really got back an
htpasswd file? No they did not. They based their failure of the site
on getting back an HTTP/1.1 200 OK response. Now for the site in
question if you hit any non-existing page you are directed to the site's
search page and the eventual code you get is 200. It really is not that
hard to check if the file fetched matches the format for .htpasswd, but
instead of making a good test they make poor web retailers spend
hundreds to thousands of dollars on systems staff or consultants time to
"prove the server does not have a problem".

It sure seems like a racket to me. I think the best way to put these
sharks out of business and make way for real and reliable PCI scanner is
to write a FreeSoftware PCI scanner. I bet we could start with nmap and
link in some calls using wget or lynx along with some small use of
netcat or telnet to produce a WORKING PCI scanner.

I do not have the time to do such a thing myself, but I can offer
hosting for the project. If anyone wants to pick up the banner and run
with it count me in on a supporting basis.

Stupid Security Camera Trick

A few years ago I purchased 2 IP cameras from TigerDirect. They were Trendnet TV-IP 110 security cameras. Before I purchased them I determined by speaking to a Trendnet representative that the cameras ran GNU/Linux. This would be good if I needed to do some custom work on them. I was also told that all features of the camera would work using any browser on any computer. Well, I was upset when I got the camera and discovered that MS-Windows and Active-X were required to access all the features of the camera. I was even more upset to discover that there was no ssh or ssl on the camera. A phone call to the Trendnet tech support about the total lack of security was met with the response that it had to be secure because there was a password. It seemed that the fools at Trendnet never heard of snooping the wire to get plain text credentials. I further poked at the camera and found the flaw recently reported by the Console Cowboys. I made another call to Trendnet again requesting the source code and offering to work with their people to fix the issues. Not only did they refuse the source code request, but they also still refused to see the GLARING OBVIOUS security flaws in their product.

I put the cameras away since TigerDirect would not accept a return on them. This past week I pulled them out with the thought of putting them to use somehow. I discovered that Trendnet has at last posted the code, so there is some hope that if I put up a cross compile environment I just may be able to fix the issues.

Unfortunately the most recent firmware update (Feb of 2012) from Trendnet still has all the security flaws of no SSL or SSH and the ability to BYPASS the BASIC AUTH.

I just checked several other IP cameras from other makers to find that they too do not seem to have any idea about system or network security either. What is worse is some of them seem to also be GNU/Linux based, but do not seem to supply source code.

While Trendnet does supply source code they seem to mix up all the sources for all their cameras into one zip file. They seem to be just following the letter of the GPL, and not the spirit of the GPL. They provide no guidance as to what needs to be compiled for what camera and also do not provide any information on how to set up the the binary firmware package.



Why in this day and age are the above issues still common? I strongly believe it is because those of us in the know just accept that this is the way of things. We do not make enough noise about security flaws such as poorly designed hardware/software systems and most so-called security cameras. For years vendors have been supplying routers, cameras, and other devices with only http or telnet access. Many vendors I have spoken too have used the excuse that including ssh or ssl on the administrative interface would take too much memory of disk space. We all know that neither statement is true.

Time for change:

It is time for a change. The only way this change can happen is if we refuse to accept such poor excuses for products as are currently on the market. We need to tell our friends and family about the security flaws and encourage them to vote with their pocket books. We, as knowledgable professionals, need to put pressure on vendors to supply products that are not 20+ years out of date in their security layers. When you see a poor product make noise. First contact the maker and tell them. If
they will not fix the problem then post the flaw everywhere you can. Let everyone know about the problems. If we, the geek elite, do nothing there is no telling what harm will come from poorly engineered products. It might also be time for a class action lawsuit against a vendor or two for using known flawed security practices in their products.

For all you FreeBSD lovers who have been upset that you could not get your favorite OS on Amazon EC2 now is the time to rejoice! As of the FreeBSD 9.0 release there are public AMI files for FreeBSD 9.0 that just work when booted in a standard EC2 host. You will find one thing somewhat unpleasing about the experience though......the icon next to the working FreeBSD images is an MS-Windows icon. This is an artifact of the way the author of the AMI had to prepare the image. He started with an Amazon MS-Windows image, tossed the MS-Windows content out and replaced it with FreeBSD 9.

FreeBSD in the Amazon Cloud has been a long time coming. Some of the reasons that have held it back were bugs in AWS and a small bug in the FreeBSD Xen support. These seem to have all been fixed as reported at http://www.daemonology.net/blog/2011-07-08-FreeBSD-on-EC2-via-defenestration.html.

Since Amazon is offering free micro images I decided to try the new image out. I went through the standard EC2 micro image setup and picked the FreeBSD 9 Release image (with the ms-windows icon) and booted an instance. A short time later I was logged in as root via ssh using pub/private keys. Well this was too good to be true, so I decided to do what I would on any brand new virgin minimal install system.

# portsnap fetch
...............output redacted for size..........
# portsnap extract
# cd /usr/ports/shells/bash
# make install && make distclean

Well everything worked as expected and in no time I had bash installed. I usually do a make package, and rarely do a dist clean so I can deinstall and reinstall with ease, but the limited size of the Free EC2 disk image made me decide to dump the distfiles and dispense with keeping a package around to clutter things up.

Since this went so well I decided to install a few other tools and toys. The build and install of screen, sudo, and ezjail all were fast non-events.

Since I installed ezjail I had to try it out......So a couple of short ezjail commands latter I had a working jail called demo100 on 127.0.0.100.

[root@ip-10-28-90-182 ~]# uname -a
FreeBSD ip-10-28-90-182 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Mon Jan 16 18:25:55 UTC 2012 root@ip-10-17-42-118:/usr/obj/i386.i386/usr/src/sys/XENHVM i386
[root@ip-10-28-90-182 ~]# jls
JID IP Address Hostname Path
1 127.0.0.100 demo100 /usr/jails/demo100
[root@ip-10-28-90-182 ~]# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0a 9.7G 2.5G 6.4G 28% /
devfs 1.0k 1.0k 0B 100% /dev
/usr/jails/basejail 9.7G 2.5G 6.4G 28% /usr/jails/demo100/basejail
devfs 1.0k 1.0k 0B 100% /usr/jails/demo100/dev
fdescfs 1.0k 1.0k 0B 100% /usr/jails/demo100/dev/fd
procfs 4.0k 4.0k 0B 100% /usr/jails/demo100/proc
[root@ip-10-28-90-182 ~]# ezjail-admin console demo100
Last login: Wed Jan 25 05:56:51 on pts/1
FreeBSD 9.0-RELEASE (XENHVM) #0: Mon Jan 16 18:25:55 UTC 2012

Welcome to FreeBSD!

Before seeking technical support, please use the following resources:

o Security advisories and updated errata information for all releases are
at http://www.FreeBSD.org/releases/ - always consult the ERRATA section
for your release first as it's updated frequently.

o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and,
along with the mailing lists, can be searched by going to
http://www.FreeBSD.org/search/. If the doc package has been installed
(or fetched via pkg_add -r lang-freebsd-doc, where lang is the
2-letter language code, e.g. en), they are also available formatted
in /usr/local/share/doc/freebsd.

If you still have a question or problem, please take the output of
`uname -a', along with any relevant error messages, and email it
as a question to the questions@FreeBSD.org mailing list. If you are
unfamiliar with FreeBSD's directory layout, please refer to the hier(7)
manual page. If you are not familiar with manual pages, type `man man'.

Edit /etc/motd to change this login announcement.

demo100# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0a 9.7G 2.5G 6.4G 28% /
demo100#


I do not know about you, but I can see lots of interesting things one could do running jails on an AWS EC2 instance.

I am about to suggest something clever as a solution to a client's problem. If the client goes for the proposal and I make it work I will be sure to tell you all about it!

Welcome to the first installment of Shaken-Not-Stirred. My friend Matt Simmons poked me a bit to take the plunge and start writing the blog. I can not promise any sort of schedule for postings, but I can promise that the postings will make you think and if you are not careful might even pass on useful information.

I have been involved in technology since the 1970's, when as a high school kid I was repairing 2 way radio equipment for the state police. My first shot at computers was at university with the Dartmouth Time Sharing System in 1977. My first programing language was of course Dartmouth Basic, quickly followed by Fortran and PL1. My introduction to Unix came in the form of a discussion of this hot new system with Eric Raymond when we were on a fall camping trip in the Catskill Mountains in about 1979 or 1980. I got my hands on the TRS-80 Model 1, the Sinclair ZX-80 and the Radio Shack Color Computer as a ghost reviewer for a buddy that had way too much review work to do on his own in the early 1980's. My first Unix admin job was running an AT&T telephone PBX that ran using tape as random access storage instead of the then very expensive disks.

Yes I have seen my share of history in the world of computing and high technology. I have seen the good, bad, and ugly. I hope to help you avoid the bad and ugly, but those that do not learn from history are destined to relive it!

-Brett Wynkoop