7 Replies Latest reply on Jan 13, 2020 3:56 PM by Joerg.Sobottka

    CVE-2012-1675: Listener vulnerability question

    user13254045

      Good morning,

       

      We have found out a vulnerability through listener with some programs like nmap. As you can see bellow, running it we can see listener port and database version, which could be a big problem for our customer:

       

      .\nmap.exe -p0- -v -A -T4 WIN-9H8TGULUPL1

      1521/tcp open oracle-tns Oracle TNS listener 1.3.0.0.0 (unauthorized)

       

      (only show 1, not 19, but it could be enough to have an attack)

       

      .\nmap.exe -p0- -v -A -T4 vmNGF2

      1521/tcp open oracle-tns Oracle TNS listener 12.2.0.1.0 (unauthorized)

       

      .\nmap.exe -p0- -v -A -T4 vmNGF2

      1523/tcp open oracle-tns Oracle TNS listener 12.2.0.1.0 (unauthorized)

       

      We have checked this error since 10g version to 19c.

       

      How we could restrict that information? I have already tested updating listener port, but we have same problem. Furthermore, we have update VALID_NODE_CHECKING_REGISTRATION_<listener_name> = ON but problem still happens.

       

      If it helps, we're following OWASP 4 testing guide.

       

      Thanks in advance.

      Best regards

        • 1. Re: CVE-2012-1675: Listener vulnerability question
          Joerg.Sobottka

          Well, you need an open port to establish the communication to the database. 1521 is default, you can change that to something else, but then you will find the new port "open".

          If the port is closed, no application would be able to connect to the database.

           

          If you do have an Enterprise Edition database, you could hide your database behind a connection manager proxy and close the ports from all other hosts at your firewall.

          • 2. Re: CVE-2012-1675: Listener vulnerability question
            user13254045

            Good afternoon,

            As you told before, I have the same issue changing the port.

             

            We don`t have enterprise and each customer has its own server with their databases, so I need a general workaround. In that scenario, customer manages his firewall, proxy... so I would like find out an Oracle solution.

             

            I will wait and see if anyone can help.

             

            Thanks a lot for your help.

            Best regards.

            • 3. Re: CVE-2012-1675: Listener vulnerability question
              Joerg.Sobottka

              As I said, you need open ports, otherwise the applications can't connect.

               

              What do you want to see? That nmap tolds you, the port is closed? That will not happen - or the applications are "death"....

              • 4. Re: CVE-2012-1675: Listener vulnerability question
                user13254045

                My fear is that through this kind of application (nmap shows port, Oracle version...), someone shows our version and knows its vulnerabilities, which could put the information at risk.

                I want to avoid get this kind of information outside the server.

                • 5. Re: CVE-2012-1675: Listener vulnerability question
                  pmdba

                  Connection Manager is distributed with the Oracle Client; it does not require Enterprise Edition to my knowledge. There's a paper here on how to configure it (written for 11g, but still works with 12c).

                   

                  That said, from what perspective was nmap run? From a trusted host on the local network with the server, or from an external host outside of the server's "circle of trust"? In other words, what is an attacker most likely to see? This is about managing risk, so if the server's ports are generally protected by firewalls from outside access, then I wouldn't worry as much about nmap output from a trusted client. If the server is going to be exposed completely (BAD IDEA!), then I would configure the local OS firewall to block all traffic to that port except from trusted clients, like known application servers. In the end I think the only way to manage this is with a networking solution; I don't believe there's an option available in the Listener configuration to suppress that information from being returned.

                   

                  One other thing: nmap and other scanners often leave distinctive traces in the listener logs. You should be monitoring for those in real-time as a counter-measure.

                  • 6. Re: CVE-2012-1675: Listener vulnerability question
                    pmdba

                    The specific vulnerability that you mentioned - CVE-2012-1675 - is mitigated through the use of Oracle's Valid Node Checking for Registration (VNCR), which is a configuration option in listener.ora. If you haven't already, you should check that out here:

                     

                    Oracle Net 12c: Valid Node Checking For Registration (VNCR) (Doc ID 1600630.1)

                     

                     

                    Just note that this solution doesn't suppress the listener response to nmap, as you were asking about.

                    • 7. Re: CVE-2012-1675: Listener vulnerability question
                      Joerg.Sobottka

                      pmdba: From the 19c manual: "Oracle Connection Manager is available for installation with Oracle Database 12c Enterprise Edition. It is a custom installation option on the Client disk."

                      Sorry, but I do a lot of licensing things also

                       

                      I think the OP does try to reach something that isn't possible without installing firewalls (even locally) and/or Connection Manager in addition.