I have been seeing tons of these Errors and Warnings in Event Viewer logs under Application section. I assumed this was a result of remote desktop connections with “printer sharing” enabled and I didn’t bother to look at around. Once I did some research about this issue, I realized the issue was related to “Windows Image Acquisition (WIA) service“. Once I stopped this service, the errors and warnings went away.

The Error / Warning Logs:

STI BrtSTI: [2010/10/22 21:28:20.778]: [00008156]: SendSkeySettingToDevice Device IpAddress Unknown []
STI BrtSTI: [2010/10/22 21:28:20.769]: [00008156]: GetDeviceIpAddress: GetAddressByName [] Error
STI BrtSTI: [2010/10/22 21:28:20.768]: [00008156]: GetAddressByName: gethostbyname[] Error[11001] 

Event Type: Warning
Event Source: Brother BrLog
Event Category: None
Event ID: 1001
Description:
STI BrtSTI: [2010/10/22 21:28:20.769]: [00008156]: GetDeviceIpAddress: GetAddressByName [] Error

Event Type: Warning
Event Source: Brother BrLog
Event Category: None
Event ID: 1002
Description:
STI BrtSTI: [2010/10/22 21:28:20.768]: [00008156]: GetAddressByName: gethostbyname[] Error[11001]

Google made a shameful move last week to people’s privacy. She has been losing in the social area since Facebook and Twitter’s dominance. On one side Microsoft – Facebook getting closer on search deal. Twitter is also moving towards Google. Facebook had revealed their search numbers several months back. “Over 600 million searches per month” when their member numbers was around 200 Million and they had doubled it since then. Putting together all this, Google needed the best dang for the shot and they did it by prying on everybody’s privacy. They couldn’t have any ground on social side with Orkut, Google Profile, Friends, Gtalk, all those things miserable failed and they couldn’t dominate it. Buzz privacy failure was another attempt to create the reaction to awaken people to use their services. It created a lot of debate and they took action right away to limit Buzz after the reactions.

Personally, I was exposed to my employees on my personal Gmail account and when I realized my private accounts were revealed all together in Google Buzz to everybody, I tried to close it down but there was no option offered by Google. It didn’t just happen to me but there was a woman with her lover in trouble which caused social reaction on twitter and other websites.

I find Google’s action to create the social reaction and find the attention that they were missing on social marketing side for a long time.

It is a very simple but very useful example. You can use UE Studio’s Regular Expressions to catch and change anything very easily.

In order to capture an IP Adress you can use this regular expression: ^([0-9]+^).^([0-9]+^).^([0-9]+^).^([0-9]+^)

Once you capture the date, you can use ^x1 ^x2 to replace the changes so for this example in order to convert A record to PTR record, you can follow this:

Find What: ^([0-9]+^).^([0-9]+^).^([0-9]+^).^([0-9]+^)
Replace With: ^3.^2.^1.in-addr.arpa ^4

This will give change this 172.22.101.10 into this 101.22.172.in-addr.arpa 10

I would like to transfer from one hosting (Mediatemple) to another (Resellerzoom) (both of them were doing superb job for 2 years btw) but I don’t want to transfer some of the old files. I tried most of tar –exclude combinations I could find on the forums but they did not work. One of them was an answer to a question “tar, excluding directories recursively ” on linuxquestions.

I believe it was due to Mediatemple’s environment which strictly jails you under your account. I tried to exclude with full path initially but it kept getting all the files.

So I decided to use -v (verbose) argument to show the compressed files in the realtime. This way you can capture instantly if you are making a mistake or not. I was initially doing with:

tar -cvf techsoar.tgz --exclude "/full-path/phones/*" --exclude "/full-path/mobiles/*" ./

Which I realized using with “” was a mistake and furthermore not putting an “=” sign between –exclude=… was also wrong.

So finally I could get it working with this line:

tar -cvf techsoar.tgz --exclude=phones/* --exclude=mobiles/* ./

I started seeing these ERROR logs in apache this morning. Somebody is trying to see if a file named “w00tw00t.at.ISC.SANS.DFind” exists on the server or not. A little research revealed, I am not the only one targeted to these attacks but there were others (example: from Webmasterworld, from Sans)

w00tw00t.at.ISC.SANS.DFind logs are the traces of DLink vulnerability scanner which is looking for flaws to exploit and get ‘root’ rights on the server. Unless you have a vulnerability, you are not prone to these attacks. You don’t have to freak out right at this moment but do a little research. I would advise these:

• Check your /public_html/ or /http_docs/ folder to see if those files really exist or not.
• If you have root rights on your server, check the processes running on your server:
  # ps -ef
  If you don’t have the root rights, contact with your hosting company.
• # lsof will show you the open files on the server. If you know for a fact that; sshd, httpd, mysqld,cpanel are running on the server and they are safe. You can try:
  # lsof | egrep -v "(sshd|httpd|mysqld|cpanel)"
  This will quickly reveal the open files on the server and by skimming through the list, you can identify weird names like “./httpd, ./ps, ./w00t”. Then you can find out where those processes are running from and delete them. You need to first delete the process and then kill the process to off load them from memory.
• I would suggest disabling ftp server and any other server that you can not keep up with the updates and not very mission critical.

As far as I can see from my log files, there are different variations of traces of this scanner:
w00tw00t.at.ISC.SANS
w00tw00t.at.ISC.SANS.DFind
w00tw00t.at.ISC.SANS.test0


The full spec looks like this:

[error] [client 216.168.43.234] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

These are the attacker bees that I captured in last 2-3 days:

[error] [client 124.60.128.27] (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)


[error] [client 97.74.120.70] (see RFC2616 section 14.23) /w00tw00t.at.ISC.SANS.DFind
[error] [client 128.121.239.210] (see RFC2616 section 14.23) /w00tw00t.at.ISC.SANS.DFind
[error] [client 74.7.26.59] (see RFC2616 section 14.23) /w00tw00t.at.ISC.SANS.DFind
[error] [client 163.117.157.226] (see RFC2616 section 14.23) /w00tw00t.at.ISC.SANS.test0
[error] [client 91.190.93.141] (see RFC2616 section 14.23) /w00tw00t.at.ISC.SANS.DFind
[error] [client 207.210.233.50] (see RFC2616 section 14.23) /w00tw00t.at.ISC.SANS.DFind
[error] [client 67.19.254.226] (see RFC2616 section 14.23) /w00tw00t.at.ISC.SANS.test0
[error] [client 61.119.173.150] (see RFC2616 section 14.23) /w00tw00t.at.ISC.SANS.DFind
[error] [client 75.127.91.174] (see RFC2616 section 14.23) /w00tw00t.at.ISC.SANS.DFind
[error] [client 173.45.84.136] (see RFC2616 section 14.23) /w00tw00t.at.ISC.SANS.DFind
[error] [client 216.168.43.234] (see RFC2616 section 14.23) /w00tw00t.at.ISC.SANS.DFind
[error] [client 173.45.84.136] (see RFC2616 section 14.23) /w00tw00t.at.ISC.SANS.DFind