whitehat to test a security config
alex black
(never posted here before, only watched the announcements: if this
topic is inappropriate for this list I apologize in advance)
I'm looking for (preferably) a company, or individual, to attempt to
breach a standard config I have created to deploy client applications
in production. It is intentionally a minimal config which is tightly
locked down and audited daily.
I've never had a security incident with a machine I've managed with
debian (I (heart) debian), though I've seen plenty of ssh bruteforce
attempts and other script-kiddie and slightly more sophisticated
attacks - but never a skilled artisan really trying to get in ;)
I would provide:
-an IP address
-a username & password
I would want:
-an attack based on knowing the IP address _only_
-an attack knowing the IP + username & password I provide
-a report on findings, with a limited overview of techniques and tools
used.
Please send any questions & proposals to me off-list:
eni...@turingstudio.com
Please include "whitehat:" in the subject :)
thanks,
_alex
--
alex black, founder
the turing studio, inc.
510.666.0074
ro...@turingstudio.com
http://www.turingstudio.com
2600 10th street, suite 635
berkeley, ca 94710
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Alvin Oga
hi ya alex
On Mon, 31 Oct 2005, alex black wrote:
i'm gonna skip the offlist part and raise some questions/comments
just because it's a fun topic to cover and see other folks comments
and philosophy
- there will never be "one solution for 2-3 people" but will
be all different solutions maybe even totally different for each
> I would provide:
> -an IP address
> -a username & password
>
> I would want:
> -an attack based on knowing the IP address _only_
> -an attack knowing the IP + username & password I provide
> -a report on findings, with a limited overview of techniques and tools
> used.
lets start with "limited overview tools and techniques" for
general security issues ( applies to crackers and defenders )
top 25 security tools
http://www.insecure.org/tools.html
- top 20 security boo-boos
http://www.sans.org/top20/
if you have one of those "apps" in your project, you'd probably
want to read lot more about its problems and patches
- to break into a box ...
i'm guessing/claiming you want to use "exploit tools"
- and we'll save the otehr gazillion googleplex of other security options
to consider for later too
with your "white hat test scenario",
that will just show that say, a "generic person" cannot login
with uid/pwd ... fairly trivial to stop ... ( a "1 min" solution )
stopping ssh login, or using uid/pwd doesn't prevent others
from getting into your machines using some other vulnerability
and exploit tools designed to break into the boxes
- i guess i dont understand why knowing the uid/pwd is
important to know when doing a "security test", why use
that restriction for the "security tests"
script kiddies "tools" are just that, meant for the low lying fruits
due to the sheer number of machines out there for ez hits
----
questions for you
- what else is in the goals for the security test, where i'm not
using audit, pen-test, assessments and other "security words"
- what is the consequence if some whitehat/grayhat/blackhat/malicioushat
does get into the box, what is the process/proceedure/consequences
and follow up costs to cleanup vs shutdown/change the product line
c ya
alvin
Harry
> questions for you
>
> - what else is in the goals for the security test,
> where i'm not
> using audit, pen-test, assessments and other
> "security words"
>
> - what is the consequence if some
> whitehat/grayhat/blackhat/malicioushat
> does get into the box, what is the
> process/proceedure/consequences
> and follow up costs to cleanup vs shutdown/change
> the product line
Perhaps the following questions should be asked first
1. How do we know know Mr Black is who he says he is?
2. How can we confirm the machine details he supplies
are actually details of a machine that he owns?
3. How can I prove that he is not actually a skid
trying to learn how to crack a debian box (which he
has set up) so that he can then go on to crack some he
has ssh passwords to after successfully brute forcing
some on a network somewhere.
blah, blah, blah.
And for Mr Black.
1. How will you know that whoever replies to your
email isn't a lurking cracker. I am sure there are
plenty on this list considering the topic.
2. In the event that they are is the machine
sufficiently isolated that it being compromised will
not affect the rest of your or anyone elses network.
3. Do you have a procedure to wipe the machine after
the tests are done in a timely fashion. You asked for
a summary of what took place on the machine, perhaps
you should be monitoring the activity on the machine
yourself.
blah, blah, blah.
H.
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs
Alvin Oga
On Tue, 1 Nov 2005, Harry wrote:
> Perhaps the following questions should be asked first
>
> 1. How do we know know Mr Black is who he says he is?
> 2. How can we confirm the machine details he supplies
> are actually details of a machine that he owns?
... all valid points ..
- a face to face meeting is the only way to get
started on the "security test" per written contract
drawn by a lawyer and signed by the "board of directors"
- all else is asking to be tossed in the local
pen with the crazies
- even after the face to face meeting, and seeing the
machine to be tested, doesn't mean that after leaving,
that the "target" box is still where you saw last
/// paranoia is a good thing when doing some "supposedly"
/// not-so-legal activities as it depends on who's view
/// and who's authority that you got the "free get-out-of-jail-card"
- lots of fun ...
c ya
alvin
Rob Burgers
agreed these are all very good questions.
Naraki.
Bernd Eckenfels
> I'm looking for (preferably) a company, or individual, to attempt to
> breach a standard config I have created to deploy client applications
> in production. It is intentionally a minimal config which is tightly
> locked down and audited daily.
I think it is very bad efficiency to do black-box testing. Because it
requires a very good attacker and much time to find a problem. And if you
dont find one, you can't be shure you are secure. It is much better to let
the external auditor verify your configuration. Give them access to all
config files and documentation, your risk matrix etc. This is much cheaper
and much more sucessfull.
Gruss
Bernd
Javier Fernández-Sanguino Peña
> In article <5c69840f54112c46...@turingstudio.com> you wrote:
> > I'm looking for (preferably) a company, or individual, to attempt to
> > breach a standard config I have created to deploy client applications
> > in production. It is intentionally a minimal config which is tightly
> > locked down and audited daily.
>
> I think it is very bad efficiency to do black-box testing. Because it
> requires a very good attacker and much time to find a problem. And if you
> dont find one, you can't be shure you are secure. It is much better to let
> the external auditor verify your configuration. Give them access to all
> config files and documentation, your risk matrix etc. This is much cheaper
> and much more sucessfull.
(This is tarting to get off-topic)
You are in someway right: black-box testing does not give you as much
coverage of present vulnerabilities than a proper security review
But also somewhat wrong: a black-box test is much cheaper than a full
security audit of a system. The main difference is that lots of work in the
black-box tests are automated and lots of tools are available to do parts of
the job, while a full system security review, including even a source code
review if there are in-house applications, demands of more brains, skills and
time.
Regards
Javier
Bernd Eckenfels
> But also somewhat wrong: a black-box test is much cheaper than a full
> security audit of a system.
Well, I guess you mean "port scan". A Tiger Team who helps your security is
most often quite expensive cause it takes a lot of attacks - including
on-site social engeneering.
To run nessus you do not need to spend any money, thats right.