Server vulnerabilities are the origin of security issues, and hackers' attacks on websites mostly start by finding the other party's vulnerabilities. Therefore, only by understanding your own vulnerabilities can website managers take corresponding countermeasures to prevent external attacks. The following are some common vulnerabilities in servers (including web servers and JSP servers).
What's going on with Apache leaking arbitrary file vulnerability?
In Apache 1.2 and later versions there is a mod_rewrite module that specifies the absolute path mapped by a special URL on the web server file system. If a rewrite rule containing the correct expression parameters is sent, the attacker can view any file on the target host.
The following is an example of rewriting rule directive (the first line only contains vulnerabilities):
RewriteRule /test/(.*) /usr/local/data/test-stuff/$1
RewriteRule /more-icons/(.*) /icons/$1
RewriteRule /go/(.*) /$1
Affected systems:
1）Apache 1.3.12
2）Apache 1.3.11win32
3）Apache 1.
Unaffected system: Apache 1.3.13
How to solve the problem of adding special characters to HTTP requests that cause exposure of JSP source code files?
Unify eWave ServletExec is a Java/Java Servlet engine plug-in, which is mainly used for WEB servers, such as: Microsoft IIS, Apache, Netscape Enterprise server, etc.
When one of the following characters is added to an HTTP request, ServletExec will return the JSP source code file.
.
%2E
+
%2B
\
%5C
%20
%00
Successfully exploiting this vulnerability will lead to the source code of the specified JSP file being leaked, for example: using any of the following URL requests will output the source code of the specified JSP file:
1）http://target/directory/jsp/.
2）http://target/directory/jsp/%2E
3）http://target/directory/jsp/+
4）http://target/directory/jsp/%2B
5）http://target/directory/jsp/\
6）http://target/directory/jsp/%5C
7）http://target/directory/jsp/%20
8）http://target/directory/jsp/%00
Affected systems:
1）Unify eWave ServletExec 3.0c
2）Sun Solaris 8.0
3）Microsoft Windows 98
4）Microsoft Windows NT 4.0
5）Microsoft Windows NT 2000
6）Linux kernel 2.
7）IBM AIX 4.3.2
8）HP HP-UX 11.4
Solution:
If no static pages or images are used, you can configure a default servlet and map "/" to this default servlet. In this way, when a URL that is not mapped to a servlet is received, the default servlet will be called. In this case, the default servlet can simply return "file not found". If a static page or image is used, this configuration can still be made, but this default servlet needs to handle requests for legal static pages and images.
Another possibility is to map *.jsp+, *.jsp., and *.jsp\, etc. to a servlet, which just returns "file not found". For cases like *.jsp%00 and *.jsp%20, the mapping should be entered in unencoded form. For example, for the mapping of *.jsp%20, enter "*.jsp ". Note that %20 is converted to a space character.
What are the vulnerabilities in Tomcat?
Tomcat 3.1 There is a problem of exposing website paths
Tomcat 3.1 is a software developed in the Apache software environment that supports JSP 1.1 and Servlets 2.2. It has a security problem. When sending a non-existent jsp request, it will expose the full path of the website's web page.
Example:
:8080/
The results show:
Error: 404
Location: /
JSP file "/appsrv2/jakarta-tomcat/webapps/ROOT/" not found
Solution: Upgrade to a new version
Tomcat exposes JSP file content
Files of type Java Server Pages (JSP) are registered on Tomcat with the '.jsp' extension, Tomcat is case-sensitive, and '.jsp' and '.JSP' are file extensions of different types. If you submit a link with '.JSP' to Tomcat, and Tomcat cannot find '.JSP' will respond to the request with the default '.text' file type. Because case file names are non-sensitive in NT systems, the requested file will be sent in text.
If it is on the UNIX server, the error message "file not found" will appear.
How to implement code protection for Tomcat under Windows
Some versions of Tomcat have vulnerabilities to leak source code. If the suffix of the file is changed to capitalization when calling the JSP page in the browser, the source code of this JSP file will be completely output to the browser (maybe there is nothing in the browser window, at this time you just need to check the HTML source file to discover). In this way, will the source code of the website be exposed to the Internet?
Don't worry, the solution is very simple. Just write all the combinations of suffixes into Tomcat_Home\conf\. In this way, Tomcat will treat JSPs with different suffix names separately and will not leak the code.
jsp
*.jsp
jsP
*.jsP
?lt;servlet-name>jSp
*.jSp
jSP
*.jSP
Jsp
*.Jsp
JsP
*.JsP
JSp
*.JSp
JSP
*.JSP
What are the vulnerabilities in the Allair Jrun vulnerability?
Allair JRUN Illegal Reading WEB-INF Vulnerability
There is a serious security vulnerability in Allaire’s JRUN server version 2.3. It allows an attacker to view the WEB-INF directory in the JRun 3.0 server.
If the user submits a URL request, and attaches a "/" to make the URL a deformed URL, all subdirectories under WEB-INF will be exposed. The attacker cleverly exploited this vulnerability will be able to remotely obtain read permissions for all files in the WEB-INF directory in the target host system.
For example, using the following URL will expose all files under WEB-INF:
:8100//WEB-INF/
Affected systems: Allaire JRun 3.0
Solution: Download and install patches:
Allaire patch jr233p_ASB00_28_29
/jrun/jr233p_ASB00_28_29.zip
Windows 95/98/NT/2000 and Windows NT Alpha
Allaire patch jr233p_ASB00_28_29tar
/jrun/jr233p_ASB00_28_29.
UNIX/Linux patch - GNU gzip/tar
Allaire JRUN 2.3 View any file vulnerability
There is a multiple display code vulnerability on Allaire’s JRUN server 2.3. The vulnerability allows an attacker to view the source code of any file in the root directory on the WEB server.
JRun 2.3 Use Java Servlets to parse various types of pages (for example: HTML, JSP, etc.). Based on file settings and, any servlet may be called with the URL prefix "/servlet/".
It may use Jrun’s SSIFilter servlet to retrieve any files on the target system. The following 2 examples show URLs that can be used to retrieve any file:
http://jrun:8000/servlet//../../t
http://jrun:8000/servlet//../../../../../../../
http://jrun:8000/servlet//../../. ./../../../../winnt/repair/sam
http://jrun:8000/servlet/ssifilter/../../
http://jrun:8000/servlet/ssifilter/../../../../../../../
http://jrun:8000/servlet/ssifilter/../../../../../../../winnt/repair/sam._
Note: Suppose JRun is running on the host "jrun" and port 8000.
Affected System: Allaire JRun 2.
Solution: Download and install patches:
Allaire patch jr233p_ASB00_28_29
/jrun/jr233p_ASB00_28_29.zip
Windows 95/98/NT/2000 and Windows NT Alpha
Allaire patch jr233p_ASB00_28_29tar
/jrun/jr233p_ASB00_28_29.
UNIX/Linux patch - GNU gzip/tar
Allaire JRUN 2.3 Remote execution of arbitrary command vulnerability
There is a security vulnerability on Allaire’s JRUN server 2.3, allowing remote users to compile/execute any files on the WEB server as JSP code. If the target file requested by the URL uses the prefix "/servlet/", the JSP interpretation execution function is activated. At this time, use "../" in the target file path requested by the user, and it is possible to access files outside the root directory on the WEB server. Using this vulnerability to request a file generated by the user input on the target host will seriously threaten the security of the target host system.
What's going on with Apache leaking arbitrary file vulnerability?
In Apache 1.2 and later versions there is a mod_rewrite module that specifies the absolute path mapped by a special URL on the web server file system. If a rewrite rule containing the correct expression parameters is sent, the attacker can view any file on the target host.
The following is an example of rewriting rule directive (the first line only contains vulnerabilities):
RewriteRule /test/(.*) /usr/local/data/test-stuff/$1
RewriteRule /more-icons/(.*) /icons/$1
RewriteRule /go/(.*) /$1
Affected systems:
1）Apache 1.3.12
2）Apache 1.3.11win32
3）Apache 1.
Unaffected system: Apache 1.3.13
How to solve the problem of adding special characters to HTTP requests that cause exposure of JSP source code files?
Unify eWave ServletExec is a Java/Java Servlet engine plug-in, which is mainly used for WEB servers, such as: Microsoft IIS, Apache, Netscape Enterprise server, etc.
When one of the following characters is added to an HTTP request, ServletExec will return the JSP source code file.
.
%2E
+
%2B
\
%5C
%20
%00
Successfully exploiting this vulnerability will lead to the source code of the specified JSP file being leaked, for example: using any of the following URL requests will output the source code of the specified JSP file:
1）http://target/directory/jsp/.
2）http://target/directory/jsp/%2E
3）http://target/directory/jsp/+
4）http://target/directory/jsp/%2B
5）http://target/directory/jsp/\
6）http://target/directory/jsp/%5C
7）http://target/directory/jsp/%20
8）http://target/directory/jsp/%00
Affected systems:
1）Unify eWave ServletExec 3.0c
2）Sun Solaris 8.0
3）Microsoft Windows 98
4）Microsoft Windows NT 4.0
5）Microsoft Windows NT 2000
6）Linux kernel 2.
7）IBM AIX 4.3.2
8）HP HP-UX 11.4
Solution:
If no static pages or images are used, you can configure a default servlet and map "/" to this default servlet. In this way, when a URL that is not mapped to a servlet is received, the default servlet will be called. In this case, the default servlet can simply return "file not found". If a static page or image is used, this configuration can still be made, but this default servlet needs to handle requests for legal static pages and images.
Another possibility is to map *.jsp+, *.jsp., and *.jsp\, etc. to a servlet, which just returns "file not found". For cases like *.jsp%00 and *.jsp%20, the mapping should be entered in unencoded form. For example, for the mapping of *.jsp%20, enter "*.jsp ". Note that %20 is converted to a space character.
What are the vulnerabilities in Tomcat?
Tomcat 3.1 There is a problem of exposing website paths
Tomcat 3.1 is a software developed in the Apache software environment that supports JSP 1.1 and Servlets 2.2. It has a security problem. When sending a non-existent jsp request, it will expose the full path of the website's web page.
Example:
:8080/
The results show:
Error: 404
Location: /
JSP file "/appsrv2/jakarta-tomcat/webapps/ROOT/" not found
Solution: Upgrade to a new version
Tomcat exposes JSP file content
Files of type Java Server Pages (JSP) are registered on Tomcat with the '.jsp' extension, Tomcat is case-sensitive, and '.jsp' and '.JSP' are file extensions of different types. If you submit a link with '.JSP' to Tomcat, and Tomcat cannot find '.JSP' will respond to the request with the default '.text' file type. Because case file names are non-sensitive in NT systems, the requested file will be sent in text.
If it is on the UNIX server, the error message "file not found" will appear.
How to implement code protection for Tomcat under Windows
Some versions of Tomcat have vulnerabilities to leak source code. If the suffix of the file is changed to capitalization when calling the JSP page in the browser, the source code of this JSP file will be completely output to the browser (maybe there is nothing in the browser window, at this time you just need to check the HTML source file to discover). In this way, will the source code of the website be exposed to the Internet?
Don't worry, the solution is very simple. Just write all the combinations of suffixes into Tomcat_Home\conf\. In this way, Tomcat will treat JSPs with different suffix names separately and will not leak the code.
jsp
*.jsp
jsP
*.jsP
?lt;servlet-name>jSp
*.jSp
jSP
*.jSP
Jsp
*.Jsp
JsP
*.JsP
JSp
*.JSp
JSP
*.JSP
What are the vulnerabilities in the Allair Jrun vulnerability?
Allair JRUN Illegal Reading WEB-INF Vulnerability
There is a serious security vulnerability in Allaire’s JRUN server version 2.3. It allows an attacker to view the WEB-INF directory in the JRun 3.0 server.
If the user submits a URL request, and attaches a "/" to make the URL a deformed URL, all subdirectories under WEB-INF will be exposed. The attacker cleverly exploited this vulnerability will be able to remotely obtain read permissions for all files in the WEB-INF directory in the target host system.
For example, using the following URL will expose all files under WEB-INF:
:8100//WEB-INF/
Affected systems: Allaire JRun 3.0
Solution: Download and install patches:
Allaire patch jr233p_ASB00_28_29
/jrun/jr233p_ASB00_28_29.zip
Windows 95/98/NT/2000 and Windows NT Alpha
Allaire patch jr233p_ASB00_28_29tar
/jrun/jr233p_ASB00_28_29.
UNIX/Linux patch - GNU gzip/tar
Allaire JRUN 2.3 View any file vulnerability
There is a multiple display code vulnerability on Allaire’s JRUN server 2.3. The vulnerability allows an attacker to view the source code of any file in the root directory on the WEB server.
JRun 2.3 Use Java Servlets to parse various types of pages (for example: HTML, JSP, etc.). Based on file settings and, any servlet may be called with the URL prefix "/servlet/".
It may use Jrun’s SSIFilter servlet to retrieve any files on the target system. The following 2 examples show URLs that can be used to retrieve any file:
http://jrun:8000/servlet//../../t
http://jrun:8000/servlet//../../../../../../../
http://jrun:8000/servlet//../../. ./../../../../winnt/repair/sam
http://jrun:8000/servlet/ssifilter/../../
http://jrun:8000/servlet/ssifilter/../../../../../../../
http://jrun:8000/servlet/ssifilter/../../../../../../../winnt/repair/sam._
Note: Suppose JRun is running on the host "jrun" and port 8000.
Affected System: Allaire JRun 2.
Solution: Download and install patches:
Allaire patch jr233p_ASB00_28_29
/jrun/jr233p_ASB00_28_29.zip
Windows 95/98/NT/2000 and Windows NT Alpha
Allaire patch jr233p_ASB00_28_29tar
/jrun/jr233p_ASB00_28_29.
UNIX/Linux patch - GNU gzip/tar
Allaire JRUN 2.3 Remote execution of arbitrary command vulnerability
There is a security vulnerability on Allaire’s JRUN server 2.3, allowing remote users to compile/execute any files on the WEB server as JSP code. If the target file requested by the URL uses the prefix "/servlet/", the JSP interpretation execution function is activated. At this time, use "../" in the target file path requested by the user, and it is possible to access files outside the root directory on the WEB server. Using this vulnerability to request a file generated by the user input on the target host will seriously threaten the security of the target host system.