They dont pay for your car, your clothing, etc... either. Ultimately information devices and Internet connectivity will will be regarded as staples and all be expected of you. Your employability will be based on having them. I can imagine a time when you will be expected to bring in your own computing devices to work - if you "go" to work at all. The whole backoffice will become public space - like your company parking lot already is - and only the core protected information resources will be controlled by the corporation.
"under a government that imprisons unjustly, the true place for a just man is also a prison."
Thoreau.
If a technically sophisticated person recognizes an act as being immoral is he justified in using his techical skills to combat it. Is he required to do so? Can he do so anonymously?
Yep - I agree. easily my favorite celebratory film.
And here the thing being celebrated is the joy of storytelling and the power of imagination ( particularly in children ) to defy and even reshape reality. Muchausen wants to die but she won't let him - why? Because she wants to hear the end of the story. I think that really Munchausen is every tired adult who is growing sick of the story ( or lie ) we have to tell ourselves every day just to keep moving. We may want to die but those damn kids wont let us. They still want to know "what happens next" - and so we keep making it up.
When they throw open the city gates at the end and the Turk really IS gone - well, that was one of the high points in my filmgoing experience.
My other favorite film is "Barton Fink" - a bit darker.;-) and a nice little companion to "The Hours".
Selah.
With webddav exploits available for IIS and the with the recently announced windows scripting vulnerability on the desktop is the situation right for a Nimda reprise? Nimda worked off a combination of IIS flaws and the readme.eml exploit at the browser. Looks like the right mix is here again.
Unix is NOT the name. It's NOT the copyright.
What is it is, what it has become, is Linux.
They are the same thing.
When I ask a guy if he is
a unix-geek I mean is he a linux-geek and I suspect that is what most of you mean as well.
There may be proprietary OS's that look like Unix - Solaris, HP-UX, etc... They are not Unix. They only stole the name from something that does not care about copyright law and will exist long after copyright law is dead.
A security firm I deal with started offering business partner security certifications several months ago. They got their first requests ( 3 ) for this service last Tuesday. All had gotten the SQL worm from partners they had back-end connectivity with.
I think back-end comm channels may be the dirty little security secret of business. From what I can see the standards for granting and maintaining these channels can be pretty lax. That may trace back to the pre-TCP days when all such connectivity was mainframe SNA.
BTW: I suspect the worm's release was a lab accident and NOT intended. It was too clean and did too little - but it will be making me look at all UDP connections we have with business partners.
I wonder if the SNMP udp 161 vulnerabilities announced last year will come back to get us - I am sure the patching was never completed.
1. The worm was strictly based on UDP 1434 transfer
I find it very difficult to believe major corporation firewalls would allow UDP 1434 inside from Internet. Some, maybe - but few.
So: I rule our direct penetration from the Internet for most corporate environments.
2. Worm was memory resident only. Reboot cleared it.
Most user PC's would be rendered useless by the worm. CPU and local Network saturation would do that. So I doubt that people got infected and THEN VPN'ed into work. They would reboot, clear the worm, possibly get re-infected - but I doubt if they would be able to bring an already infected machine into work via VPN.
Note: If split tunneling was allowed then it is quite possible for an already conencted home PC to act as a vector into a company - my guess
is that this is NOT common.
So: I rule out employee remote access as a primary vector.
3. This leaves me with back-end connectivity across private "trusted" comm channels. ( i.e. Frame ).
I know this was a vector in at least one case - and the circumstances ( misconfigured ACL's that were overly generous in what UDP traffic they
allowed from "trusted" business partners ) is something that I suspect is very common in large organizations.
The speed which this thing moved ( see: http://isc.sans.org/port1434start.gif ) and the actual vectors I saw make me very suspicious that
the large organizations of the world are massively linked by misconfigured routers/firewall that allow way too much UDP traffic flow between
trusted partners - affectively a "fuse" linking the worlds computing infrastructures.
That's it. Wacky and overly-speculative perhaps but I would be interested in getting some anonymous feedback about the successful attack vecors
other people saw in the propagation of the worm - particularly people in large organizations that have large "private" comm networks.
Slashdot Mirror
They dont pay for your car, your clothing, etc... either. Ultimately information devices and Internet connectivity will will be regarded as staples and all be expected of you. Your employability will be based on having them. I can imagine a time when you will be expected to bring in your own computing devices to work - if you "go" to work at all. The whole backoffice will become public space - like your company parking lot already is - and only the core protected information resources will be controlled by the corporation.
"under a government that imprisons unjustly, the true place for a just man is also a prison." Thoreau. If a technically sophisticated person recognizes an act as being immoral is he justified in using his techical skills to combat it. Is he required to do so? Can he do so anonymously?
Yep - I agree. easily my favorite celebratory film. And here the thing being celebrated is the joy of storytelling and the power of imagination ( particularly in children ) to defy and even reshape reality. Muchausen wants to die but she won't let him - why? Because she wants to hear the end of the story. I think that really Munchausen is every tired adult who is growing sick of the story ( or lie ) we have to tell ourselves every day just to keep moving. We may want to die but those damn kids wont let us. They still want to know "what happens next" - and so we keep making it up. When they throw open the city gates at the end and the Turk really IS gone - well, that was one of the high points in my filmgoing experience. My other favorite film is "Barton Fink" - a bit darker. ;-) and a nice little companion to "The Hours".
Selah.
With webddav exploits available for IIS and the with the recently announced windows scripting vulnerability on the desktop is the situation right for a Nimda reprise? Nimda worked off a combination of IIS flaws and the readme.eml exploit at the browser. Looks like the right mix is here again.
Unix is NOT the name. It's NOT the copyright. What is it is, what it has become, is Linux. They are the same thing. When I ask a guy if he is a unix-geek I mean is he a linux-geek and I suspect that is what most of you mean as well. There may be proprietary OS's that look like Unix - Solaris, HP-UX, etc... They are not Unix. They only stole the name from something that does not care about copyright law and will exist long after copyright law is dead.
A security firm I deal with started offering business partner security certifications several months ago. They got their first requests ( 3 ) for this service last Tuesday. All had gotten the SQL worm from partners they had back-end connectivity with.
I think back-end comm channels may be the dirty little security secret of business. From what I can see the standards for granting and maintaining these channels can be pretty lax. That may trace back to the pre-TCP days when all such connectivity was mainframe SNA.
BTW: I suspect the worm's release was a lab accident and NOT intended. It was too clean and did too little - but it will be making me look at all UDP connections we have with business partners.
I wonder if the SNMP udp 161 vulnerabilities announced last year will come back to get us - I am sure the patching was never completed.
1. The worm was strictly based on UDP 1434 transfer
.
I find it very difficult to believe major corporation firewalls would allow UDP 1434 inside from Internet. Some, maybe - but few.
So: I rule our direct penetration from the Internet for most corporate environments.
2. Worm was memory resident only. Reboot cleared it.
Most user PC's would be rendered useless by the worm. CPU and local Network saturation would do that. So I doubt that people got infected and THEN VPN'ed into work. They would reboot, clear the worm, possibly get re-infected - but I doubt
if they would be able to bring an already infected machine into work via VPN.
Note: If split tunneling was allowed then it is quite possible for an already conencted home PC to act as a vector into a company - my guess
is that this is NOT common.
So: I rule out employee remote access as a primary vector.
3. This leaves me with back-end connectivity across private "trusted" comm channels. ( i.e. Frame )
I know this was a vector in at least one case - and the circumstances ( misconfigured ACL's that were overly generous in what UDP traffic they
allowed from "trusted" business partners ) is something that I suspect is very common in large organizations.
The speed which this thing moved ( see: http://isc.sans.org/port1434start.gif ) and the actual vectors I saw make me very suspicious that
the large organizations of the world are massively linked by misconfigured routers/firewall that allow way too much UDP traffic flow between
trusted partners - affectively a "fuse" linking the worlds computing infrastructures.
That's it. Wacky and overly-speculative perhaps but I would be interested in getting some anonymous feedback about the successful attack vecors
other people saw in the propagation of the worm - particularly people in large organizations that have large "private" comm networks.