Songbird v0.7.0

“Songbird promises to be the Firefox of media players”

—Aaron Boodman, Greasemonkey

then I guess Foobar promises to be the “Opera” of media players…

Songbird = orgasm

foobar = multiple orgasms

Pass

root@utam-f9:/data/bin # bash /downloads/unsorted/direct/wget/openssh-blacklist-1.0.sh
PASS: no suspect packages were found on this system

Redhat: To check your boxes are pwnd

http://www.redhat.com/security/data/openssh-blacklist.html

<snip>

We have provided a shell script which lists the affected packages and can verify that none of them are installed on a system:

* openssh-blacklist-1.0.sh

The script has a detached GPG signature from the Red Hat Security Response Team (key) so you can verify its integrity:

* openssh-blacklist-1.0.sh.asc

This script can be executed either as a non-root user or as root. To execute the script after downloading it and saving it to your system, run the command:

bash ./openssh-blacklist-1.0.sh

If the script output includes any lines beginning with “ALERT” then a tampered package has been installed on the system. Otherwise, if no tampered packages were found, the script should produce only a single line of output beginning with the word “PASS”, as shown below:

bash ./openssh-blacklist-1.0.sh
PASS: no suspect packages were found on this system

The script can also check a set of packages by passing it a list of source or binary RPM filenames. In this mode, a “PASS” or “ALERT” line will be printed for each filename passed; for example:

bash ./openssh-blacklist-1.0.sh openssh-4.3p2-16.el5.i386.rpm
PASS: signature of package “openssh-4.3p2-16.el5.i386.rpm” not on blacklist

Red Hat customers who discover any tampered packages, need help with running this script, or have any questions should log into the Red Hat support website and file a support ticket, call their local support center, or contact their Technical Account Manager.

</snip>

Redhat & fedora hackered, suspect Steve Jobs

Errr

https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html

<snip>

Last week we discovered that some Fedora servers were illegally
accessed. The intrusion into the servers was quickly discovered, and the
servers were taken offline.

Security specialists and administrators have been working since then to
analyze the intrusion and the extent of the compromise as well as
reinstall Fedora systems. We are using the requisite outages as an
opportunity to do other upgrades for the sake of functionality as well
as security. Work is ongoing, so please be patient. Anyone with
pertinent information relating to this event is asked to contact
fedora-legal redhat com
</snip>

http://rhn.redhat.com/errata/RHSA-2008-0855.html

<snip>

Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers.

In connection with the incident, the intruder was able to sign a small number of OpenSSH packages relating only to Red Hat Enterprise Linux 4 (i386 and x86_64 architectures only) and Red Hat Enterprise Linux 5 (x86_64 architecture only). As a precautionary measure, we are releasing an updated version of these packages and have published a list of the tampered packages and how to detect them.

To reiterate, our processes and efforts to date indicate that packages obtained by Red Hat Enterprise Linux subscribers via Red Hat Network are not at risk.

</snip>

Ever Popular Directory Traversal Vulnerabilities

Fujitsu Web-Based Admin View Directory Traversal Vulnerability

Version: 2.1.2 on Solaris, Other versions may vulnerable

Vulnerability: Directory Traversal
Risk: Critical

Description: Due to insufficient control of user inputs, Fujitsu Web-based admin view reveals content of files residing in folders other than webroot. This will allow an attacker to view arbitrary local files within the context of the web server.

Sample Request:

GET /.././.././.././.././.././.././.././.././.././etc/passwd HTTP/1.0

Host: target:8081

OMG: Obama’s long lost brother FOUND!!!!

No this doesnt just happen in bollywood, in real life too http://www.telegraph.co.uk/news/newstopics/uselection2008/barackobama/2590614/Barack-Obamas-lost-brother-found-in-Kenya.html

sshdrive is free vs sftpdrive paid

Accessing sftp drive from windows, mounted as an independent drive letter. Download free software sshdrive http://sshdrive.com/ alternative to sftp drive ….

Bah! Not able to sftp! But ssh works! WTF!

Wasnt able to sftp (filezilla, winsftp, sftpdrive, all fail) to my linux box, but was able to ssh like normal. SFTP gives weird error “Received message too long “. Realized the fucking bashrc/profile.d causing this issue. When ssh starts up the sftp subagent the shell must be clean, else the sftp may fail with error like this.

#sftp from localbox.

g@utam-f9:/temp $ sftp -v root@localhost
Connecting to localhost…
OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /data/home/g/.ssh/id_rsa type 1

….

debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending subsystem: sftp
Received message too long 167772160
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

A quick inspection reveals, few lines in my bashrc are using colors to echo out some funky message, whenever I login to root. So a quick work around :)

if [ ${TERM} != “dumb” ]; then

cowsay -s Hey man, you are ROOT now! Careful!  > ~/_cowsay.txt
dialog —title ‘ROOT!’ —textbox ~/_cowsay.txt 16 45

fi

ZOMG SuckCess!!!!

g@utam-f9:/temp $ sftp -v root@localhost
Connecting to localhost…
OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *

…

debug1: Next authentication method: publickey
debug1: Offering public key: /data/home/g/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering public key: /data/home/g/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: password
root@localhost’s password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending subsystem: sftp
sftp>