AOH :: ISN-1106.HTM

Re: Hacker logs onto FWP hunter database, but no information




Re: Hacker logs onto FWP hunter database, but no information
Re: Hacker logs onto FWP hunter database, but no information



Forwarded from: Harlan Carvey  
Cc: ngevock@dailychronicle.com, isn@c4i.org 

Wow, yet another example of how the popular media just
gets it so wrong...and I'm not even going to go near
the use of the term "hacker" issue...


http://www.bozemandailychronicle.com/articles/2005/06/29/news/02fwp.txt 
> : 
> : By NICK GEVOCK
> : Chronicle Staff Writer 
> : June 29, 2005
> : 
> : A hacker broke into a Montana Department of Fish, Wildlife and 
> : Parks computer database containing personal information about 
> : hunters last month, but officials say no data was stolen.
> 
> : The database includes personal information about hunters, 
> : including Social Security numbers, along with data on where
> : they hunted and whether they killed game.
> : 
> : Upon discovering the hacking, FWP immediately contacted Sam Mason, 
> : a state data security specialist, who determined the hacker hadn't 
> : downloaded any information, Aasheim said.
> 
> : Based on a review of the database after the incident, it appears 
> : that the hacker was looking for storage space for files, Mason said.
> 
> Because all of the system logs clearly show this? And the logs were
> not altered?

Were they altered?  And were the logs that were examined the _right_
logs?  And was the necessary level of auditing enabled to detect this?

If you're not auditing for successful logins to a system (only
failures), then you don't have anything in the logs that will tell you
if someone actually, successfully logged in.

> : Luckily, Aasheim said, the agency's databases use Oracle software, 
> : which compresses inforamtion into a code that is not visible to 
> : hackers as readable text.
> 
> "Not visible to hackers" is quite amusing, given the nature of
> hacking and how many hackers are responsible for reversing just
> about everything, including encryption/obfuscation schemes. And
> heaven forbid the hacker know Oracle commands, because I think
> Oracle can read that "inforamtion"  (sic).

No kidding!  I read that in the article, and immediately thought to
myself, wow, someone is really pulling the wool over someone's eyes!

> : In addition, the database takes up 12 gigabytes of disc storage 
> : that can't be accessed in pieces. 
> 
> So the machine has 12 gigs of RAM to load it into memory? Oh wait..
> of course it can be accessed in pieces. Maybe he couldn't download
> the raw database in pieces, but Oracle sure can query it in such a
> way as to display pieces.

So, are they saying that state employees cannot access a single
hunter's record, and that instead they have to access the entire 12
GB?

Wow, this really goes to show a couple of things...that there are some
IT folks out there who have no idea what's going on, but also that
there are some "journalists" that really have no clue.  After all,
what is the purpose of a database?  And even Oracle's databases can be
queried to return single records, or "pieces".

> : A transfer of that size would take time, but the hacker was only 
> : on the server for a few minutes.
> 
> Or the logs were zapped past a certain point. It's hard to swallow
> this story, that they detected the intrusion, responded and can
> *guarantee* that no data was stolen. Any company/agency that runs
> the swiss cheese we call Oracle should know better.

Well, we really need to take these things with a grain of salt,
keeping in mind that this stuff is coming to us third- and
fourth-hand, through several filtering mechanisms.  First, there's the
IT folks who aren't versed in the products they use, and certainly
aren't versed in simple troubleshooting and IR activities.  The second
layer filter that adds more noise and removes signal is the author of
the article.  Instead of asking the "hard" question, one like, "why
would someone have to download the entire database?", he simply knods
his head, and trots off to fill space on some page in the paper.

Here's another thing I found interesting in the article:

> "Based on a review of the database after the incident, it appears
> that the hacker was looking for storage space for files, Mason said.
>
> Hackers often use such databases as a temporary location for storing
> pirated software so it can be downloaded by others without leaving a
> trail."

Such databases?  How about simply "systems"?  These "hackers" who are
trying to set up warez servers aren't looking for databases, they're
looking for fat pipes, lots of disk space.  And just the acts of
uploading and downloading the files leaves a "trail".

Again, the author had a great opportunity to ask some tough questions
here, rather than simply accept what was said and type it up.

If I were a hunter in Montana, I'd want to know things like, why is
the system w/ my SSN and address accessible by a "hacker"?  I'd want
to know exactly what happened...how did the "hacker" gain initial
access to the system (was it an insecure FTP server running on the
database system?), and how can the state of Montana guarantee that the
"hacker" didn't run any queries against the database.

The author of the article could have asked questions like this...but
as with other articles like this, such things are noticeably absent.  
God forbid someone ask these questions, and people actually start
getting held responsible for their actions...like putting databases
with personal information on insecure machines connected to the
Internet...

H


------------------------------------------
Harlan Carvey, CISSP
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com 
http://windowsir.blogspot.com 
------------------------------------------



_________________________________________
Attend the Black Hat Briefings and
Training, Las Vegas July 23-28 - 
2,000+ international security experts, 
10 tracks, no vendor pitches.
www.blackhat.com 

Site design & layout copyright © 1986-2014 CodeGods