I've a friend that I got an e-mail from. It had an empty subject line and one URL in the body. Twenty others were sent the same e-mail.
I notified the sender that they had an issue. I then decided to use Web-Sniffer to attempt to visit the link and do a quick investigation.
When visiting via the web proxy, I observed the following:
The web server was up and running, serving content but threw a code 302. It also may have attempted to redirect to hxxp://uvuhjomuph.com (I obfuscated the link). Clicking that URL takes me to an ED page (erectile dysfunction):
Googling that domain, I got at least one good hit:
So, my friend more than likely got phished and her e-mail account is now throwing out spam for penile meds. :(
This is an online log of my Slackware experiences. Be aware that I'm also using this blog to cover basic and intermediate security issues that may not pertain to Slackware. This is my way of consolidating blogs (I've several of them).
Thursday, August 26, 2010
Wednesday, August 25, 2010
Protect your privates!
Protect your privates!
http://isc.sans.edu/diary.html?storyid=9367
In view of all the brute force attacks still being attempted against Secure Shell (SSH), we have long since been extolling the virtues of forgoing passwords and moving to RSA/DSA keys instead.
While key based login indeed nicely addresses the problem of password guessing attacks, it looks like many a Unix admin has been less than diligent in the implementation. In pretty much every Unix security audit recently, we've come across unprotected or badly protected SSH private keys (id_dsa, id_rsa). Some reside plain flat out in the open, in /tmp and such. Others are found in world-readable tar "backup" archives of user and administrator home directories. Some are even built into home-grown Linux RPM and Solaris PKG packages, ready to be plucked off an install server.
http://isc.sans.edu/diary.html?storyid=9367
In view of all the brute force attacks still being attempted against Secure Shell (SSH), we have long since been extolling the virtues of forgoing passwords and moving to RSA/DSA keys instead.
While key based login indeed nicely addresses the problem of password guessing attacks, it looks like many a Unix admin has been less than diligent in the implementation. In pretty much every Unix security audit recently, we've come across unprotected or badly protected SSH private keys (id_dsa, id_rsa). Some reside plain flat out in the open, in /tmp and such. Others are found in world-readable tar "backup" archives of user and administrator home directories. Some are even built into home-grown Linux RPM and Solaris PKG packages, ready to be plucked off an install server.
Failure of controls...Spanair crash caused by a Trojan
Failure of controls...Spanair crash caused by a Trojan
Several readers have pointed us to an article about the preliminary report of the Spanair flight that crashed on takeoff in 2008 killing 154. The article suggests that a Trojan infected a Spanair computer and this prevented the detection of a number of technical issues with the airplane. The article speculates that if these issues had been detected the plane would not have been permitted to attempt take off.
NOTE: Another article is here. Another is here, and this one supports the error being on the pilots' behalves (bad pre-flight checks).
Several readers have pointed us to an article about the preliminary report of the Spanair flight that crashed on takeoff in 2008 killing 154. The article suggests that a Trojan infected a Spanair computer and this prevented the detection of a number of technical issues with the airplane. The article speculates that if these issues had been detected the plane would not have been permitted to attempt take off.
NOTE: Another article is here. Another is here, and this one supports the error being on the pilots' behalves (bad pre-flight checks).
Subscribe to:
Posts (Atom)