http://blogs.sun.com/tpenta/entry/the_in_telnetd_vulnerability_exploit
It seems there is a patch available pretty quickly. This does not mean you should turn telnet back on though, leave it off.
Big round of applause for Sun owning up to the mistake and fixing it quickly.
Showing posts with label Solaris. Show all posts
Showing posts with label Solaris. Show all posts
Tuesday, February 13, 2007
Monday, February 12, 2007
SANs sticks head in sand over exploits...
http://isc.sans.org/diary.html?storyid=2220
I really don’t understand organizations some times. SANs states they won’t link to the original advisory Solaris telnet. This confuses me because anybody who really wanted to find it would take a few seconds a Google it and come up with a bunch of sites in the blog-o-sphere that list the exploits. I think they are doing this because they don’t want to be accused of distributing exploits but in the end I don’t think they are making their readers any safer. We have all seen/met/worked for the kind of person that would read the SANs entry and declare it FUD and that telnet stays on. This doesn’t occur necessarily because they are clueless, it could just be that that have been dulled by every security vendor pitch in the world claiming that the sky is constantly falling. It would be a different story if no one knew about this but the cat is most definitely out of the bag. I feel this kind of information is required for a company to test and understand the problem themselves. SANs sees fit to deny this to the people who use them as a sole source of security information.
I would like to know how security vendors are responding to this as well. Errata Security shipped a detailed report on the problem including protection mechanism like a snort rule about a few hours after it was on announced in the early hours of a Sunday morning. Can anybody who uses any other security vendor’s comment on their response; a new ruleset, an alert, advisory, anything?
I really don’t understand organizations some times. SANs states they won’t link to the original advisory Solaris telnet. This confuses me because anybody who really wanted to find it would take a few seconds a Google it and come up with a bunch of sites in the blog-o-sphere that list the exploits. I think they are doing this because they don’t want to be accused of distributing exploits but in the end I don’t think they are making their readers any safer. We have all seen/met/worked for the kind of person that would read the SANs entry and declare it FUD and that telnet stays on. This doesn’t occur necessarily because they are clueless, it could just be that that have been dulled by every security vendor pitch in the world claiming that the sky is constantly falling. It would be a different story if no one knew about this but the cat is most definitely out of the bag. I feel this kind of information is required for a company to test and understand the problem themselves. SANs sees fit to deny this to the people who use them as a sole source of security information.
I would like to know how security vendors are responding to this as well. Errata Security shipped a detailed report on the problem including protection mechanism like a snort rule about a few hours after it was on announced in the early hours of a Sunday morning. Can anybody who uses any other security vendor’s comment on their response; a new ruleset, an alert, advisory, anything?
Sunday, February 11, 2007
Trivial remote Solaris 0day, disable telnet now.
NOTE: Following link may not we work safe due to cartoon...
http://www.com-winner.com/0day_was_the_case_that_they_gave_me.pdf
Oh jeez, that’s not good. This was posted to Full-Disclosure. Remote root exploit in the Solaris 10/11 telnet daemon. It doesn’t require any skill, any exploit knowledge, and can be scripted for mass attacks. Basically if you pass a “-fusername” as an argument to the –l option you get full access to the OS as the user specified. In my example I do it as bin but it worked for regular users, just not for root. This combined with a reliable local privilege escalation exploit would be devastating. Expect mass scanning and possibly the widespread exploitation of this vulnerability.
And example of the command line is
telnet -l "-fbin" target_address
Please disable telnet on Solaris at this time. The HEV for this will be shipping to ErrataSec customers within the hour.
UPDATE: There seems to be some conflicting reports about this vulnerability working with the root account. This does not work on a default install of Solaris 10. By default a variable is set in /etc/default/login called CONSOLE. If this variable is set then root is not allowed to login from anywhere but the console. Commenting this variable out allows root to login from anywhere and allows this vulnerability to take advantage of the telnet exploit. Below is a pic of my trying it with console set then with console commented out.
http://www.com-winner.com/0day_was_the_case_that_they_gave_me.pdf
Oh jeez, that’s not good. This was posted to Full-Disclosure. Remote root exploit in the Solaris 10/11 telnet daemon. It doesn’t require any skill, any exploit knowledge, and can be scripted for mass attacks. Basically if you pass a “-fusername
And example of the command line is
telnet -l "-fbin" target_address
Please disable telnet on Solaris at this time. The HEV for this will be shipping to ErrataSec customers within the hour.
UPDATE: There seems to be some conflicting reports about this vulnerability working with the root account. This does not work on a default install of Solaris 10. By default a variable is set in /etc/default/login called CONSOLE. If this variable is set then root is not allowed to login from anywhere but the console. Commenting this variable out allows root to login from anywhere and allows this vulnerability to take advantage of the telnet exploit. Below is a pic of my trying it with console set then with console commented out.
Subscribe to:
Posts (Atom)