
Internet Auditing Project Results 161
The Internet Auditing Project has returned with some pretty grim results. From Jan 99, they tried to crack 36 million servers, and found that a huge amount of the machines, and some you would think aren't, are open. They've also made the program they used Bulk Auditing Security Scanner availible for download. Pretty disturbing results though-well worth reading.
You're telling me. (Score:1)
I try to be at least a little paranoid on any system I set up for public access. Installing ssh, disabling telnet, allowing connections only from hosts with intended users, yadda yadda...
There's no way in hell I'd catch that.
My machine could be cracked right now, and I wouldn't know it.
That scares the sh*t out of me.
Re:Hey look, script kiddies with a project. (Score:1)
Yes, and what if someone on that EZ box uses SSH to connect to your "secure" system?
Re:Hey look, script kiddies with a project. (Score:1)
Stealth Reboots (Re:Get a clue) (Score:1)
Don't be so sure about noticing reboot.
I think it's theoretically possible to reboot a system, replace the kernel, and bring back all of the processes as if nothing has happened. This of course requires grabbing images of the processes and their state before rebooting. Really, if you can replace the kernel, you can do practically anything.
Heck, on most servers it would probably be sufficient to reboot the machine in the middle of the night and then fiddle with the system uptime and processes' run time to make it look like the uptime was still 200+ days.
So, when using securelevels it is important to make sure that everything involved in the boot process is locked down.
Re:BASS core dumps... (Score:1)
Re:Hey look, script kiddies with a project. (Score:3)
As they said in the report, we don't live in isolation on the Internet. If any host is insecure then there's usually a knock-on effect which could affect any one of us.
Rob Wilderspin
Re:super crack (Score:1)
That the Linux kernel could be modified on-the-fly via a module is a serious security hole. That really needs to be fixed, urgently, IMHO.
Well, if you're that paranoid you can compile a kernel without module support. (you may have some difficulty with newer hardware, PnP devices and stuff though..that's a problem. Maybe sort-of modules..compile it like a module but load it into the kernel at bootup, just delay its activation and don't allow later loading of modules)
Loadable module support is always going to leave you vulnerable to this sort of thing, though.
Daniel
BASS core dumps... (Score:1)
super crack (Score:2)
Huge amount? (Score:2)
I think it was a neat project, I was very interested in the "super hack" that occurred on one of the participating scan servers, and I think the groups recommendation for an IDDN is a worthwhile project.
But I still am actually reassured, not scared, by the fact that less than 2% of the hosts in their fairly sizable test group were "wide open" (as I would consider any host that is vulnerable to a common exploit)
-Count Zero-
IDDN... (Score:3)
Of course, law enforcement will hate IDDN; after all if there are no more security vulnerabilities how are they going to snoop on us^H^H^H^H^H^H^H^H^H^H^H^Hprotect us from evil terrorists?
Re:super crack (Score:1)
FUD by any other name.. (Score:1)
Bowie J. Poag
Re:Throw them in jail! (Score:1)
2) No, they *shouldn't* go to prison. Some archaic (Is that how you spel that?) laws say they should go to prison, but that's something rather different.
Re:FUD by any other name.. (Score:1)
Re:.jp intrusion (Score:1)
Funny (and prophetic) comment in Makefile (Score:1)
# -lnsl -lsocket -lresolv -lrpc (is that how the rpc library is called?)
#
# On Irix you'll need to... Hmmm...
#
# Forget it! I'm not going to fight Unix. Here's a nickel kid, go buy yourself
# a Linux distribution.
Re:Criminals (Score:1)
Re:super crack (Score:1)
Re:BASS core dumps... (Score:1)
~Tim
--
Re:BASS core dumps... (Score:1)
Never was the name 'anonymous coward' more applicable; the only more applicable one is 'pillock', I think.
~Tim
--
Scary. (Score:2)
In fact, if "them" can get into any box in the net, they could change our systems in a way we wouldn't be able to notice (read "Reflections on Trusting Trust"). Then any system we made from any of our systems would be compromissed too. "They" would have backdoors to any computer in the world, and there would be no way we could find out except out of sheer luck ("this system is acting strange, the foo feature is not working as the source says it should...").
See also Worst Nightmares Come Alive [hackernews.com].
Interesting (Score:2)
Notice which vulnerabilities are the most common:
tooltalk 26.1%
bind 18.1%
wu_imapd 15.5% (hel-LOO! anyone hoooome??)
qpopper 12.4%
wwwcount 11.8%
rpc_mountd 10.8%
This was right before the big wave of tooltalk advisories came out so it may be somewhat less now.
What is instructive is that, face it, TCP/IP and all the associated dependencies are way too complex but we can't roll this back so get used to it. No reason to give up on tightening things, of course.
For an interesting view from another level, read Stephen Northcutt's new book Network Intrusion Detection (New Riders Publishing).
-------
Re:Securelevels (Re:super crack) (Score:1)
Re:BASS core dumps... (Score:2)
It seems to occur if you actually use the ``-l logname'' option (at least this is what triggers it for me). The problem seems to be with getopt() not seeing the ``logname'' part, returning 0 which then causes the segfault. I am at a loss at why this would be happening.
However, doing the full `make install' and running it as root with the default log file location (/usr/local/bass/bass.log) works for me.
In general this program seems a little shifty. For example, why is there the (default) ability to clear out it's argv[0] (and thus be less immediately detectable in the process table)? And why does it need a ``coward'' mode. It seems as if it was written to run on machines where it wasn't supposed to be.
Re:Condemnation of the C-programming language (Score:1)
1.I already exempted systems programming. You may as well bring up assembly language too.
Then what kind of applications are you talking about? Buffer overflow in a program that never uses anything but the data it produced before, can't compromise the system anyway. And if a program is a mailreader, text editor or web server, the same rules as for "system" software apply.
2.bzzt! thanks for playing. Many other languages such as Ada and Eiffel are "bootstrapped" from C into a subset compiler, and then fully rewritten in their own programming language and used to compile themselves. You obviously know zero about compiler technology. I suggest taking a course or reading the Dragon book.
I am familiar with that. The point still stands -- implementation does not necessarily works correctly, nothing gives a hard proof that combination of generated code plus system libraries plus OS still follow the rules that were supposed to be implemented.
So? The point it it's safeER, not completely safe. With a fully debugged string/buffer/collections library with assertions and bounds checking, less programmers will "reinvent" them and there will be less bugs.
This has nothing to do with language -- only with libraries. And "standard" libraries that come with C++ can help only with extremely dumb cases of buffer overflows, so "increase" of safety exists only if a programmer doesn't think at all. To eliminate the theoretical possibility of buffer overflows one has to eliminate pointers, and this can't keep system simple and efficient enough to be implemented well -- look at Java.
The facts are, stronger typed languages produce less bugs, period. Years of study by the military and NASA (do a google search) bear this out.
Why should I trust them? Military pushed Ada for ages and achieved nothing -- they have to "justify" their wasted time somehow.
WRONG! In many if not most of the cases, the compiler has sufficiently enough information to *PROVE* that an invalid array access can't occur, and hence can remove bounds checking code altogether. This occurs for example, when variable is incremented monotonically, like most iteration code which accounts for most loops.
Problems start when functions are being called, and cross-dependencies between data structures in them (not necessarily even data structures that exist at the same time and definitely ones that didn't exist when libraries were compiled) come into play.
Web Apps in particular are a perfect example. Their performance is easily bounded by network, disk, memory, and database performance long before CPU even matters. The CPU spends most of its time waiting for I/O to complete.
This only applies to primitive applications that do nothing but wait for database to give result, then do something trivial to represent it. "Web application" that performs complex calculation on its own or its backend application that keeps track of various parameters that are not stored in database will be still CPU-bound. If a lot of amateurs manage to stick database and high-latency access to it everywhere where it doesn't belong, it doesn't mean that this is correct or even sane way to solve those problems.
Any book on scalability will tell you this. And, when it comes down to CPU bound apps, 80-90% of the CPU time is spent in 10% of the code, so it makes sense to concentrate your risky optimized bounds-check free code there.
This won't improve security because in most of cases exactly the same code is most likely to contain buffer overflows, and in various conditions distribution of time spend in different pieces of code may change thus opening an easy DoS vulnerability (ex: almost all routers DoS).
I'm simply amazed at the number of so-called programmer geeks on slashdot that don't understand Knuth's Law or Amdahl's Law. People who have orgasms over Mhz ratings, and then wonder why some code on a 90Mhz sun will rock their 300Mhz pentium application.
How is it relevant? You still can't take already implemented and optimized application and make its equivalent on the same hardware with the same performance if you will reimplement every part of it in less efficient way.
I'm sorry, but C simply isn't the right tool for every job. It has it's place in systems programming, much like Perl is great at text processing. It sucks for everything else, and I speak as someone with 13 years C experience. I guess, I decided that it is better to know and use multiple programming languages than to rely on only one.
Most of things still can't be implemented in inefficient language and be expected to remain usable. If one is afraid of buffer overflows, he should get more benefit from buffer-overflow protection tricks in function calls, nonexecutable stack, etc. -- and even that is considered too expensive in the terms of performance in most of cases. And if someone claims that his language can eliminate all possible, or even most of classes of security bugs, he is lying, and Java is the best example of this so far.
Re:kmem tekniq (Score:1)
IIRC you can turn off
IIRC there is *no* way to write to a write-protected floppy through software.
If someone rooted your machine then you're fucked anyway. I always thought the trick was to make your machine either impossible (yeah right) or very difficult to root.
Re:super crack (Score:2)
Second, it doesn't matter if it was an overseas phonecall. The tunnel endpoint wouldn't be with the ISP! It would be with the host machine.
Thirdly, yes there would. Yes, you could break the encryption (it's very simple), and modify the routines so that they use absolute values rather than checksums. Yes, you can install stealth code to trick the kernel into thinking no changes have occured. All these are perfectly possible, and I understand the mechanisms well. The point is, the magnitude of the changes required is far greater than for a simple, unprotected binary. The stealth code is therefore going to be bulkier, to hide all those changes. So, either the stealth code is going to reveal itself, or an antivirus scanner will pick up the changes.
The trick with any kind of protection is to not bother trying to make the protection itself perfect (you can't), but to force attacks on that protection to be visible.
Re:super crack (Score:1)
> He probably used the password-saving feature
> of the dialup software. It's easy to get it
> this way (since the dialer needs the plaintext
> password to do the dialing)
Just being nitpicky here, but CHAP doesn't send anything plaintext...
... unless you're talking about grabbing the ISP password from the registry or something.
Idea for OTP to prevent this (Score:1)
when you SSH in the password is passed and the indexed incremented. Use the same thing for su. PAM would be wonderful here.
Any thoughts?
Re:super crack (Score:1)
Re:Huge amount? (Score:1)
SuperCrack - clarifications (Score:4)
"The crack was via an NT box, so the weakness was less in Linux itself than in NT. (NT has more holes than swiss cheese.)"
2: This is only an hypothesis, but is strongly supported by the fact that the entire attack only lasted an incredible 8 seconds! During which the attacker manages to log on (over an employee's SSH account, no less), gain root privileges, backdoor the system, remove any (standard) traces of it's activity and log off.
3: Further investigation shows that this employee's personal NT box, connected over a dynamic dailup connection, had been cracked into 4 days earlier.
It appears that the crack was due to an NT box, not via it. The actual intrusion came in at the Japanese ISP, and the intruder already knew the username and password for both the ISP and SSH. Note that the phone call to the ISP is from an "untraceable overseas" number.
"The second vulnerability was SSH. Someone altered the SSH client to act as a trojan. This should not be possible - programs should be able to detect if they've been modified. Failing that, a virus scanner should be able to detect modifications."
They were using scanning and file comparator software. Even when the backdoor was identified and manually examined, they "could not detect any odd behavior"! Impressive.
"Thirdly, how did they get hold of the ISP password? The article said SSH was cracked, but not that the dial-in software was. "
There's no specific quote I can use here, but knowing the NT box was compromised leads me to believe that the ISP account was compromised shortly thereafter. I've tried L0phtCrack, it's an impressive program. If I can 'script kiddie' almost every NT machine I've ever worked on like this, getting the ISP account info out of the registry isn't much of a stretch.
I want to know how they ID'd the NT box in the first place. I don't know how they did that, and I can't even start to guess...
Re:Not impressed (Score:2)
Re:super crack (Score:2)
> altered the SSH client to act as a trojan. This
> should not be possible - programs should be able
> to detect if they've been modified. Failing
> that, a virus scanner should be able to detect
> modifications.
As the author of the package that was trojaned (TTSSH), I feel obliged to point out that there is NO WAY for a program to reliably detect if it's been modified. The cracker can always just disable the code that's supposed to detect the modifications. (This is a bit easier when source code is available, as TTSSH's is.)
A separate virus scanner might be a bit tougher, but would be vulnerable in the same way.
what id like to see.. (Score:1)
Re: Throw them in jail! (Whose jail? Where?) (Score:1)
Re:Paranoid Thought of the Day (Score:1)
Sure... if you want to refer to marketing as a "conspiracy". And that's not too far from the concept. Marketing IS selling. Selling is getting people to do what you want them to do. It's just that marketdroids are so much less exciting than gunmen on grassy knolls.
Re:Wen Ho Lee??? Does He Count? (Score:1)
Re:super crack (Score:1)
Clue: 36 million addresses, not Unix hosts (Score:1)
Be scared. Be very scared.
-russ
Re:SuperCrack - clarifications (Score:1)
And the eight seconds bit is certainly enlightening. They had to have had a way of knowing exactly what was on this box (notably KDE's buffer overflow problem) to get in, do it's thing, and get out. Perhaps it could be BO, they could sit back and watch the user for a couple days, grabbing passwords, watching what they do when the SSH in, etc. Hmmm
OK, someone's daydreaming (Score:1)
A global fury of half a billion packets, digital signals zipping back and force across the planet at the speed of light. Above the Earth, across the land, under the sea, over satellite microwave, copper wiring, fiberoptics, wireless and undersea cable. Probing cyberspace.
... all is not well.
... but the proud people of the free world stand strong (led by Harrison Ford, no doubt).
In the world of tomorrow...
Seven hundred thousand vulnerabilities, gaping holes, wounds in the skin of our present and future information infrastructures, our dream for a free nexus of knowledge, a prosperous digital economy, where we learn, work, play and live our lives. Easy pickings, at the fingerprints of anyone who follows in our footsteps, friend or foe.
Struggles for power in the digital domain could very well develop into the world's first real information war, with the very future of the Internet as a free unregulated supernetwork caught in the cross fire.
The stakes are huge, the weapons deadly...
The only thing necessary for the triumph of evil is for good men to do nothing. Wake up fellow countrymen. Let's get to work.
Coming August 14th to your local cinema.
Whoever wrote that article has some pretty big delusions of greatness there. The same applies to the "IDNN" project. First, they seem to have forgotten that scanning systems for vulnerabilities is very much illegal in many countries. I don't know the specifics, but I'd guess that it's illegal in much of North America and western Europe, which also happen to be the homes of most Internet users. That might kind of hurt any effort of this type. People are also not going to like being on the receiving end of regular scans. It would certainly make it difficult to tell the difference between a "friendly scan" and an attempted (or maybe realized) crack. Finally, I'm sure that someone would manage to subvert that system if it ever came into being. This isn't like hacking a distributed.net client; subverting the system would allow you to gain access to many computers.
And in the final analysis, the numbers aren't all that bad. Under 2% of the servers on the Internet is not a huge number. I'm sure many of those boxes are relatively unimportant boxes that are probably just personal machines. That 2% may be composed of forgotten boxes in university/corporate offices. Also, this is purely theoretical; I doubt that all those boxes could just be cracked into in seconds.
Oh, one more thing: someone tell this guy what "How discrete" means!
Re:Paranoid Thought of the Day (Score:1)
That's a nice idea, but there's a simpler explaination. The Government IT budgets are controlled, in the most part, by PHBs. What sells to Corporate PHBs, also works for Government PHBs.
Re:Criminals! (Score:1)
You miss the point (Score:2)
Re:Criminals! (Score:1)
Doesn't this just SCREAM for a "flamebait" tag? :)
Welcome to the real world. It's populated by lots of generally cool, intelligent people. It's also chock-full of people with malicious intent. That's why we have people who make it their profession to protect those who hire them.
The dynamics are the same online as offline. Most people already know this. Perhapse its new to you? In any case, either produce some Good Ideas on how to fix the situation or take your sabre-rattling elsewhere. On the off chance that this is humor... work on your delivery.
(note to moderators: aren't these kinds of notes simply missing the point?)
Re:Hands off (Score:2)
Droids (Score:1)
1. Stupid thing to do, go find someone to work for.
2. Cool project. I make comments but do nothing.
3. I posted first!
Look. Back in the old days we used to call up BBSs and down load the latest t-file from the cDc. It called for action "Go out! Save yourself! Do something!" I'm only 23. But, back then I went to school and didn't think about guns. I thought about Nukes. Now suddenly, people shooting eachother left and right. People get pissed and say we should do something, but nothing is done. Or, people just think it doesn't happen around here.
Well, let me offer you a clue. Nukes = got enough money go get one. Guns = that kid Kip in Springfield, I dated his sister -- I cooked dinner in his house.
This guy scanning is like Paul Revere. One if by land, two if by sea, three if by fiber. China is getting pissed and our whole economy is running off the net right now.
If you don't smell the smoke you won't get burned right?
Linux is a counter-culture. Once you have a mascot you just sit back and watch the game. Slashdot and freshmeat are your cheerleaders, but won't it be funny when you find out that's the idea.
Keep em occupied and they will obey.
Stop reading these half-thought, rant things and look around.
Look at a gas station, see that dish? Look at the supermarket see that veriphone. Can you say rations, food coupons, etc.
Re:Condemnation of the C-programming language (Score:2)
Re:Casing or something else? (Score:1)
well.. (Score:1)
*gasp*
actually read the article, download the scanner that they used in their survey, and scan all the computers that you're wondering about
not too hard now is it?
btw, it compiled fine for me.
...
Re:.jp intrusion (Score:2)
You want a protection agency (Score:2)
From there we move on to people complaining that there arn't enough "public goods". So they start to form welfare societies and opera groups. These slowly get bigger and have trouble managing their money collecting, so they turn to the people who already have a good system of collecting cash - the state. Welfare and opera become another thing that everyone must pay for, and the "protection fee" becomes a "tax".
The alternative is to refute any form of authoritarianism.. because we know where it leads, to an all powerful state who spends billions of dollars on war planes when half the world is starving.
Re:Hey look, script kiddies with a project. (Score:2)
Re:OK, someone's daydreaming (Score:1)
Doesn't matter. If any machine on a network is insecure, then the entire network is insecure. Read the story of their own crack. J. Random Employee runs an insecure NT box. Result: Entire company network is compromised, and one of the most secure machines on it is rooted.
That 450,000 compromises millions of other machines. And those millions compromise others, which compromise others... What depth does one need to reach any machine on the net? What's the average degree of seperation of two random boxes?
One of my ISP's n-thousand users has a cracked box. This is a certainty. Now I could be running trojans, and my school's network is compromised. From there, access to hunreds of private, academic, and government networks...
Re:Huge amount? (Score:1)
Remember, the Linux box that was cracked was 'secure' as far as the Audit would show. Yet, it was comprimised, through the compromization of another box.
The analogy was made in the article that the Internet is less of a community, more of an organism. When one area is infected (cracked) it can spread to other areas easily, without the problems of having to crack each box individually.
Just remember that.
Re:Criminals (Score:1)
A funny outlook to the Crack =) (Score:4)
I suppose after Columbia Internet got hit with the probe, Erwin took it personally. After having NT on it's drives before, I imagine it knew exactly how to get into the NT box and play around with everything to get the SSH going and eventually onto the Linux box.
It makes perfect sense =) That's what we get for messing around with an AI of that caliber
Re:Paranoid Thought of the Day (Score:1)
Or, in other words, the conspiracy is so good it doesn't even know of its own existence. Which is, of course, a sure sign that there is a universal conspiracy going on - just not necessarily an orchestrated one.
I should get around to reading "Revelation X" like my roommate insists I do... (No, he's not a "bobby," he just knows what's going on.)
---
"'Is not a quine' is not a quine" is a quine.
Re:SuperCrack - clarifications (Score:1)
U SUK (Score:1)
kmem tekniq (Score:1)
Re:IDDN... (Score:2)
Word to the wise: secure the hell out of your box before you go poking around and knocking on people's doors and peeking in windows. A lot of people don't take kindly to portscans. Some of them will peek back, and maybe bounce your box and check for common vulnerabilities as a warning shot.
Re:what id like to see.. (Score:1)
Yeah.
Re:Microsoft Excluded (Score:1)
Perhaps Microsoft (if hell freezes over) will see what this means. Serious administrators concerned about security will/should shy away from using Win 95/98/NT for mission critical operations and networking where security is a concern. Then, when they are serious about beefing up security, they won't run windows2000test.com. Instead they'll allow independent and open review of their security system and network protocols. After all no one seems to trust an un publicly tested encryption algorhythm.
Only after Microsoft has taken the serious step to more secure networking, do I think they'd be worthy of the scanning effort.
Minor nit (Score:1)
Um, they didn't try to crack 45 million computers. All they did was probe for known exploits.
Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16
U.S. DoD/Military (Score:3)
As a point of caution to those about to grab this latest scanner and joyride, every military installation & network is monitored 24/7. I assure you, portscans are detected and the source IP recorded & blocked. (To be specific, for 15 days after the attack/intrusion; if it occurs again, further measures are taken.)
Of course, where I work, many of the CSSOs and TASSOs consider applying the latest patches/disabling the latest services to be rather a pain. But then, it's a research institution, and scientists don't like to sully their hands with such mundane matters.
Just wanted to reassure slashdotters that the military does take computer security very seriously. At some laboratories, you would have better luck sauntering in and sitting down at a computer physically, than messing around with network attacks.
Casing or something else? (Score:2)
I've come up with a few thoughts:
1) This seems to be beneficial information on the general state of security on the Net (poor)
2) Any sysadmin smart enough to check logs and not be lulled feeling secure should use this as a further wake-up call to review their services. Do they really need non SSH telnet services running? How are those firewall settings?
3) There are those out there who will always take things the wrong way.
I'm interested in seeing where this project ends up. With RC5 like support, or in jail like Mitnick.
Re:U.S. DoD/Military (Score:1)
> this latest scanner and joyride, every military
> installation & network is monitored 24/7. I
> assure you, portscans are detected and the
> source IP recorded & blocked. (To be specific,
> for 15 days after the attack/intrusion; if it
> occurs again, further measures are taken.)
Damn straight. I think our base blocks them for
longer than 15 days, though... that may just be
local extra paranoia. Not my baliwick, so I
could be wrong.
> But then, it's a research institution, and
> scientists don't like to sully their hands
> with such mundane matters.
When I worked on base before, I used to try and
make things convenient for my users as long as
security never got compromised. If they came and
complained, well, sorry, but that's the way
things have to be. Usually they understood.
Lately I've decided that I won't even listen to
"inconvenience" complaints. Screw 'em. My boxes
haven't been cracked yet, and I'm not going to
take any chances. So they have to go through
extra steps. Waaah.
RE: Throw them in jail! (Whose jail? Where?) (Score:2)
[Now, a little more off topic...]
Securelevels (Re:super crack) (Score:3)
Yes, it sent chills down my spine when I read it as well. I've known such things were possible but didn't think anyone had yet gone to the trouble.
There are things you can do about it, though.
Some Unixes, including Linux and the freeware BSDs (all BSDs since 4.4, I think), have the concept of "securelevels". Set files to be immutable (under *BSD the command is "chflags schg somefile") and raise the securelevel above zero. This prevents everyone, including root, from modifying the file. At securelevel 2, the disk and memory devices are also read-only, to prevent doctoring that way.
This doesn't stop intruders from gaining root, but it can prevent them from trojaning everything and going invisible, or at least make it a hell of a lot harder.
The only way around it is to go to the console and bring the system to single-user mode. If some files or directories used in the boot sequence before the securelevel is raised aren't set immutable, it's often possible to modify them such that the securelevel will not be raised during the next reboot, so it's important to know what you're doing. Other than that, the only way for an intruder to trojan the system is to discover a bug in the kernel itself. There have been bugs found in the past, but they are much less plentiful than root exploits.
Program self checks (Score:1)
I have never seen an anti-piracy scheme that couldn't (read: hasn't) been cracked. There is no such thing.
Re:Criminals (Score:1)
Re:U.S. DoD/Military (off topic) (Score:1)
Good luck. Unless the branch of service you're interested in has an opening in the exact field you're interested in, don't exect to do it. Assuming you DO find an opening, do NOT enlist unless you've been guarenteed that position on papper. Recruiters will play bait-and-switch and they will lie.
Having said that... it doesn't mean you can't find interesting, rewarding jobs in the military. You might even get to do what you want to do. But your happiness in your job involves a combination of carefull planning and luck (and maybe a willingness to accept your second or third choice of careers).
Whatever you do, don't go in under an "open enlistment" (that is - no specified career field / position).
Again... good luck.
Helpful links (Score:3)
I'm realizing that something stupid like an obscene message on one of my stupid little web servers will probably get me in more trouble than a stealthy download of confidential files. Lock it all down. Only the paranoid survive.
Monty
Microsoft Excluded (Score:3)
Re:Securelevels (Re:super crack) (Score:2)
The only way to protect yourself against someone like this (apart from having no bugs in any of the software you run), is to have your disks shared with another (separated and highly secured) computer - preferable with only console access. Even then, a memory resident trojan can get you - does anyone know of any systems which have the system memory readable by another computer (without the intervention of the first CPU or any programmable hardware which can disable the feature). We are really getting into national security stuff here I think - in wich case the computer should be in a bunker with an army squadron to protect it
--
Re:Condemnation of the C-programming language (Score:1)
No, the reason you use C is because the development tools in Linux suck for any language exception C. (g++ sucked until recently too)
And the reason for that is the unusability of all languages other than C for system programming. Not to mention that all other commonly used languages are implemented in C, and implementations had their own security holes -- the "nicer" is the language, the larger are its implementation holes: perl had suid bugs in many versions, java crashes so much, it has to have some of that exploitable, etc.
Even C++ would be better than C, since a large majority of the buffer overflows are idiots using the stdio str*/mem* routines without supplying buffer lengths, or trying to code up their own collection routines (vector, list, tree, etc) c++ and STL would fix a lot of it. The fact is, C is not type safe. C++ offers more type-safety.
Yet after working in commercial software development I can testify that security bugs are abundant in C++ code, too.
Eiffel offers design-by-contract assertions which would prevent a lot of the buggy libraries that float around from causing security holes.
How?
And Java of course, is like chroot()ing your code, since it can't modify memory, disk, or network resources without specifically allowing it to.
This is irrelevant because program that does something useful must be allowed to do it anyway. But the main problem with java is its own bugginess, so one can never be sure if his program will be even running at the time when it will be necessary unless something is keeping an eye on it (=> DoS),and no one knows how many exploitable bugs are in Java implementations.
The fact is, all the of the reasons to use C don't apply to developing daemons and application level code. You could make an argument for sticking with C for kernel work. But as an application language, it's far too sloppy and dangerous.
Every other language is worse for most of purposes.
Also, bounds checking *doesn't* lead to a performance hit.
Sure it does.
Most modern compilers can remove the vast majority of bounds checks when optimizing
What are you smoking? Bounds checking code, once introduced can be optimized, yet the result will still produce enormous performance hit, especially considering that it should be performed at least once per array per function for every local variable.
, and with Eiffel, you can turn them off for a "production build", but leave them on while developing/debugging.
If they won't be there, how can they protect you from the attack? the whole point of attack is to create condition that never occured in development in testing, so it will be able to produce unexpected case of buffer overflow.
I'm sick of C hacks making the "speed" argument when they usually don't understand how to make things scalable anyway (HINT: it's not CPU in the vast majority of cases)
It *is* CPU -- if you look what is it comes down to in the end. Except, of course, in some braindead cases that no decent programmer should produce anyway. After problems of braindamaged communications with poorly-designed other software and inefficient libraries were solved, all my projects finally hit the limit of performance, imposed by CPU, what could be well proven by the results of profiling. And the only solution was to get a better compiler and faster box.
Hands off (Score:1)
Re:super crack (Score:1)
3. How about flashing their BIOS to load code off the hard drive (if needed) to modify the behavior of the copy of ssh on the floppy?
(Okay, this is tricky. You'd have to be familiar with the specific BIOS and floppy-based ssh version available, and doing it without a speed cut would be difficult. Nonetheless, it's similar, in a one-level-up sort of way, to the kernel modifications. If they could do that)...
Get a clue (Score:1)
With a securelevel of two (or even 1) you cannot read a module after the boot phase.
With a securelevel of two the kernel cannot be altered and even root cannot fiddle with disks and memory devices. Your are pretty sure your kernel is yours unless the machine is rebooted, but you could notice that. (Why the hell have I been disconnected ?)
Much more than 2% of servers (Score:1)
I wouldn't want begin to guess the percentage of vulnerable NT machines...
Impressive demo! (Score:1)
Do it in 8 seconds??? That's Incredible! (TM that old 70s (80s?) show by the same name)
I learned a fair amount reading this article, most specifically:
- Don't run anything you don't
- absolutely need! Like X.
I know that'll make things sometimes slower, and less pretty, but look at the alternative! 8 Seconds... DAMN!Re:Casing or something else? (Score:1)
Seems like they're not in the US, so I think you can skip the jail option. I don't mean to say that outside of the US you can't go to jail for cracking, but there should be a bit more damage done before legal action is taken, generally.
Geez, I liked the bit about the Aussie 486... Talk about a 'quick hack'...
I want to know! (Score:1)
Not impressed (Score:2)
Re:super crack (Score:3)
The second vulnerability was SSH. Someone altered the SSH client to act as a trojan. This should not be possible - programs should be able to detect if they've been modified. Failing that, a virus scanner should be able to detect modifications.
(Ideally, for an ultra-paranoid setup, the connection should be made via an IPIP tunnel, and connections refused from anything other than the correct end-point.)
Thirdly, how did they get hold of the ISP password? The article said SSH was cracked, but not that the dial-in software was. I assume they have thought of that. If not, the NT box and the ISP account are still wide open.
That the Linux kernel could be modified on-the-fly via a module is a serious security hole. That really needs to be fixed, urgently, IMHO.
Re:IDDN... (Score:1)
It seems to me that if we were able to implement this, the fact of its accomplishment would be much more than any law enforcement or legal agency would be able to cope with. Fait accompli.
So what would it take? How soon can we get it done?
Re:Program self checks (Score:2)
Re:super crack (Score:2)
Simple modifications would then be impossible, as the code is essentially encrypted.
More sophisticated modifications, which included altering the decryption to use an absolute value rather than a calculated one, would still fail, owing to the second, encrypted, decoder, which would be using an invalid checksum.
Very sophisticated attacks, which include decrypting the binary, modifying the second routine, and re-encrypting it using the new checksum would still work, but you're talking about something that is going to make -MAJOR- changes to a program, setting off every alarm on the machine.
For something like SSH, binary encryption is an absolute MUST.
Re:super crack (Score:2)
*SIGH* Clearly, someone who's NEVER played with self-modifying code. Why must I suffer this? Anyway, you have one routine in the clear, which XORs your binary with the checksum, or some function of the checksum. This unencrypts a second routine (but not the rest of the program), which does exactly the same, using the new checksum value, or function thereof. This, finally, decrypts the actual program itself.
Anyone can "break" the first check, but this leaves the rest of the program scrambled, and so useless. You can modify it to use an absolute value, sure, but if you do that, the second decrypt routine will use the wrong checksum value and the program will crash. Only by breaking BOTH encryption routines can you alter the code, but by then, tripwire and every other security scanner will be screaming. There's no way to break a double lock of that kind, without triggering every alarm on the machine.
Tunnel endpoints are to =TWO= IP addresses (physical and virtual). You can't simply move one end of a tunnel, like that. The end-point would be at the NT machine, and nothing could change that, short of breaking into the Linux box, which can't, then, be done without connecting through the NT machine. Overseas connections, of the kind that happened, CAN'T divert a tunnel.
Anyone paranoid enough to use SSH to connect to an ultra-secure Linux box is hardly likely to save their password on the computer! That's the -biggest- single NONO in standard security. NEVER, EVER write your password down, or keep a copy of it on a computer.
Re:super crack (Score:1)
Meanwhile, encrypted code is useless because the program has to start with...a decryptor! This is why, long ago when people compressed and scrambled executables with some PKzip product, it was so easy to decrypt them: to run itself, it needs the key and the decryption code...
Re:Condemnation of the C-programming language (Score:1)
Bounds checking can be used -- but:
Re:what id like to see.. (Score:1)
Re:.jp intrusion (Score:3)
Once inside, yes, KDE is going to listen, if it's running. X is a networked GUI, and any server that is active will listen to connections. If XDM(?) is running, that, too, will be listening for network connections.
KDE has almost certainly removed that buffer overflow, in more recent versions. If they haven't, they almost certainly will, soon. I think it's about as safe to install KDE as any other window manager. However, I -don't- advise leaving any window manager running, unless it's needed. They -are- complex pieces of software, and that means possibilities of bugs (memory leaks, etc) and security holes. If the computer is idly running a program that's a potential risk, for no reason but to put swirling patterns on a monitor that's turned off, you're better off with it shut down.
Re:FUD by any other name.. (Score:2)
1. It's assumed that everyone is extremely proficient with the doors. I bet you'd be surprised by the count of simple enough ways to crack the whole-metal, patended lock and all-that door you consider absolutely invulnerable. 'Real-world' criminals spend years studying constructions of doors and locks.
2. Of course it's essential for such an effort to ask the 'door' owner in advance or at least to provide them with test results. However, I didn't find anything stating that this hasn't been done. Obviously, they can't put the whole list online but after this article is published one can address them for security audit log, I believe. Of course one needs to prove his rights
Re:Not impressed (Score:2)
Re:Not impressed (Score:1)
CERT reports are useful, but people need a wake-up call to actually do something about them. This is a good first step, and some sort of automatic monitoring agency could well be a good second.
Rob Wilderspin
Re:Huge amount? (Score:1)