You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@solr.apache.org by "Davis, Daniel (NIH/NLM) [C]" <da...@nih.gov.INVALID> on 2022/02/16 16:28:09 UTC
Re: [EXTERNAL] Re: Vulnerability on solr port
If the port is proxied to something else, maybe by a load balancer, then disclosing the IP address in an HTTP header could be an issue. The scanner doesn't know whether the port is proxied elsewhere.
On 2/14/22, 8:29 AM, "matthew sporleder" <ms...@gmail.com> wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and are confident the content is safe.
So you scanned an internal IP address and somehow disclosed the
internal IP address?
On Mon, Feb 14, 2022 at 4:36 AM Anchal Sharma2 <an...@in.ibm.com> wrote:
>
> Hi All,
>
> We have got following vulnerability on port where apache solr is running on few of our servers .Does anyone have any ideas/suggestions on how to mitigate this ?
> Vulnerability -> Web Server HTTP Header Internal IP Disclosure 8983
>
> Thanks
> Anchal Sharma
Re: Vulnerability on solr port
Posted by Vincenzo D'Amore <v....@gmail.com>.
This also means that if Solr is reachable from the outside via reverse
proxy (this should never happen btw) the issue can be mitigated by
configuring the reverse proxy with the internal network Solr hostname
instead of the internal network ip address.
On Fri, Apr 8, 2022 at 8:42 AM Vincenzo D'Amore <v....@gmail.com> wrote:
> I agree that a relative redirect without the ip/hostname of the server,
> and not even the port should solve the security issue in a fairly simple
> way.
>
> Just another thing I tried to do a couple of calls by myself:
>
> curl -vv localhost:8983/
> 7 err
>
> < HTTP/1.1 302 Found
> < Location: http://localhost:8983/solr/
> < Transfer-Encoding: chunked
>
> curl -vv 127.0.0.1:8983/
> ok
>
> < HTTP/1.1 302 Found
> < Location: http://127.0.0.1:8983/solr/
> < Transfer-Encoding: chunked
>
> As you can see the answer contains the ip/host of the caller.
>
>
> On Fri, Apr 8, 2022 at 4:26 AM Gus Heck <gu...@gmail.com> wrote:
>
>> Are you assigning internal dns names to your solr servers? This possibly
>> will allow the redirect to use the internal dns name instead, likely
>> fooling the CVE checker program :) Just a thought on what to try if the
>> checker-runner folks are not understanding types.
>>
>> As noted by the above folks, simple proxy or direct access to your solr
>> server from the outside is not good, don't do it. The auth/security
>> features are typically used for internal security. Disclosing the internal
>> IP to a checker running on an internal network is fundamentally not a
>> risk,
>> because ANY computer on the internal network can look up the network
>> address based on a host name... that's what DNS is... So this would only
>> have meaning if the address crossed out of its home network. (at which
>> point mapping of the destination network from outsied is often considered
>> a
>> security risk).
>>
>> Finally, this redirect would not be a solr issue. It's Jetty code doing
>> the
>> redirect based on
>>
>> <!-- redirect root to solr -->
>> <Call name="addRule">
>> <Arg>
>> <New class="org.eclipse.jetty.rewrite.handler.RedirectRegexRule">
>> <Set name="regex">^/$</Set>
>> <Set name="location">/solr/</Set>
>> </New>
>> </Arg>
>> </Call>
>>
>>
>> -Gus
>>
>> On Thu, Apr 7, 2022 at 7:53 PM dmitri maziuk <dm...@gmail.com>
>> wrote:
>>
>> > On 2022-04-07 6:18 PM, matthew sporleder wrote:
>> > > Yes I agree the point of the "vulnerability" is that an http 1.0
>> request
>> > (does not require a Host header) will cause the origin to guess what it
>> > should put in the Location header. In some cases that guess is the ip of
>> > the server. In an http 1.1 or higher request the host header is used.
>> > >
>> > > I don't know what it has to do with IIS or Basic auth but that cve is
>> > very very old.
>> > >
>> > > I can't think of a way to return a redirect without violating this
>> > condition because iirc the http spec says Location headers need to be
>> fully
>> > qualified with protocol and host! That might not have applied in the
>> http
>> > 1.0 days though. (Although in practice many servers return just /paths)
>> >
>> > I think you can redirect to either absolute or relative URL, the problem
>> > is that relative URLs are really just paths within DocumentRoot -- no
>> > port number. I.e. you can't use them to redirect from :80 to :8983.
>> >
>> > I'm not sure what that CVE is really about either, there's just not
>> > enough detail there to make any sense. Authentication's kinda b0rk3d in
>> > IIS anyway; AFAIK auth returns a 401, not a redirect. Whereas a redirect
>> > to IP is perfectly fine when, as you say, server can't figure out what
>> > name to put in there. The "iformation disclosure" problem sounds like it
>> > came out of the knee-jerk security research team since if the host is
>> > reachable, then its IP address is known...
>> >
>> > Dima
>> >
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>
>
> --
> Vincenzo D'Amore
>
>
--
Vincenzo D'Amore
Re: Vulnerability on solr port
Posted by Vincenzo D'Amore <v....@gmail.com>.
I agree that a relative redirect without the ip/hostname of the server, and
not even the port should solve the security issue in a fairly simple way.
Just another thing I tried to do a couple of calls by myself:
curl -vv localhost:8983/
7 err
< HTTP/1.1 302 Found
< Location: http://localhost:8983/solr/
< Transfer-Encoding: chunked
curl -vv 127.0.0.1:8983/
ok
< HTTP/1.1 302 Found
< Location: http://127.0.0.1:8983/solr/
< Transfer-Encoding: chunked
As you can see the answer contains the ip/host of the caller.
On Fri, Apr 8, 2022 at 4:26 AM Gus Heck <gu...@gmail.com> wrote:
> Are you assigning internal dns names to your solr servers? This possibly
> will allow the redirect to use the internal dns name instead, likely
> fooling the CVE checker program :) Just a thought on what to try if the
> checker-runner folks are not understanding types.
>
> As noted by the above folks, simple proxy or direct access to your solr
> server from the outside is not good, don't do it. The auth/security
> features are typically used for internal security. Disclosing the internal
> IP to a checker running on an internal network is fundamentally not a risk,
> because ANY computer on the internal network can look up the network
> address based on a host name... that's what DNS is... So this would only
> have meaning if the address crossed out of its home network. (at which
> point mapping of the destination network from outsied is often considered a
> security risk).
>
> Finally, this redirect would not be a solr issue. It's Jetty code doing the
> redirect based on
>
> <!-- redirect root to solr -->
> <Call name="addRule">
> <Arg>
> <New class="org.eclipse.jetty.rewrite.handler.RedirectRegexRule">
> <Set name="regex">^/$</Set>
> <Set name="location">/solr/</Set>
> </New>
> </Arg>
> </Call>
>
>
> -Gus
>
> On Thu, Apr 7, 2022 at 7:53 PM dmitri maziuk <dm...@gmail.com>
> wrote:
>
> > On 2022-04-07 6:18 PM, matthew sporleder wrote:
> > > Yes I agree the point of the "vulnerability" is that an http 1.0
> request
> > (does not require a Host header) will cause the origin to guess what it
> > should put in the Location header. In some cases that guess is the ip of
> > the server. In an http 1.1 or higher request the host header is used.
> > >
> > > I don't know what it has to do with IIS or Basic auth but that cve is
> > very very old.
> > >
> > > I can't think of a way to return a redirect without violating this
> > condition because iirc the http spec says Location headers need to be
> fully
> > qualified with protocol and host! That might not have applied in the
> http
> > 1.0 days though. (Although in practice many servers return just /paths)
> >
> > I think you can redirect to either absolute or relative URL, the problem
> > is that relative URLs are really just paths within DocumentRoot -- no
> > port number. I.e. you can't use them to redirect from :80 to :8983.
> >
> > I'm not sure what that CVE is really about either, there's just not
> > enough detail there to make any sense. Authentication's kinda b0rk3d in
> > IIS anyway; AFAIK auth returns a 401, not a redirect. Whereas a redirect
> > to IP is perfectly fine when, as you say, server can't figure out what
> > name to put in there. The "iformation disclosure" problem sounds like it
> > came out of the knee-jerk security research team since if the host is
> > reachable, then its IP address is known...
> >
> > Dima
> >
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
--
Vincenzo D'Amore
Re: Vulnerability on solr port
Posted by Gus Heck <gu...@gmail.com>.
Are you assigning internal dns names to your solr servers? This possibly
will allow the redirect to use the internal dns name instead, likely
fooling the CVE checker program :) Just a thought on what to try if the
checker-runner folks are not understanding types.
As noted by the above folks, simple proxy or direct access to your solr
server from the outside is not good, don't do it. The auth/security
features are typically used for internal security. Disclosing the internal
IP to a checker running on an internal network is fundamentally not a risk,
because ANY computer on the internal network can look up the network
address based on a host name... that's what DNS is... So this would only
have meaning if the address crossed out of its home network. (at which
point mapping of the destination network from outsied is often considered a
security risk).
Finally, this redirect would not be a solr issue. It's Jetty code doing the
redirect based on
<!-- redirect root to solr -->
<Call name="addRule">
<Arg>
<New class="org.eclipse.jetty.rewrite.handler.RedirectRegexRule">
<Set name="regex">^/$</Set>
<Set name="location">/solr/</Set>
</New>
</Arg>
</Call>
-Gus
On Thu, Apr 7, 2022 at 7:53 PM dmitri maziuk <dm...@gmail.com>
wrote:
> On 2022-04-07 6:18 PM, matthew sporleder wrote:
> > Yes I agree the point of the "vulnerability" is that an http 1.0 request
> (does not require a Host header) will cause the origin to guess what it
> should put in the Location header. In some cases that guess is the ip of
> the server. In an http 1.1 or higher request the host header is used.
> >
> > I don't know what it has to do with IIS or Basic auth but that cve is
> very very old.
> >
> > I can't think of a way to return a redirect without violating this
> condition because iirc the http spec says Location headers need to be fully
> qualified with protocol and host! That might not have applied in the http
> 1.0 days though. (Although in practice many servers return just /paths)
>
> I think you can redirect to either absolute or relative URL, the problem
> is that relative URLs are really just paths within DocumentRoot -- no
> port number. I.e. you can't use them to redirect from :80 to :8983.
>
> I'm not sure what that CVE is really about either, there's just not
> enough detail there to make any sense. Authentication's kinda b0rk3d in
> IIS anyway; AFAIK auth returns a 401, not a redirect. Whereas a redirect
> to IP is perfectly fine when, as you say, server can't figure out what
> name to put in there. The "iformation disclosure" problem sounds like it
> came out of the knee-jerk security research team since if the host is
> reachable, then its IP address is known...
>
> Dima
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Vulnerability on solr port
Posted by dmitri maziuk <dm...@gmail.com>.
On 2022-04-07 6:18 PM, matthew sporleder wrote:
> Yes I agree the point of the "vulnerability" is that an http 1.0 request (does not require a Host header) will cause the origin to guess what it should put in the Location header. In some cases that guess is the ip of the server. In an http 1.1 or higher request the host header is used.
>
> I don't know what it has to do with IIS or Basic auth but that cve is very very old.
>
> I can't think of a way to return a redirect without violating this condition because iirc the http spec says Location headers need to be fully qualified with protocol and host! That might not have applied in the http 1.0 days though. (Although in practice many servers return just /paths)
I think you can redirect to either absolute or relative URL, the problem
is that relative URLs are really just paths within DocumentRoot -- no
port number. I.e. you can't use them to redirect from :80 to :8983.
I'm not sure what that CVE is really about either, there's just not
enough detail there to make any sense. Authentication's kinda b0rk3d in
IIS anyway; AFAIK auth returns a 401, not a redirect. Whereas a redirect
to IP is perfectly fine when, as you say, server can't figure out what
name to put in there. The "iformation disclosure" problem sounds like it
came out of the knee-jerk security research team since if the host is
reachable, then its IP address is known...
Dima
Re: Vulnerability on solr port
Posted by matthew sporleder <ms...@gmail.com>.
Yes I agree the point of the "vulnerability" is that an http 1.0 request (does not require a Host header) will cause the origin to guess what it should put in the Location header. In some cases that guess is the ip of the server. In an http 1.1 or higher request the host header is used.
I don't know what it has to do with IIS or Basic auth but that cve is very very old.
I can't think of a way to return a redirect without violating this condition because iirc the http spec says Location headers need to be fully qualified with protocol and host! That might not have applied in the http 1.0 days though. (Although in practice many servers return just /paths)
I tried to test this through my load balancer but did not get a solr IP address because I think the lb had fixed up the headers. (https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypassreverse)
imho this is a load balancer/proxy problem and not an origin problem.
Solr/jetty respects a host header. You could lock it down with jetty configs.
> On Apr 7, 2022, at 7:05 PM, Vincenzo D'Amore <v....@gmail.com> wrote:
>
> I don't think this is the point and I agree that Solr should not be
> accessible from the outside world but only from a restricted number of
> clients.
>
> So in my opinion, the OP was trying to explain that, for example, if you
> make an http call to solr through a reverse proxy (or a chain of) with the
> path / the answer is a 302 with the ip address of the original server.
>
>
>> On Thu, Apr 7, 2022 at 11:45 PM dmitri maziuk <dm...@gmail.com>
>> wrote:
>>
>>> On 2022-04-07 9:56 AM, Anchal Sharma2 wrote:
>>> Hi All,
>>>
>>> It took me a while to get the following information about the detected
>> vulnerability from the security team .
>> ...
>>
>> Maybe you should educate them about a vulnerability in the `ping`
>> command: if they ping your solr server by its name, it'll tell them the
>> server's ip address.
>>
>> Dima
>>
>>
>>
>
> --
> Vincenzo D'Amore
Re: Vulnerability on solr port
Posted by David Hastings <ha...@gmail.com>.
“IP address of the original server”
Is exactly the problem. A solr server doesn’t/shouldn’t have an up address
that exists outside of the internal network. So even if it didn’t get an
IP it would have no vulnerabilities since, it’s not a real ip. The only
people or machines that can touch ot are already on the network
On Thu, Apr 7, 2022 at 7:06 PM Vincenzo D'Amore <v....@gmail.com> wrote:
> I don't think this is the point and I agree that Solr should not be
> accessible from the outside world but only from a restricted number of
> clients.
>
> So in my opinion, the OP was trying to explain that, for example, if you
> make an http call to solr through a reverse proxy (or a chain of) with the
> path / the answer is a 302 with the ip address of the original server.
>
>
> On Thu, Apr 7, 2022 at 11:45 PM dmitri maziuk <dm...@gmail.com>
> wrote:
>
> > On 2022-04-07 9:56 AM, Anchal Sharma2 wrote:
> > > Hi All,
> > >
> > > It took me a while to get the following information about the detected
> > vulnerability from the security team .
> > ...
> >
> > Maybe you should educate them about a vulnerability in the `ping`
> > command: if they ping your solr server by its name, it'll tell them the
> > server's ip address.
> >
> > Dima
> >
> >
> >
>
> --
> Vincenzo D'Amore
>
Re: Vulnerability on solr port
Posted by Vincenzo D'Amore <v....@gmail.com>.
I don't think this is the point and I agree that Solr should not be
accessible from the outside world but only from a restricted number of
clients.
So in my opinion, the OP was trying to explain that, for example, if you
make an http call to solr through a reverse proxy (or a chain of) with the
path / the answer is a 302 with the ip address of the original server.
On Thu, Apr 7, 2022 at 11:45 PM dmitri maziuk <dm...@gmail.com>
wrote:
> On 2022-04-07 9:56 AM, Anchal Sharma2 wrote:
> > Hi All,
> >
> > It took me a while to get the following information about the detected
> vulnerability from the security team .
> ...
>
> Maybe you should educate them about a vulnerability in the `ping`
> command: if they ping your solr server by its name, it'll tell them the
> server's ip address.
>
> Dima
>
>
>
--
Vincenzo D'Amore
Re: Vulnerability on solr port
Posted by dmitri maziuk <dm...@gmail.com>.
On 2022-04-07 9:56 AM, Anchal Sharma2 wrote:
> Hi All,
>
> It took me a while to get the following information about the detected vulnerability from the security team .
...
Maybe you should educate them about a vulnerability in the `ping`
command: if they ping your solr server by its name, it'll tell them the
server's ip address.
Dima
Re: Vulnerability on solr port
Posted by David Hastings <ha...@gmail.com>.
Yes, this looks like an IIS problem. IIS is on version 10, "Current
Description . IIS 4.0 allows remote......"
there is no reason IIS 4.0 should be running, ever
On Thu, Apr 7, 2022 at 3:00 PM Jan Høydahl <ja...@cominvent.com> wrote:
> Hi,
>
> Solr is not a web server that is accessible to someone on the outside of
> your firewall.
> I.e. users on the outside will never issue requests direclty or indirectly
> directly to Solr, unless you have exposed the raw Solr server through a
> simple reverse proxy or similar, which is a big no-no.
> What happens when you request http://solr-ip:8983/ <http://solr-ip:8983/>
> is that there is no content there, so you get redirected to Solr's "webapp"
> on /solr/.
> The "Location: http..." is a Http 302 redirect message.
>
> Again, human users will never have direct access to Solr server, and if
> they do they are already on the inside of your network and already know
> Solr's IP address.
>
> Thus, this is not a vulnerability like it would perhaps be for an IIS
> server that is designed to be end-user facing.
>
> Jan
>
> > 7. apr. 2022 kl. 16:56 skrev Anchal Sharma2 <an...@in.ibm.com>:
> >
> > Hi All,
> >
> > It took me a while to get the following information about the detected
> vulnerability from the security team .The officially used security tool was
> able to exploit the issue using the following request :
> >
> > GET / HTTP/1.0
> > Accept-Charset: iso-8859-1,utf-8;q=0.9,*;q=0.1
> > Accept-Language: en
> > Connection: Close
> > User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
> Trident/4.0)
> > Pragma: no-cache
> > Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png,
> */*
> >
> >
> >
> >
> > This produced the following truncated output (limited to 10 lines) :
> > ------------------------------ snip ------------------------------
> > Location: http://<IP address>:8983/solr/
> >
> >
> > ------------------------------ snip ------------------------------
> >
> > The CVE number is CVE-2000-0649.
> https://nvd.nist.gov/vuln/detail/CVE-2000-0649 Can anyone suggest some
> fixes for the said vulnerability ?
> > NVD - CVE-2000-0649<https://nvd.nist.gov/vuln/detail/CVE-2000-0649>
> > Current Description . IIS 4.0 allows remote attackers to obtain the
> internal IP address of the server via an HTTP 1.0 request for a web page
> which is protected by basic authentication and has no realm defined.
> > nvd.nist.gov
> >
> > Thank you
> > Anchal Sharma
> > ________________________________
> > From: Davis, Daniel (NIH/NLM) [C] <da...@nih.gov.INVALID>
> > Sent: Wednesday, February 16, 2022 9:58 PM
> > To: users@solr.apache.org <us...@solr.apache.org>
> > Cc: solr-user <so...@lucene.apache.org>
> > Subject: Re: [EXTERNAL] Re: Vulnerability on solr port
> >
> > If the port is proxied to something else, maybe by a load balancer, then
> disclosing the IP address in an HTTP header could be an issue. The scanner
> doesn't know whether the port is proxied elsewhere.
> >
> > On 2/14/22, 8:29 AM, "matthew sporleder" <ms...@gmail.com> wrote:
> >
> > CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you recognize the sender and are
> confident the content is safe.
> >
> >
> > So you scanned an internal IP address and somehow disclosed the
> > internal IP address?
> >
> > On Mon, Feb 14, 2022 at 4:36 AM Anchal Sharma2 <an...@in.ibm.com>
> wrote:
> >>
> >> Hi All,
> >>
> >> We have got following vulnerability on port where apache solr is
> running on few of our servers .Does anyone have any ideas/suggestions on
> how to mitigate this ?
> >> Vulnerability -> Web Server HTTP Header Internal IP Disclosure 8983
> >>
> >> Thanks
> >> Anchal Sharma
> >
>
>
Re: Vulnerability on solr port
Posted by Jan Høydahl <ja...@cominvent.com>.
Hi,
Solr is not a web server that is accessible to someone on the outside of your firewall.
I.e. users on the outside will never issue requests direclty or indirectly directly to Solr, unless you have exposed the raw Solr server through a simple reverse proxy or similar, which is a big no-no.
What happens when you request http://solr-ip:8983/ <http://solr-ip:8983/> is that there is no content there, so you get redirected to Solr's "webapp" on /solr/.
The "Location: http..." is a Http 302 redirect message.
Again, human users will never have direct access to Solr server, and if they do they are already on the inside of your network and already know Solr's IP address.
Thus, this is not a vulnerability like it would perhaps be for an IIS server that is designed to be end-user facing.
Jan
> 7. apr. 2022 kl. 16:56 skrev Anchal Sharma2 <an...@in.ibm.com>:
>
> Hi All,
>
> It took me a while to get the following information about the detected vulnerability from the security team .The officially used security tool was able to exploit the issue using the following request :
>
> GET / HTTP/1.0
> Accept-Charset: iso-8859-1,utf-8;q=0.9,*;q=0.1
> Accept-Language: en
> Connection: Close
> User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
> Pragma: no-cache
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
>
>
>
>
> This produced the following truncated output (limited to 10 lines) :
> ------------------------------ snip ------------------------------
> Location: http://<IP address>:8983/solr/
>
>
> ------------------------------ snip ------------------------------
>
> The CVE number is CVE-2000-0649. https://nvd.nist.gov/vuln/detail/CVE-2000-0649 Can anyone suggest some fixes for the said vulnerability ?
> NVD - CVE-2000-0649<https://nvd.nist.gov/vuln/detail/CVE-2000-0649>
> Current Description . IIS 4.0 allows remote attackers to obtain the internal IP address of the server via an HTTP 1.0 request for a web page which is protected by basic authentication and has no realm defined.
> nvd.nist.gov
>
> Thank you
> Anchal Sharma
> ________________________________
> From: Davis, Daniel (NIH/NLM) [C] <da...@nih.gov.INVALID>
> Sent: Wednesday, February 16, 2022 9:58 PM
> To: users@solr.apache.org <us...@solr.apache.org>
> Cc: solr-user <so...@lucene.apache.org>
> Subject: Re: [EXTERNAL] Re: Vulnerability on solr port
>
> If the port is proxied to something else, maybe by a load balancer, then disclosing the IP address in an HTTP header could be an issue. The scanner doesn't know whether the port is proxied elsewhere.
>
> On 2/14/22, 8:29 AM, "matthew sporleder" <ms...@gmail.com> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and are confident the content is safe.
>
>
> So you scanned an internal IP address and somehow disclosed the
> internal IP address?
>
> On Mon, Feb 14, 2022 at 4:36 AM Anchal Sharma2 <an...@in.ibm.com> wrote:
>>
>> Hi All,
>>
>> We have got following vulnerability on port where apache solr is running on few of our servers .Does anyone have any ideas/suggestions on how to mitigate this ?
>> Vulnerability -> Web Server HTTP Header Internal IP Disclosure 8983
>>
>> Thanks
>> Anchal Sharma
>
Re: Vulnerability on solr port
Posted by Shawn Heisey <ap...@elyograg.org>.
On 4/7/2022 8:56 AM, Anchal Sharma2 wrote:
> The CVE number is CVE-2000-0649. https://nvd.nist.gov/vuln/detail/CVE-2000-0649 Can anyone suggest some fixes for the said vulnerability ?
> NVD - CVE-2000-0649<https://nvd.nist.gov/vuln/detail/CVE-2000-0649>
> Current Description . IIS 4.0 allows remote attackers to obtain the internal IP address of the server via an HTTP 1.0 request for a web page which is protected by basic authentication and has no realm defined
If anybody who is not clearly authorized can make a network connection
to your Solr server, then you've failed the most basic security
recommendation we can make: Do not allow network connections from
people and applications that are not authorized to use that Solr
install. I would go further, and say that Solr should never be exposed
to the open Internet, whether it is protected by encryption and
authentication or not.
If somebody compromises one of your other machines, then they most
likely already have the internal IP address for the Solr machine,
because the address or name of the Solr server will be in the
application configuration, and from a name, they can get an IP address.
So ... if you follow recommendations, this vulnerability is only
exploitable by someone who has already broken your security and already
has the information that could be disclosed.
Thanks,
Shawn
RE: Vulnerability on solr port
Posted by Anchal Sharma2 <an...@in.ibm.com>.
Hi All,
It took me a while to get the following information about the detected vulnerability from the security team .The officially used security tool was able to exploit the issue using the following request :
GET / HTTP/1.0
Accept-Charset: iso-8859-1,utf-8;q=0.9,*;q=0.1
Accept-Language: en
Connection: Close
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
This produced the following truncated output (limited to 10 lines) :
------------------------------ snip ------------------------------
Location: http://<IP address>:8983/solr/
------------------------------ snip ------------------------------
The CVE number is CVE-2000-0649. https://nvd.nist.gov/vuln/detail/CVE-2000-0649 Can anyone suggest some fixes for the said vulnerability ?
NVD - CVE-2000-0649<https://nvd.nist.gov/vuln/detail/CVE-2000-0649>
Current Description . IIS 4.0 allows remote attackers to obtain the internal IP address of the server via an HTTP 1.0 request for a web page which is protected by basic authentication and has no realm defined.
nvd.nist.gov
Thank you
Anchal Sharma
________________________________
From: Davis, Daniel (NIH/NLM) [C] <da...@nih.gov.INVALID>
Sent: Wednesday, February 16, 2022 9:58 PM
To: users@solr.apache.org <us...@solr.apache.org>
Cc: solr-user <so...@lucene.apache.org>
Subject: Re: [EXTERNAL] Re: Vulnerability on solr port
If the port is proxied to something else, maybe by a load balancer, then disclosing the IP address in an HTTP header could be an issue. The scanner doesn't know whether the port is proxied elsewhere.
On 2/14/22, 8:29 AM, "matthew sporleder" <ms...@gmail.com> wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and are confident the content is safe.
So you scanned an internal IP address and somehow disclosed the
internal IP address?
On Mon, Feb 14, 2022 at 4:36 AM Anchal Sharma2 <an...@in.ibm.com> wrote:
>
> Hi All,
>
> We have got following vulnerability on port where apache solr is running on few of our servers .Does anyone have any ideas/suggestions on how to mitigate this ?
> Vulnerability -> Web Server HTTP Header Internal IP Disclosure 8983
>
> Thanks
> Anchal Sharma