Incident Handling: Home Heating 101

Published: 2005-10-29
Last Updated: 2005-10-29 20:46:16 UTC
by David Goldsmith (Version: 1)
0 comment(s)
Every winter we get suggestions, warnings, etc to have our furnaces checked out before the cold seasion to make sure they are safe to use, to ensure that they won't burn our house down while trying to heat it.  I have central AC/heat at home so the same air handler is used year round.  When its hot, the outside compressor cools the air and when its cold, the gas furnace heats the air.  The air handler has been working fine without problems until this incident.

Several days ago it finally got cold enough in Virginia to require using the furnace to heat the house so we flipped the switch on the thermostat from Cool to Heat.  The furnace worked fine and we had whole-house heat for a couple of days.  Two days ago I came home and the house was cold.  I checked the circuit breaker in the electric panel and it wasn't tripped.  I checked the light in the utility room (same circuit as the furnace) and it wouldn't come on.  Changed the light bulb -- no joy.  Flipped the circuit breaker off and back on -- no joy.  I went back upstairs to think of other ideas to try before calling an HVAC contractor when all of a sudden, a few minutes later the furnace turned on and started working just fine.

The furnace ran that evening and into the night but sometime early in the morning, it stopped working again.  I called an electrician and got someone to come out a take a look at it that afternoon.  He started with the furnace.  It seemed ok.  Tested the new light bulb -- it was good.  Tested the light socket and was suprised to get a voltage reading on the neutral wire.

So he went to the main electric panel for the house, removed the panel cover to expose the wiring connections to the circuit breakers and nuetral bars and found quite a suprise.  Instead of one neutral wire for each circuit being secured by one lockdown screw on the neutral bar, there were a number of instances of two or three wires under one screw.  In the case of the furnace circuit, there were four wires under one screw.  The screws were loose so the wires had been intermittently shorting and sparking.  Had lots of nice black soot from the arcing in there.  He was really "shocked" at the condition of the wiring in there -- no way it could have passed an inspection as it was.  He rewired the box correctly and the furnace works fine now.

So in this incident, it appeared that the problem was with the furnace since the air handler had been working fine for months cooling air and just shortly after starting to use the furnace for heat was when we had problems.  But it turned out to be an external component (the electrical circuit) that the furnace depended on.

How does this relate to information security?  Well, similar incidents can occur.  If we get alerted that a system on our network has been compromised, the first place our attention is usually directed is to the  compromised system and then perhaps the firewall to ensure to we are only allowing the appropriate access.  We may need to look elsewhere on our network to find the cause of the problem or the access vector that open.  Perhaps someone has added a wireless access point or has a dialin modem attached to a workstation.  Oftentimes we need to look beyond the immediate likely cause to look for the actual cause.

Have a safe weekend and Happy Halloween Monday night.  It looks like its supposed to be dry and cold here so I'm glad my furnace works now.

Dave Goldsmith
Keywords:
0 comment(s)

Botnet Malware code modifier's competition continues

Published: 2005-10-29
Last Updated: 2005-10-29 12:19:13 UTC
by Patrick Nolan (Version: 1)
0 comment(s)
Trend Micro's analysis of WORM_MYTOB.KV and WORM_FANBOT.H mention some strings in the HOSTS file indicative of the ever ongoing competition between the botnet malware "modifiers", including the strings;
 "HellBot3 have BackDoor in 'HellMsn.h'. The HellBot3 author is an idiot!!!
Play with The best, Die like the rest."
Sheesh, upon reflection, the strings above make me miss Gobbles, whose flames rank right up there as all-time classics.

Keywords:
0 comment(s)

Defeating A/V by inserting forged data

Published: 2005-10-29
Last Updated: 2005-10-29 11:20:32 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
Andrey Bayora (GCIH, dontja know) has released an advisory regarding an insertion-style attack to slide certain malicious content past many antivirus products. http://www.securityelf.org/magicbyteadv.html and the accompanying white paper http://www.securityelf.org/magicbyte.html describe fooling text-parsing routines by prepending executeable-looking file headers. The additional data is ignored by the victim's system, while the A/V sees it and stops evaluating the file before encountering the malicious script, code, etc. Andrey has let us know he has been contacted by some vendors, and that he is aware that Trend has issued a letter to their customers on this issue.
Keywords:
0 comment(s)

Ethereal Advisory

Published: 2005-10-29
Last Updated: 2005-10-29 02:28:22 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
In case you missed it last week, Idefense released an advisory regarding Ethereal, the very popular open source protocol analyzer. Several buffer overflow and DOS vulnerabilites are corrected with the latest release version - 0.10.13.

From http://www.ethereal.com/appnotes/enpa-sa-00021.html:
"It may be possible to make Ethereal crash, use up available memory, or run arbitrary code by injecting a purposefully malformed packet onto the wire or by convincing someone to read a malformed packet trace file."

The IDefense advisory is at: www.idefense.com/application/poi/display?id=323&type=vulnerabilities

There is exploit code for at least one of the BOF vulns. Now, who uses Ethereal, anyway? Net admins, incident handlers, auditors, analysts....nothing important to worry about on their systems, eh?

A great way to avoid getting bitten badly by these protocol parser attacks is to not run them as a super user, if you don't have to. Do your packet capturing with something dumb (like tethereal or tcpdump with the -w switch), then analyze as a non-priv user. This way an attacker is limited in the damage that can be done, should they slide the evil bits into your sniffer.

Keywords:
0 comment(s)

Escaping the P2P-induced alert onslaught

Published: 2005-10-29
Last Updated: 2005-10-29 02:25:47 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
Eric Hughes was plagued with what, at first, loked like a DOS on his system. As it turns out, he was the lucky renter of an IP address that a busy P2P net believed was a willing participant. After being pounded for days and his firewall logs busting at the seams, he opted for a new DHCP-assigned IP address. Unfortunately, many ISPs aren't terribly responsive to such requests, so he took matters into his own hands & changed his MAC address. Release & renew and bingo...no more nasty UDP trash-o-grams filling his logs.
.

Keywords:
0 comment(s)

Comments


Diary Archives