[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] Links for tutorials on false positives
- From: Joshua Thomas <mr.omnipresent@xxxxxxxxx>
- Subject: Re: [WEB SECURITY] Links for tutorials on false positives
- Date: Mon, 30 Nov 2009 17:23:07 +0530
--001485ec01f9ec724b04799548ce
Content-Type: text/plain; charset=ISO-8859-1
Hello Sutapa,
Ideally when we run any tool (AppSec/ InfraSec) results are generated. Now
there can be 3 cases -
1. Actual vulnerabilities - The ones which are really there is reported by
the tool ( POSITIVES)
2. Unreal vulnerabilities - The ones which are reported but are not there
(FALSE POSITIVES)
3. Un-FOUND vulnerabilities - The ones which are not reported but they do
exist (FALSE NEGATIVES)
Now, to identify which are real and/ or real but not reported the only way
is to MANUALLY VERIFY. This process ranges from simple tests to
complicated.
[I am not sure if you will find all the tutorials, documents revealing how
these tests are to be performed since it comes from knowledge of the entity
you are scanning... i.e., (Example)
a> AppSec - Let's say your tool found a XSS (Cross site scripting). Now what
you could do is go to the link reported by the tool and try tampering the
parameter to inject the script, or code (as applicable) to validate if it
is real
b>InfraSec - Let say you tool reports Anonymous FTP with write able
permissions - Now what you have to do is to manually launch the FTP client
and check if it accepts anonymous logins and if you could upload/ write/
delete any file on that server
]
Now here is one POINTER - While Validating some of these vulnerabilities,
you might un-intentionally change/ affect the Integrity, Availability or
Reliability of the entity. So those case in which you think which it could
affect the above mentioned CIARs (Confi, Integrity, Availability and
Reliability) you might want to get a approval from the client if you are
allowed to perform such testing (Exploitation activities). So what you can
do is mark those as PROBABLE VULNERABILITIES and ask for confirmation.
EXAMPLE (Vulnerability in Plug and Play Service Could Allow Remote Code
Execution (Microsoft ID: MS05-039) was reported by your tool on IP
X1.X2.X3.X4 ... Now you report that this vulnerability might be present and
it could be false positive and ask the client to confirm if this can be
tested. Once you get the confirmation here are the things you could do for
starters -
1. Note down the BUGTRAQ ID, CVE ID, or any ID (ID= Security identifier) and
google if this can be exploited. Security Focus, Packetstorm, milw0rm
provides some sort of exploitation code which you could leverage for this
activity (**CAUTION** SOME OF THESE CODES ARE Proof-Of-Concepts, and can
affect Availability of the service/ server i.e., could lead to Denial of
Service... This you should not test unless explicitly suggested by Client.
Try to evaluate the Risk of such activity before proceeding since these
entities might be in a production environment)
2. Every vulnerability scanning tool has some sort of engine, plugins,
modules - so for mid-level users I would suggest you analyse these modules
and plugins for how these vulnerabilities are reported and identified. Not
only you would learn lot of techniques but you might end up write some
customized code of your own.
3. Advanced - (RESEARCH PURPOSE ONLY) - you could replicated these entities
in Virtual environments and attach debuggers and try how these services/
process (vulnerable ones) react to different inputs (networked/ locally/
calls) and try writing you own exploit codes (POC/ Shell etc)
For client service purpose 1 & 2 is applicable since there would be time
limits for these kind of engagements. 3 would be for specialized usage or
personal/ educational/ research purposes ONLY
>From the steps 1 & 2 you would be able to identify/ verify False Positives
and Positives. For identifying False Negatives some experience is required
(from Step 3 kind of activities or previous experiences)
Hope this helps. Feel free to shoot out to all of us if you have some
specific vulnerabilities in mind, since this group consists of some really
brilliant white-hats
Best Wishes
Joshua
P.S It's an art .. So try to be creative and artistic :)
--001485ec01f9ec724b04799548ce
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello Sutapa,=A0<div><br></div><div>Ideally when we run any tool (AppSec/ I=
nfraSec) results are generated. Now there can be 3 cases -</div><div>1. Act=
ual vulnerabilities - The ones which are really there is reported by the to=
ol ( POSITIVES)</div>
<div>2. Unreal vulnerabilities - The ones which are reported but are not th=
ere (FALSE POSITIVES)</div><div>3. Un-FOUND vulnerabilities - The ones whic=
h are not reported but they do exist (FALSE NEGATIVES)</div><div><br></div>
<div>Now, to identify which are real and/ or real but not reported the only=
way is to MANUALLY VERIFY. This process ranges from simple tests to compli=
cated.=A0</div><div>[I am not sure if you will find all the tutorials, docu=
ments revealing how these tests are to be performed since it comes from kno=
wledge of the entity you are scanning... i.e., (Example)=A0</div>
<div>a> AppSec - Let's say your tool found a XSS (Cross site scripti=
ng). Now what you could do is go to the link reported by the tool and try t=
ampering the parameter to =A0inject the script, or code (as applicable) to =
validate if it is real</div>
<div>b>InfraSec - Let say you tool reports Anonymous FTP with write able=
permissions - Now what you have to do is to manually launch the FTP client=
and check if it accepts anonymous logins and if you could upload/ write/ d=
elete any file on that server</div>
<div>]</div><div><br></div><div>Now here is one POINTER - While Validating =
some of these vulnerabilities, you might un-intentionally change/ affect th=
e Integrity, Availability or Reliability of the entity. So those case in wh=
ich you think which it could affect the above mentioned CIARs (Confi, Integ=
rity, Availability and Reliability) you might want to get a approval from t=
he client if you are allowed to perform such testing (Exploitation activiti=
es). So what you can do is mark those as PROBABLE VULNERABILITIES and ask f=
or confirmation.=A0</div>
<div><br></div><div>EXAMPLE (Vulnerability in Plug and Play Service Could A=
llow Remote Code Execution (Microsoft ID: MS05-039) was reported by your to=
ol on IP X1.X2.X3.X4 ... Now you report that this vulnerability might be pr=
esent and it could be false positive and ask the client to confirm if this =
can be tested. Once you get the confirmation here are the things you could =
do for starters -=A0</div>
<div><br></div><div>1. Note down the BUGTRAQ ID, CVE ID, or any ID (ID=3D S=
ecurity identifier) and google if this can be exploited. Security Focus, Pa=
cketstorm, milw0rm provides some sort of exploitation code which you could =
leverage for this activity (**CAUTION** SOME OF THESE CODES ARE Proof-Of-Co=
ncepts, and can affect Availability of the service/ server i.e., could lead=
to Denial of Service... This you should not test unless explicitly suggest=
ed by Client. Try to evaluate the Risk of such activity before proceeding s=
ince these entities might be in a production environment)</div>
<div><br></div><div>2. Every vulnerability scanning tool has some sort of e=
ngine, plugins, modules - so for mid-level users I would suggest you analys=
e these modules and plugins for how these vulnerabilities are reported and =
identified. Not only you would learn lot of techniques but you might end up=
write some customized code of your own.</div>
<div><br></div><div>3. Advanced - (RESEARCH PURPOSE ONLY) - you could repli=
cated these entities in Virtual environments and attach debuggers and try h=
ow these services/ process (vulnerable ones) react to different inputs (net=
worked/ locally/ calls) and try writing you own exploit codes (POC/ Shell e=
tc)</div>
<div><br></div><div><br></div><div>For client service purpose 1 & 2 is =
applicable since there would be time limits for these kind of engagements. =
3 would be for specialized usage or personal/ educational/ research purpose=
s ONLY</div>
<div><br></div><div>From the steps 1 & 2 you would be able to identify/=
verify False Positives and Positives. For identifying False Negatives some=
experience is required (from Step 3 kind of activities or=A0previous exper=
iences)</div>
<div><br></div><div><br></div><div>Hope this helps. Feel free to shoot out =
to all of us if you have some specific vulnerabilities in mind, since this =
group consists of some really brilliant white-hats =A0</div><div><br></div>
<div><br></div><div>Best Wishes=A0</div><div>Joshua</div><div><br></div><di=
v><br></div><div><br></div><div>P.S It's an art .. So try to be creativ=
e and artistic :)=A0</div><div><br></div><div><br></div>
--001485ec01f9ec724b04799548ce--
Brought to you by http://www.webappsec.org
Search this site
|