As a comparison, attempts that were blocked that weren’t ssh only totaled 1430. So are these bot’s or people looking for rogue iPhone’s or just trying to find new vulnerabilities in SSH? The interesting thing is it appears that each source IP tries 3 times. The second try is 3 seconds after the first and the third is 6 seconds after the second.

An interesting IP is 217.70.139.42, which has tried 303 times since the 14th. The IP is from Germany and also appears on several SSH dictionary attacks. So is it time to start running services on non-standard ports?

“To minimize the chances of being affected by this issue, Internet Explorer users should ensure their antivirus definitions are up to date, disable JavaScript and only visit Web sites they trust until fixes are available from Microsoft,” Symantec said.

How many mom and pop’s out there even know how to disable java script, and only visit sites they trust? Let alone make sure their antivirus definitions are updated. I have seen some virus trick Symantec’s AV in to thinking the definitions were up to date, and then I go to find hundreds of virus’ on my parents computer. This is just another reason why building the web browser in to the OS is a bad thing and why it should be sandbox’d off in to its own little area.

From Apple’s Web Site:

WebKit

CVE-ID: CVE-2009-2797

Available for: iPhone OS 1.0 through 3.0.1, iPhone OS for iPod touch 1.1 through 3.0

Impact: User names and passwords in URLs may be disclosed to linked sites

Description: Safari includes the user name and password from the original URL in the referer header. This may lead to the disclosure of sensitive information. This update addresses the issue by not including user names and passwords in referer headers. Credit to James A. T. Rice of Jump Networks Ltd for reporting this issue.

Not sure when James reported it though. So I don’t know if I found it before him or not. Anyways, here is my suggestion, if you use an iPhone and have EVER logged in to a web site with a username and password, you need to change that password immediately and then apply the patch from Apple to your iPhone. I know there are some people who view my site that use an iPhone and are clicking on links from other websites, therefore sending your username and password to me as well.

strings ~/Application Support/Nambu/Nambu.db

and the second line will contain your userid and password. They keep saying that it is because they are in beta, and when they move to production, it will go to the encrypted keychain, yadda yadda yadda. But these little things should have been done from the begining… Just wondering why people do stupid security stuff like this…

So it appears that the iPhone has a bug where it seems to like to send the Userid and Password for Websites that you log in to as a referring link if you click on an outside link from inside an protected place.  Say what?  Well let me explain some more:

Say I set up a password protected web site that uses an htaccess style password protection. I then go to that web site, say http://somecoolsite.com/protected. If the userid and password is stored or used in the URL, say I had the user id of unixwiz and my password was IamCool, and I went to the web site with http://unixwiz:IamCool@somecoolsite.com/protected… Once inside the protected site, I then click on a link to some external site, for example http://mycoolsite.com, the iPhone is sending the refering URL as http://unixwiz:IamCool@somecoolsite.com/protected/ .. Which you guessed it, shows up on mycoolsite.com’s access log if they have referrer logging set up, or are doing anything that captures referr data. I would be interested in seeing if it still does it if you are prompted to enter your username and password and not save it.  How cool is that, with the amount of people using iPhone’s now, wonder how many people are looking at the logs to see this sort of data….

FWIW

If you want to give a specific user readonly access to your solaris machine via ssh, and want to log everything they do, it is sort of easy to setup. Here is a quick step-by-step guide to setting it up.

1. First you will need to chose what restricted shell you want to use. In this case I used bash as I wanted the .bash_history file to contain the exact time every command was run on the system. Since Solaris does not come with the rbash command, the only thing you need to do is make a copy of /usr/bin/bash to /usr/bin/rbash.

2. Make the user’s shell be /usr/bin/rbash, this will make them use the restricted bash shell.

3. Make their home directory owned by root.

4. Make their .profile owned by root

5. Create a .bash_history file and make it owned by that user. This should be the only file in their directory that is owned by the user.

6. Pick a location for your “restricted” binaries to reside. If this user will be logging in to multiple machines and you have a shared file system (say /home) I would suggest making the directory in /home; say /home/rbin.. This way you only have to put /home/rbin in their PATH.

7. Make symbolic links in your restricted binary directory to the binaries you want to run. I.e. ls, ps, more, prstat,passwd and hostname :

By making these sym links instead of the actual binaries, you do not have to worry if you have multiple platforms that you are going between (i.e. Sparc, x86) and doing custom logic to use the right binary.

8. Create the users .profile with the following in it:

This will make it so they can not change any of the Environment variables. It sets their path to /home/rbin. Sets a inactivity time out to be 15 minutes. Sets the extended history to be on (this logs the time each command was executed in their .bash_history file). And finally sets their prompt and makes it readonly as well.

9. The last thing you need to do is change the permissions on the scp and sftp-server binaries so that the user can not execute them. Otherwise, they would be able to download files and go any where on the server they want. (Restricted shell will prevent them from cd’ing out of their home directory) To do this, I created a group and put my user in it as their primary group. Say the group was called rdonly. Now I do the following:

So the files should show up like this now:

And the getfacl will look like this:

This makes it so when the user tries to sftp or scp in to the machine, it will immediately disconnect them as they don’t have permissions to run those 2 executables.

That is about it. Don’t forget to set their password, make sure it has a policy set on it to be changed often and require a combination of letters, numbers and special characters and that it is at least 8 characters in length.

So now when the user logs in they will see something similar to this:

As you can see, it will give you errors if you try to do something that you are not allowed to do. The last line shows the time out message where it closes the connection due to inactivity.

Now if the administrator goes and looks at the users .bash_history file they would see this:

The #number is the exact time that the user ran the command below it. The item is the seconds since the epoch…

Surprising is that IBM put’s one of their own OS’s near the bottom of the list. Some of my opinions are :

1. No one uses AIX that much, so no one looks for holes in the code.
2. Any one who uses AIX, doesn’t have it directly connected to the Internet.
3. It is so cost prohibitive to use, that people are looking at Solaris/Linux or Windows to run their business on.

But the funniest thing about this is the last I used AIX the following were still done on install by IBM:
1. telnet enabled
2. root logins allowed remotely
3. no ssh comes with the OS, you have to install a crappy “linux toolkit”, and then install another 10 different packages to get SSH enabled.
4. No RBAC
5. Syslog configuration does not exist
6. Root does not even have a password on install

Seems to me that IBM needs to fix some fundamental issues with their OWN OS before they can say it is not one of the “Most Vulnerable Operating Systems”.

The funniest issue with this is for MacOSX to be listed at the top, all most all of those require some one to actually run something on the machine with administrative privileges.

1. Find the PID of the mysql process

2. Kill the mysql process;

Make sure not to use a -9…
3. Create a file that the user that runs mysql can access; and place in it the following:

4. Start mysql:

5. Try to connect as root now, if it works, delete the temp file; stop and restart mysql.

Granted, the above can be done by any one who knows the password for the account that MySQL runs under, or has root access to the machine. I usually leave the mysql UNIX account in a locked state, so no one can su to it, so you have to have access to root, to be able to su to it.

needless to say, I had to settle with a 14 character password before I just deleted the account all together. Hopefully their delete is really a delete. Kinda funny when the 30 character password I used was : TMG5IRWX4_hP5_Oi7Zh_N5oLXkeWP_