> We had one optional (extra credit) section on a network prac that involved
> hacking various computers around the university.
> Questions included getting a login prompt on the admin's server (IP
> restricted), modifying the Journ dept's website and obtaining a file from
> one of the Comp Sci lecturer's PCs

Most of what we did was totally outside any lectures or classes ;-)

The one that took most thought was the "round of applause" I made.  On the 
network drive there were some example sound files, one was a round of 
applause that lasted for like 10 seconds.  I thought about how cool it would 
be if all the computers in the computer room played this at once.  In the 
end I put a program on the shared work drive (that everyone opened to load 
example work etc) that loaded automatically and sat in the background.  It 
then constantly checked the presence of that program on the network drive, 
and as soon as it had gone it started a 5 minute countdown timer before 
playing that sound sample 10 times and then exiting.  Then all I had to do 
was delete the program from the network drive during the lesson and wait for 
the result :-D

Post a reply to this message

"Orchid XP v8" <voi### [at] devnull> wrote in message 
news:4829f767$1@news.povray.org...

 [It wasn't in the exam, so I cannot *imagine* anybody bothered
> to actually look it up. Except me, anyway. I had great fun breaking all my 
> classmate's web sites...]

    Lol, owned! :)

    ~Steve~


>
> -- 
> http://blog.orphi.me.uk/
> http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:

> Well, here's a question for you. Other than very generic advice like 
> "don't use predictable secrets" and "don't execute code from untrusted 
> users" (which really covers a lot more than you may think), what would 
> you teach?

How about

   Rule #1: You will NOT "add security later". It doesn't workt that way.

If more people understood that, things would be *so* much better! Too 
many people think "security" is just something you can buy in a box and 
install as a seperate item. It isn't.

Of similar signifigance,

   Rule #2: People WILL try to circumvent security if it inconviniences 
them too much.

After that we get into smaller details, such as

   Rule #3: Any user-supplied data should be thoroughly checked before 
use. [For reliability as much as security.]

   Rule #4: Treat network data with suspicion unless you are absolutely 
sure where it came from.

and so forth.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

"scott" <sco### [at] scottcom> wrote in message
news:482aa252$1@news.povray.org...
> > We had one optional (extra credit) section on a network prac that
involved
> > hacking various computers around the university.
> > Questions included getting a login prompt on the admin's server (IP
> > restricted), modifying the Journ dept's website and obtaining a file
from
> > one of the Comp Sci lecturer's PCs
>
> Most of what we did was totally outside any lectures or classes ;-)

So was ours. This was just the 'official' hacking portion. I did my fair
share of unofficial, as did a lot of others.

