Nessus Scan Report

358 views
Skip to first unread message

icecolor

unread,
Aug 3, 2011, 7:06:36 PM8/3/11
to Jenkins Developers
I am trying to get Jenkins approved for use in our organization. Our
security team ran Nessus and found a couple of problems that they want
me to get remediated to get Jenkins approved for use. Can you please
comment on these two vulnerabilities?

Web Server Uses Plain Text Authentication Forms
====================================================================
Synopsis:The remote web server might transmit credentials in
cleartext.Description:The remote web server contains several HTML form
fields containing
an input of type 'password' which transmit their information to
a remote web server in cleartext.

An attacker eavesdropping the traffic between web browser and
server may obtain logins and passwords of valid users.Risk
factor:MediumCVSS Base Score:5.0CVSS2#AV:N/AC:L/Au:N/C:P/I:N/
A:NSolution:Make sure that every sensitive form transmits content over
HTTPS
Page : /builds
Destination page :
Input name : j_password


Page : /computer/
Destination page :
Input name : j_password


Page : /job/SampleCProgram/
Destination page :
Input name : j_password

Plugin ID:26194Other references: CWE:522, CWE:523, CWE:718, CWE:724


Port www (8080/tcp) [-/+]
Web Server Generic XSS
======================================================================

Synopsis:The remote web server is prone to cross-site scripting
attacks.Description:The remote host is running a web server that fails
to adequately
sanitize request strings of malicious JavaScript. By leveraging this
issue, an attacker may be able to cause arbitrary HTML and script code
to be executed in a user's browser within the security context of the
affected site.Risk factor:MediumCVSS Base Score:4.3CVSS2#AV:N/AC:M/
Au:N/C:N/I:P/A:NSee also:http://en.wikipedia.org/wiki/Cross-
site_scriptingSolution:Contact the vendor for a patch or
upgrade.Plugin output:
The request string used to detect this flaw was :

<script>cross_site_scripting.nasl</script>

The output was :

HTTP/1.1 400 Bad Request
Server: Winstone Servlet Engine v0.9.10
Content-Length: 334
Connection: Close
Content-Type: text/html;charset=ISO-8859-1
Date: Fri, 20 May 2011 18:21:07 GMT
X-Powered-By: Servlet/2.5 (Winstone/0.9.10)


<html><head><title>Error 400</title></head><body
bgcolor="#ffffff"><h1>S
tatus Code: 400</h1>Exception: URI must start with a slash:
<script>cros
s_site_scripting.nasl</script><br>Stacktrace: <pre>(none)
</pre><br><hr size="1" width="90%"><i>Generated by Winstone Servle
[...]

Plugin ID:10815CVE: CVE-2002-1700, CVE-2003-1543, CVE-2005-2453,
CVE-2006-1681BID: 5011, 5305, 7344, 7353, 8037, 14473, 17408Other
references: OSVDB:18525, OSVDB:24469, OSVDB:42314, OSVDB:4989, OSVDB:
58976, CWE:79, CWE:80, CWE:81, CWE:83, CWE:20, CWE:74, CWE:442, CWE:
712, CWE:722, CWE:725, CWE:811, CWE:751, CWE:801, CWE:116

Ben Castellucci

unread,
Aug 3, 2011, 7:16:23 PM8/3/11
to jenkin...@googlegroups.com

The first is easy - read up on winstone (i.e. google it) and configure SSL support OR (much easier in my opinion and far more robust) deploy jenkins.war in your own secured servlet container.

Not so sure about the second one - I'll defer to others in the group on that, especially since there have been many past discussions on this very thing (search this group for such past discussions).

Thanks,
Ben

Sent from my Android phone.

Stephen Connolly

unread,
Aug 3, 2011, 8:01:51 PM8/3/11
to jenkin...@googlegroups.com
On 4 August 2011 00:16, Ben Castellucci <ben...@gmail.com> wrote:
> The first is easy - read up on winstone (i.e. google it) and configure SSL
> support OR (much easier in my opinion and far more robust) deploy
> jenkins.war in your own secured servlet container.

The login password fields are determined by the authentication plugin
you use, so in a sense this is pluggable anyway, if somebody took the
time to write a SPNEGO security realm you'd have no password field at
all.

>
> Not so sure about the second one - I'll defer to others in the group on
> that, especially since there have been many past discussions on this very
> thing (search this group for such past discussions).
>

Use a different markup formatter, e.g.
http://www.cloudbees.com/jenkins-nectar-features-wiki.cb (ho hum...
yes I know that is pimping our commercial version)

Bap

unread,
Aug 4, 2011, 6:51:49 AM8/4/11
to jenkin...@googlegroups.com
Quoting Stephen Connolly <stephen.al...@gmail.com>:

> On 4 August 2011 00:16, Ben Castellucci <ben...@gmail.com> wrote:
>> The first is easy - read up on winstone (i.e. google it) and configure SSL
>> support OR (much easier in my opinion and far more robust) deploy
>> jenkins.war in your own secured servlet container.
>
> The login password fields are determined by the authentication plugin
> you use, so in a sense this is pluggable anyway, if somebody took the
> time to write a SPNEGO security realm you'd have no password field at
> all.
>
>>
>> Not so sure about the second one - I'll defer to others in the group on
>> that, especially since there have been many past discussions on this very
>> thing (search this group for such past discussions).
>>
>
> Use a different markup formatter, e.g.
> http://www.cloudbees.com/jenkins-nectar-features-wiki.cb (ho hum...
> yes I know that is pimping our commercial version)
>

There are 2 free formatters available for Jenkins which will prevent
users from directly entering HTML into the page

1. Use Markdown with the [PegDown Formatter Plugin] [1] and enable the
"SUPPRESS_ALL_HTML" option to strip all HTML elements from the Markdown.
Links, images, lists, tables, emphasis, etc., can all be added
safely using Markdown.
2. Use the [Escaped Markup Plugin] [2] which will escape all HTML in
the descriptions.

[1]: https://wiki.jenkins-ci.org/display/JENKINS/PegDown+Formatter+Plugin
[2]: https://wiki.jenkins-ci.org/display/JENKINS/Escaped+Markup+Plugin

Bap.

Reply all
Reply to author
Forward
0 new messages