Last Updated: 2006-08-16 16:21:09 UTC
by Kyle Haugsness (Version: 2)
Of course, Litchfield has found lots of vulnerabilities and reported them to IBM in January 2005 and now patches are released in August 2006.
Please note that I'm not trying to make a political statement about IBM. There are plenty of other vendors with similar types of problems still lurking about. Instead, I am merely highlighting the research of Litchfield and posing some thoughts for our readers. I will do my best to leave my opinion unstated, so that you can draw your own conclusions.
Here is what I find interesting about the vulnerabilities that Litchfield found:
1) There is a basic stack overflow in the username parameter when you authenticate to the database. You can't get any more easy than this. The bug exists on all versions of Informix on all operating systems. This reminds me that "Smashing the Stack for Fun And Profit" by Aleph1 is almost 10 years old now.
2) An attacker doesn't need to authenticate to determine the remote operating system. The installation path is given in the error message for an authentication failure. This is very useful for exploiting #1.
3) After authentication, there are numerous buffer overflows available that allow for code execution and privilege escalation. These are vanilla buffer overflow scenarios that are easy to exploit.
4) In the event of a crash, Informix will dump username and password information to files that are world readable in /tmp. This makes it convenient for an unprivileged bad guy with local access to get usernames and password for admin or privileged users.
5) Any authenticated user has the ability to create a new database, which gives that user DBA privileges on the database. So once you do this, you own the whole server. This is a major architectural flaw.
6) Normal users can run arbitrary OS commands using the SYSTEM SQL command. There are numerous paths to get commands and user-specified DLLs executed as the privileged Informix account.
7) Finally, there are stack overflows still available in environment variables used by SUID command-line binaries.
Here is a link to the research paper by Litchfield: http://www.databasesecurity.com/informix/DatabaseHackersHandbook-AttackingInformix.pdf
So given the facts above, are you asking the right questions of your vendors? How certain are you that your favorite software vendor is writing secure code? Do you have the ability to change software packages if you find that a product has been found to have basic programming errors? And can your organization afford to let known holes live unpatched for 1.5 years?
Last Updated: 2006-08-15 20:06:26 UTC
by Kyle Haugsness (Version: 1)
Last Updated: 2006-08-15 19:13:33 UTC
by Swa Frantzen (Version: 2)
In some organizations the system or network administrators are the ones who are in the best position to keep them up to date and working properly, sometimes making it hard to coordinate with a different set of security people.
What should be in such a logbook ?
Hardware and configuration
IdentificationYou need to be able to identify a device should it get lost, stolen or otherwise compromised. I've found it useful for administrators who are less familiar with certain devices to still locate the right device and be able to power toggle a completely unresponsive system back to life. This information can be of great value and is easy to obtain during physical installation and initial staging.
- Options: CPUs, memory, disks ...
- Serial numbers
- Host ID
Network(s)Information on the network connections.
- Connects to: device, port
- MAC address
- IP addresses (use CIDR, network and broadcasts written out, remember you'll use it in an emergency!)
- FQDN (DNS name)
FilteringFiltering used by this device such as packet filters, their configuration, how to turn them on and off and how to get a closed emergency filter installed.
Disk(s)Detailed information on disks, partitions and slices. Make sure to add what they are used for and the information needed to select the right replacement drive.
The easiest is to print out the information from the OS. E.g.:
$ sudo fdisk wd0
Disk: wd0 geometry: 24321/255/63 [390716865 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
*3: A6 0 1 1 - 24320 254 63 [ 63: 390716802 ] OpenBSD
$ sudo disklabel wd0a
disk: ESDI/IDE disk
label: WDC WD2000JD-00G
total sectors: 390721968
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
# size offset fstype [fsize bsize cpg]
a: 4194225 63 4.2BSD 2048 16384 328 # (Cyl. 0*- 4160)
b: 1048320 4194288 swap # (Cyl. 4161 - 5200)
c: 390721968 0 unused 0 0 # (Cyl. 0 - 387620)
d: 4194288 5242608 4.2BSD 2048 16384 328 # (Cyl. 5201 - 9361)
e: 4194288 9436896 4.2BSD 2048 16384 328 # (Cyl. 9362 - 13522)
f: 377085681 13631184 4.2BSD 2048 16384 328 # (Cyl. 13523 - 387615*)
/dev/wd0a on / type ffs (local)
/dev/wd0e on /home type ffs (local, nodev, nosuid)
/dev/wd0d on /var type ffs (local, nodev, nosuid)
/dev/wd0f on /var/www type ffs (local, nodev, nosuid)
RAIDMake sure you have all the information to deal with raid devices you might have. As most often this is proprietary in format, giving guidance is hard. But make sure you have all information needed to replace drives, use hotspares, rebuild partity and reconfigure them in the same way as they were should the configuration information get lost.
Operating SystemThis information changes with reinstallation but stays as a while fairly static
- Revision (if any)
- Installation time choices indicating installed components.
OS patchesThis information changes a lot in modern OSes. An informational paragraph on how the patches are applied now and how they are done normally should suffice. Having a log of what was installed when is important.
ApplicationsThis section is what you installed as applications on the machine. It should include the important choices made during installation so that people coming after the installer could redo the installation in the same manner. This section must be expanded as time goes by and more applications are installed or removed.
If activation keys are used they should be copied here as well or at least clearly indicated how they can be obtained in an emergency.
Service contractsInformation on all hardware and software or other service contracts related to this machine. It should include the needed procedures, contract numbers , FAX and phone numbers, and any reference the other party will demand before they will start their service execution.
DependenciesA tricky part in larger organization to get right and it might make use of automation if you have many. Basically you want to show:
Services offeredServices the device offers. It should list what needs to be in place, how to test that the services are working, and a list of machines and/or other services depending on them. A prediction of what happens when the services are lost can be very valuable information when dealing with incidents and their needed communication.
Services usedDevices typically need a bunch of services of other machines. Having such a list with simple test to see if those services perform their intended task can be a great timesaver.
IncidentsAny incident this machine was involved in, should be documented in detail. Even simple hardware failures should be documented as they can lead to discover a trend that could indicate a problematic device and trigger a need for replacement.
- what was observed
- what was done
ProceduresProcedures can be either detailed procedures or pointers to specifics. Remember you'll need them under stressy conditions, so make them easy to find and execute. Make sure they list when and by whom they were last actually tested.
Emergency accessHow does an authorized person not having or remembering the passwords access the system in an emergency (e.g a sealed envelope in a safe).
Check Backup statusHow do you see what backups have been made, what they contain etc.
Normal backup out of sequenceHow do you make a backup use normal means for backing up ?
Emergency backupHow do you make a backup in an emergency ?
Restore of dataHow do you restore a single file or directory ?
Restore of full systemHow do you restore a full system ?
Raid proceduresAs needed.
...Add other emergency procedures that are usuful for the specific devices such as how to deny all traffic for a firewall. Also in the text above the procedures there are some links that say to document procedures, those coul dbe added here or pointed to at least.
How do you store this information ? I've used various document formats, but if I were today to start with this again I'd seriously consider an internal wiki.
Things to look out for:
- Make sure it is easy to access and update by all your administrators.
- Make sure you have a copy ready in your Disaster Recovery site, you'll put it to good use inthe process of a recovery should you ever need to start it.
- Make sure it is easy enough to add additional information the administrator thinks might be good to know. So allow for a flexible format to store it in. Allowing for some flexinbility allows you to use this kind of logbook for devices you might not consider to be "computers" such as network elements, or even devices such as accurate clocks, environmental controls etc. (even if they aren't networked).
- You can link this in with change management. In fact you should ...
- While updatign remember that you are documenting it for a slightly less experienced administrator than yourself who knows the hardware/software a little bit but does not know the specifics of this machine.
- It's meant to be used during emergencies, keep it simple to read and understand.
For additional inspiration refer to Security Consensus Operational Readiness Evaluation, there are check lists and incident forms available there.
Swa Frantzen -- Section 66
Please choose a specific diary above to comment