The best was when we (admins and comittee for the university computer users
society) caught 3 lusers trying to do an NTNuke on a local ISP's site.
Firstly, the ISP was running some flavour of unix (don't remember which) so
the NTNuke had no effect.
Best was that the lusers didn't wipe their command history file before
logging out.

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message
news:482a2219$1@news.povray.org...
>
> What sorts of stuff would you teach?  Basic firewall and
> SQL-injection-prevention stuff? Something more?
>

In addition to Andrews Rule 1 and 2... (and note that I am not an expert in
security by any means)

The importance of good error checking, handling and reporting. Way too many
hacks are possible because the program does something unexpected in an error
condition (buffer overflow) or reports far too much info to users in the
case of an error.

Password and key management. Possibly covered by your 'don't use predictable
secrets'. Emphasis on how hard this really is to do properly.

Don't trust user input. A subset of your "don't execute code from untrusted
users" This covers SQL injection, XSS, buffer overflows and probably more.

Use the principle of least permissions. The picture editing software does
not need admin rights on the machine. The web app does not need to connect
to the db server as sysadmin.

Defend in depth. Always check multiple times at different levels. Assume
that the level above has been compromised. Similarly, harden the OS you're
running on. A secure app on a vulnerable OS is like a castle on wet sand.

Always work on the assumption that you will be hacked and that the hacker
knows your system. Security through obscurity doesn't work, and hoping you
won't be hacked is a poor defense

It's scary how little some know. I was at a local MS event last year and the
speaker (who is a security guru) was showing off some simple exploits. From
the response of the audience, I would guess a large portion had never seen
buffer overflow working before, and this was a room of several hundred, all
IT people, most professional developers.

Post a reply to this message

Gail Shaw wrote:
> 
> In addition to Andrews Rule 1 and 2... (and note that I am not an expert in
> security by any means)
> 
> The importance of good error checking, handling and reporting. Way too many
> hacks are possible because the program does something unexpected in an error
> condition (buffer overflow) or reports far too much info to users in the
> case of an error.
> 
> Password and key management. Possibly covered by your 'don't use predictable
> secrets'. Emphasis on how hard this really is to do properly.
> 
> Don't trust user input. A subset of your "don't execute code from untrusted
> users" This covers SQL injection, XSS, buffer overflows and probably more.
> 
> Use the principle of least permissions. The picture editing software does
> not need admin rights on the machine. The web app does not need to connect
> to the db server as sysadmin.
> 
> Defend in depth. Always check multiple times at different levels. Assume
> that the level above has been compromised. Similarly, harden the OS you're
> running on. A secure app on a vulnerable OS is like a castle on wet sand.
> 
> Always work on the assumption that you will be hacked and that the hacker
> knows your system. Security through obscurity doesn't work, and hoping you
> won't be hacked is a poor defense
> 
> It's scary how little some know. I was at a local MS event last year and the
> speaker (who is a security guru) was showing off some simple exploits. From
> the response of the audience, I would guess a large portion had never seen
> buffer overflow working before, and this was a room of several hundred, all
> IT people, most professional developers.
> 
> 
 I was about to post a similar reply; here's a snippet of it:

Client-side security doesn’t work.
You cannot securely exchange encryption keys without a shared piece of
information.
Malicious code cannot be 100 percent protected against.
Any malicious code can be completely morphed to bypass signature detection.
Firewalls cannot protect you 100 percent from attack.
Any intrusion detection system can be evaded.
Secret cryptographic algorithms are not secure.
If a key isn’t required, you do not have encryption—you have encoding.
Passwords cannot be securely stored on the client unless there is
another password to protect them.
In order for a system to begin to be considered secure, it must undergo
an independent security audit.
Security through obscurity does not work.

John

-- 
I will be brief but not nearly so brief as Salvador Dali, who gave the
world's shortest speech. He said, "I will be so brief I am already
finished," then he sat down.

Post a reply to this message

Doctor John wrote:
> You cannot securely exchange encryption keys without a shared piece of
> information.

Isn't think what public key encryption is all about? I mean, this is 
basic Diffie Helman.

I think you probably mean something slightly different, which would be 
"you can't be sure who you're talking to without a shared piece of 
information."

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Doctor John wrote:
> Client-side security doesn’t work.
> You cannot securely exchange encryption keys without a shared piece of
> information.
> Malicious code cannot be 100 percent protected against.
> Any malicious code can be completely morphed to bypass signature
> detection. Firewalls cannot protect you 100 percent from attack.
> Any intrusion detection system can be evaded.
> Secret cryptographic algorithms are not secure.
> If a key isn’t required, you do not have encryption—you have encoding.
> Passwords cannot be securely stored on the client unless there is
> another password to protect them.
> In order for a system to begin to be considered secure, it must undergo
> an independent security audit.
> Security through obscurity does not work.

Don't modify code you don't understand, particularly if it's
security-related?

http://www.debian.org/security/2008/dsa-1571
http://www.links.org/?p=327
http://www.links.org/?p=328

Post a reply to this message

Darren New wrote:
> Doctor John wrote:
>> You cannot securely exchange encryption keys without a shared piece of
>> information.
> 
> Isn't think what public key encryption is all about? I mean, this is
> basic Diffie Helman.
> 
> I think you probably mean something slightly different, which would be
> "you can't be sure who you're talking to without a shared piece of
> information."
> 
Umm, yeah. What I meant was exactly what you said. Thanx for the correction.

John

-- 
I will be brief but not nearly so brief as Salvador Dali, who gave the
world's shortest speech. He said, "I will be so brief I am already
finished," then he sat down.

Post a reply to this message

Nicolas Alvarez wrote:

> Don't modify code you don't understand, particularly if it's
> security-related?

+847!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message