Nytro

SecuREview magazine It’s a definitive sign of the times when terms like “cyber-warfare” and “cyber-espionage” are creeping into computer news stories. And these aren’t just movie plots or an imagination running wild. Military-grade malware are now creeping across corporate networks. Nation-state actors are investing heavily in the creation of tools to conduct cyber-warfare and we now have documented cases of malware being used against critical infrastructure targets. In this issue, we feature two stories addressing this issue. Costin Raiu writes about the timeline related to Stuxnet and Duqu, the malware families that are clearly targeting Iran’s nuclear facilities. Raiu’s research shows clearly that Duqu and Stuxnet were created by the same ‘owners’ with the main aim to spy on -- and eventually sabotage -- Iran’s FEP at Natanz. Eugene Kaspersky’s call for the Internet to be a military-free zone is relevant when we take into account that fact that Duqu was created as early as 2007, when the people who manage critical infrastructure around the globe were clearly unprepared for the dangerous ramifications of military-grade malware gone rogue. As Eugene outlines, we are sitting on a powder keg. If a ‘cyberweapon’ hits an unintended target, real lives could be at stake and collateral damage could be devastating. Achieving a military-free Internet might not be possible but a clear understanding of the clear and present dangers is necessary. Stay secure! Download: http://www.secureviewmag.com/downloads/article_pdf/4th_quarter_secureview_small_file.pdf

S-a mai discutat asta, de multe ori. E feature, nu bug. Un topic facut de tine nu e "New posts", e deja vizualizat de tine. La fel, cand intri intr-un topic, altul, e vizualizat, deci nu mai apare la new posts. bruttus139: Da, e o problema cand la link-uri apar caractere Unicode, nu stiu inca exact despre ce e vorba dar cand o sa am timp o sa ma uit pentru ca si eu am intalnit aceasta problema.

[h=1]SQL Injection Cheat Sheet[/h] 08/12/2011 Find and exploit SQL Injections with free Netsparker SQL Injection Scanner SQL Injection Cheat Sheet, Document Version 1.4 [h=2]About SQL Injection Cheat Sheet[/h] Currently only for MySQL and Microsoft SQL Server, some ORACLE and some PostgreSQL. Most of samples are not correct for every single situation. Most of the real world environments may change because of parenthesis, different code bases and unexpected, strange SQL sentences. Samples are provided to allow reader to get basic idea of a potential attack and almost every section includes a brief information about itself. [TABLE] [TR] [TD=align: right]M : [/TD] [TD]MySQL [/TD] [/TR] [TR] [TD=align: right]S : [/TD] [TD]SQL Server[/TD] [/TR] [TR] [TD=align: right]P : [/TD] [TD]PostgreSQL[/TD] [/TR] [TR] [TD=align: right]O : [/TD] [TD]Oracle[/TD] [/TR] [TR] [TD=align: right]+ : [/TD] [TD]Possibly all other databases [/TD] [/TR] [/TABLE] [h=5]Examples;[/h] (MS) means : MySQL and SQL Server etc. (M*S) means : Only in some versions of MySQL or special conditions see related note and SQL Server [h=2]Table Of Contents[/h] [LIST=1] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#about"]About SQL Injection Cheat Sheet [/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#SyntaxBasicAttacks"]Syntax Reference, Sample Attacks and Dirty SQL Injection Tricks [/URL] [LIST=1] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#LineComments"]Line Comments [/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#LineCommentAttacks"]SQL Injection Attack Samples[/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#InlineComments"]Inline Comments [/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#InlineSamples"]Classical Inline Comment SQL Injection Attack Samples[/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#MySQLInlineSamples"]MySQL Version Detection Sample Attacks[/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StackingQueries"]Stacking Queries[/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#LangDbFigure"]Language / Database Stacked Query Support Table [/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#AboutMySQLandPHP"]About MySQL and PHP[/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StackedSamples"]Stacked SQL Injection Attack Samples[/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#IfStatements"]If Statements[/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#MySQLIf"]MySQL If Statement[/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#SQLServerIf"]SQL Server If Statement [/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#SampleIfStatements"]If Statement SQL Injection Attack Samples [/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#UsingIntegers"]Using Integers [/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StringOperations"]String Operations[/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StringConcat"]String Concatenation [/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StringwithoutQuotes"]Strings without Quotes[/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#HexbasedSamples"]Hex based SQL Injection Samples[/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#StringModification"]String Modification & Related [/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#UnionInjections"]Union Injections[/URL] [LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#UnionLanguageIssues"]UNION – Fixing Language Issues[/URL] [/LIST] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#ByPassingLoginScreens"]Bypassing Login Screens[/URL] [*][URL="http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#Enablecmdshell"]Enabling xp_cmdshell in SQL Server 2005 [/URL] [*][I]Other parts are not so well formatted but check out by yourself, drafts, notes and stuff, scroll down and see. [/I] [/LIST] [/LIST] Link: http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/

Te caci in palma si arunci cu cacat dupa el. Iti faci laba si dai sloboz peste mancare. Mananci tu cacat cand el doarme, apoi mergi si ii vomiti in gura. Iti dai pula si cand doarme i-o indesi in cur. Nu mai intri aici si postezi astfel de porcarii. Ce parere ai?

Cred ca asta nu se pune... Metasploit Pro is available immediately for $15,000 per named user, per year and includes support with dedicated SLAs provided by Rapid7 staff. Si probabil nici asta: CORE Impact Pro Vulnerability Assessment and Penetration Testing Software Product: Core Impact Pro 8 Core Security Price:$30,000 per year Asta se pune? http://pwnieexpress.com/products/pwnplug-elite

[COLOR=#000000][COLOR=#007700] if(isset([/COLOR][COLOR=#0000BB]$_COOKIE[/COLOR][COLOR=#007700][[/COLOR][COLOR=#DD0000]'uid'[/COLOR][COLOR=#007700]])){ [/COLOR][COLOR=#0000BB]$uid [/COLOR][COLOR=#007700]= (int)[/COLOR][COLOR=#0000BB]$_COOKIE[/COLOR][COLOR=#007700][[/COLOR][COLOR=#DD0000]'uid'[/COLOR][COLOR=#007700]]; [/COLOR][COLOR=#0000BB]$query [/COLOR][COLOR=#007700]= [/COLOR][COLOR=#0000BB]mysql_query[/COLOR][COLOR=#007700]([/COLOR][COLOR=#DD0000]'SELECT * FROM users WHERE uid='[/COLOR][COLOR=#007700].[/COLOR][COLOR=#0000BB]$uid[/COLOR][COLOR=#007700].[/COLOR][COLOR=#DD0000]' LIMIT 1'[/COLOR][COLOR=#007700]);[/COLOR][/COLOR] /*..............................................................................................*/ [COLOR=#000000][COLOR=#0000BB]setcookie[/COLOR][COLOR=#007700]([/COLOR][COLOR=#DD0000]'uid'[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000BB]$_GET[/COLOR][COLOR=#007700][[/COLOR][COLOR=#DD0000]'uid'[/COLOR][COLOR=#007700]], [/COLOR][COLOR=#0000BB]time[/COLOR][COLOR=#007700]()+[/COLOR][COLOR=#0000BB]3600[/COLOR][COLOR=#007700]); [/COLOR][COLOR=#0000BB]$uid [/COLOR][COLOR=#007700]= (int)[/COLOR][COLOR=#0000BB]$_GET[/COLOR][COLOR=#007700][[/COLOR][COLOR=#DD0000]'uid'[/COLOR][COLOR=#007700]]; [/COLOR][COLOR=#0000BB]$query [/COLOR][COLOR=#007700]= [/COLOR][COLOR=#0000BB]mysql_query[/COLOR][COLOR=#007700]([/COLOR][COLOR=#DD0000]'SELECT * FROM users WHERE uid='[/COLOR][COLOR=#007700].[/COLOR][COLOR=#0000BB]$uid[/COLOR][COLOR=#007700].[/COLOR][COLOR=#DD0000]' LIMIT 1'[/COLOR][COLOR=#007700]);[/COLOR][/COLOR] Genial.

Lasa "Driver Plm" si instaleaza-le manual. E posibil ca multe dintre aceste porcarii sa fie de fapt niste troieni simpatici.

V.i.p.

“Red October”. Detailed Malware Description 1. First Stage of Attack - Securelist The Excel-based exploit - CVE-2009-3129 This is the oldest known way for Red October to infect computers. A list of some of the Excel file names can be found below: ... Agenda Telefoane institutii si ministere 2011.xls Agenda Telefoane institutii si ministere 2011 (2).xls Agenda Telefoane&Email institutii si ministere 2011.xls ... Cititi in pula mea articolul complet nu toate cacaturile, prostilor. The "Red October" Campaign - An Advanced Cyber Espionage Network Targeting Diplomatic and Government Agencies - Securelist "Red October" - part two, the modules - Securelist "Red October" Diplomatic Cyber Attacks Investigation - Securelist “Red October”. Detailed Malware Description 1. First Stage of Attack - Securelist “Red October”. Detailed Malware Description 2. Second Stage of Attack - Securelist “Red October”. Detailed Malware Description 3. Second Stage of Attack - Securelist “Red October”. Detailed Malware Description 4. Second Stage of Attack - Securelist “Red October”. Detailed Malware Description 5. Second Stage of Attack - Securelist Reveniti cu comentatii dupa ce cititi. Stirea a mai fost postata, de x ori, doar ca va pica coaiele daca cititi articolele bine scrise in engleza, preferati aberatiile jurnalistilor pulii. https://rstforums.com/forum/63558-red-october-diplomatic-cyber-attacks-investigation.rst https://rstforums.com/forum/63570-red-october-campaign.rst https://rstforums.com/forum/63685-hunt-red-october.rst https://rstforums.com/forum/63689-red-october-java-exploit-delivery-vector-analysis.rst https://rstforums.com/forum/63762-red-october-part-two-modules.rst Adica muie.

[h=3]TOR relay and transparent routing[/h][h=2]Friday, January 18, 2013[/h]I assume you already know about TOR, The Onion Router for anonymity to protect your privacy. TOR is a network so it can only work if there are nodes (relays). If you have a server, you can run one so consider it. Afraid of legal issues? You do not need to run an exit node, a relay is just fine: everything is encrypted. This post will show you how easy it is to set up a TOR relay on Debian, how to nicely monitor it and how to use it as a transparent router. [h=3]Setup[/h]Simple: a NAT router and behind a LAN with a server and a workstation. ________ ________ internet | | LAN | | ----------| (NAT) |--------------| server | 192.168.0.1 1.2.3.4 | router |---------. |________| |________| | ______|______ | | | workstation | 192.168.0.2 |_____________| [h=3]Install[/h]If you are not root, use sudo -i or su to get a root shell then: # echo 'deb http://deb.torproject.org/torproject.org squeeze main' \ >> /etc/apt/sources.list # gpg --recv 74A941BA219EC810 # gpg --export --armor 74A941BA219EC810 | apt-key add - # apt-get update # apt-get install tor [h=3]Prepare a control password[/h]You will need a password to remotely control your TOR server: $ tor --hash-password test [...] 16:A908451A24E6A06D604B4D30592A14A177FD276103658D4F10D9C4B12F [h=3]Configuration[/h]Open /etc/tor/torrc with your favourite editor and configure a few things: # TOR SOCKS port SocksPort 0.0.0.0:9050 # Control port ControlPort 0.0.0.0:9051 HashedControlPassword 16:A908451(...the hash above...)10D9C4B12F # TOR relay port ORPort 9001 # Throttle traffic to 100KB/s (800Kbps) but allow bursts up to 200KB/s (1600Kbps) RelayBandwidthRate 100 KB RelayBandwidthBurst 200 KB # No exits allowed, just be a relay node ExitPolicy reject * # Transparent router VirtualAddrNetwork 10.192.0.0/10 AutomapHostsOnResolve 1 TransPort 0.0.0.0:9040 DNSPort 0.0.0.0:53 Apply: # invoke-rc.d tor reload [h=3]Firewall[/h]I like iptables with ferm, for easy rule making. Edit /etc/ferm/ferm.conf: domain ip { table filter { chain INPUT { proto tcp dport 9001 ACCEPT; # ORPort saddr 192.168.0.0/24 { proto udp dport 53 ACCEPT; # DNSPort proto tcp dport 9040 ACCEPT; # TransPort proto tcp dport 9050 ACCEPT; # SocksPort proto tcp dport 9051 ACCEPT; # ControlPort } } } table nat { chain PREROUTING { interface eth0 saddr 192.168.0.0/24 { proto udp dport 53 REDIRECT to-ports 53; # DNSPort proto tcp syn REDIRECT to-ports 9040; # TransPort } } } } Apply: # invoke-rc.d ferm reload [h=3]Port forwarding[/h]The only port you need to forward from your router to your TOR server is 9001. If your router is also a Linux server, you can do this with ferm again. Edit /etc/ferm/ferm.conf: domain ip { table nat { chain PREROUTING { daddr 1.2.3.4 { proto tcp dport 9001 DNAT to 192.168.0.1; # ORPort } } } } Apply: # invoke-rc.d ferm reload [h=3]Monitoring[/h]I like ARM, the Anonymizing Relay Monitor in console: Install: # apt-get install tor-arm And start it: # arm You can also run arm remotely, by connecting on the ControlPort (9051) and using the control password. [h=3]Use TOR on the workstation[/h]Instead of using TOR for the whole system, let's add a tor user that will pass through TOR, while other users still use the normal connection: # adduser tor And now it is policy routing on user. Edit /etc/ferm/ferm.conf to mark packets coming from tor user: domain ip { table mangle { chain OUTPUT { mod owner uid-owner tor MARK set-mark 0x1; } } } Apply: # invoke-rc.d ferm reload And route packets differently based on the mark: # ip rule add fwmark 0x1 table 100 # ip route add default via 192.168.0.1 table 100 # ip route flush cache To persist after reboot, edit /etc/network/interfaces and add 3 post-up to your network interface: auto eth0 iface eth0 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.254 post-up ip rule add fwmark 0x1 table 100 post-up ip route add default via 192.168.0.1 table 100 post-up ip route flush cache Now try: tor$ curl ifconfig.me [not your IP but a TOR exit node] Posted by StalkR at 22:22 Sursa: StalkR's Blog: TOR relay and transparent routing

Confirmed: Java only fixed one of the two bugs. Monday, January 14, 2013 One of things we tend to do when preparing our Java exploitation training as part of the INFILTRATE master class, is to analyze the past and the present in order to not only teach the specifics of exploitation but to build in our students their offensive "intuition". This is an important characteristic if you want to win in the world of exploitation, because these days exploits are not served on a fresh cucumber nitro-tini but rather you will need picks and shovels to open your way into it. This is the case of the recent MBeanInstantiator exploit, which combines two bugs in order to remotely execute code. And sometimes for everyone involved in the offensive world, this mean you need to look at the patch with special detail, because sometimes the vendor stops the worm/0day exploit with a patch, but doesn't necessary fix all of the associated problems. And of course, being only human, sometimes the vendor's team just plain messes up the patch. After further analysis of the Oracle Java patch (Java 7 update 11), Immunity was able to identify that only one of the two bugs were fixed, making Java still vulnerable to one of the bugs used in the exploit found in the wild. The patch did stop the exploit, fixing one of its components. But an attacker with enough knowledge of the Java code base and the help of another zero day bug to replace the one fixed can easily continue compromising users. (Assuming they now use a signed Java applet - one of the other changes introduced in this patch.) Java is indeed a constant target for attackers, and nobody should be surprised if an attacker just replaces the patched bug with a different one and starts compromising machines again. This is why it is important for Oracle and their user base to start paying special attention to each bug because with an exploitation chain as the one is needed these days, every bug matters. Immunity this year is doing a five day long Master class at Infiltrate (April, 15-19) where we will spent a full day on Java exploitation, teaching our student how to analyze patch, understand the Java code base and how to combine multiple bugs to obtain full exploitation. Oracle patch Oracle released a patch for these 2 vulnerabilities and two different CVE's were assigned to them. The patch for the Recursive Reflection vulnerability (CVE-2013-0422) can be seen in the java.lang.invoke.MethodHandleNatives.isCallerSensitive method: [TABLE=class: tr-caption-container, align: center] [TR] [TD][/TD] [/TR] [TR] [TD=class: tr-caption] isCallerSensitive diff between Java 7 update 10 and 11[/TD] [/TR] [/TABLE] And also sun.reflect.misc.MethodUtil class was changed to include some more checks: public static Object invoke(Method paramMethod, Object paramObject, Object[] paramArrayOfObject) throws InvocationTargetException, IllegalAccessException { if ((paramMethod.getDeclaringClass().equals(AccessController.class)) || ((paramMethod.getDeclaringClass().equals(MethodHandles.class)) && (paramMethod.getName().equals("lookup"))) || ((paramMethod.getDeclaringClass().equals(MethodHandles.Lookup.class)) && ((paramMethod.getName().startsWith("find")) || (paramMethod.getName().startsWith("bind")) || (paramMethod.getName().startsWith("unreflect")))) || (paramMethod.getDeclaringClass().equals(Method.class))) { throw new InvocationTargetException( new UnsupportedOperationException("invocation not supported")); } [...] } However, the patch (which is Java 7 update 11) doesn't show any difference at all in the classes inside com.sun.jmx.mbeanserver package. It appears then that the MBeanInstantiator.findClass vulnerability (CVE-2013-0422) is still there in the latest Java update. In fact, running a simple test shows that restricted classes can still be retrieved with this bug. A simple PoC like this can be used to see the situation: import java.applet.Applet; import com.sun.jmx.mbeanserver.JmxMBeanServer; import com.sun.jmx.mbeanserver.JmxMBeanServerBuilder; import com.sun.jmx.mbeanserver.MBeanInstantiator; public class Test9 extends Applet { public void test1() { System.out.println("RUNNING TEST1"); try { javax.management.MBeanServer ms = com.sun.jmx.mbeanserver.JmxMBeanServer .newMBeanServer("test", null, null, true); com.sun.jmx.mbeanserver.MBeanInstantiator mi = ((com.sun.jmx.mbeanserver.JmxMBeanServer) ms) .getMBeanInstantiator(); System.out.println("MBeanInstantiator = " + mi); Class clazz = mi.findClass( "sun.org.mozilla.javascript.internal.Context", (ClassLoader) null); System.out.println("clazz = " + clazz); } catch (Exception e) { e.printStackTrace(); } } public void test2() { System.out.println("RUNNING TEST2"); try { JmxMBeanServerBuilder sb = new JmxMBeanServerBuilder(); JmxMBeanServer jxmMBS = (JmxMBeanServer) sb.newMBeanServer("", null, null); MBeanInstantiator mi = jxmMBS.getMBeanInstantiator(); System.out.println("MBeanInstantiator = " + mi); Class clazz = mi.findClass("sun.misc.Unsafe", (ClassLoader) null); System.out.println("clazz = " + clazz); } catch (Exception e) { e.printStackTrace(); } } public void init() { test1(); System.out.println("--------------------------------------------"); test2(); } } The output of such code executed with Java 7 update 11 will be something like this: MbeanInstantiator.findClass vulnerability Over our investigation of the com.sun.jmx.mbeanserver.MBeanInstantiator.findClass and com.sun.jmx.mbeanserver.MBeanInstantiator.loadClass we found that the implementation on JDK6 and JDK7 are the same, which led us at first to the wrong conclusion that both were vulnerable. After further research we found that although the MBeanInstantiator code is the same in both versions, JDK/JRE 6 cannot be exploited. There is a flag called com.sun.jmx.mbeanserver.JmxMBeanServer.interceptorsEnabled that determines if MbeanServerInterceptors are enabled or not and that value is set in the com.sun.jmx.mbeanserver.JmxMBeanServer constructor. In JDK7, the public static method com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(String, MBeanServer, MBeanServerDelegate, boolean) directly calls the constructor com.sun.jmx.mbeanserver.JmxMBeanServer.JmxMBeanServer(String, MBeanServer, MBeanServerDelegate, MBeanInstantiator, boolean, boolean) where the interceptorsEnabled flag is fully controlled. JDK6 implementation is different because it calls another constructor that ignores the flag passed to the newMbeanServer method and always sets the flag to false. This is what is preventing an attacker from getting a MbeanInstantiator instance to then use the findClass method. We can clearly see that the call hierarchy is different in JDK6 and JDK7 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center] JDK7 MBeanInstantiator constructor call hierarchy[/TD] [/TR] [/TABLE] [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center] JDK6 MBeanInstantiator constructor call hierarchy[/TD] [/TR] [/TABLE] This last image clearly shows that the newMBeanServer method is calling a different constructor that sets the flag to False. Recursive Reflection Vulnerability The vulnerability is that the new reflection API security checks were passed because a trusted caller from the JDK (java.lang.invoke.MethodHandle) was retrieved from the frame's stack, as was explained in the analysis. We came to the conclusion that this happened due to an error in the sun.reflect.Reflection.getCallerClass implementation that failed to skip frames related to the new reflection API, but this was not correct. I'd like to thank Michael 'mihi' Schierl for pointing out that the reason behind the situation was not what I suspected but something else. Learning from mistakes is good You can see the details in Michael's post. Update: According to mitre.org, CVE-2013-0422 includes the MBeanInstantiator and the Recursive Reflection issue (Even though MBeanInstantiator is not fixed on the last Java release). CVE-2012-3174 is actually for an unspecified vulnerability with no publicly known details. - Esteban Guillardoy Security Research Immunity, Inc Sursa: Immunity Products: Confirmed: Java only fixed one of the two bugs.

Java MBeanInstantiator.findClass 0Day Analysis January, 2013 Esteban Guillardoy Table of Contents Introduction.......................................................................................................................................... 3 MbeanInstantiator.findClass vulnerability........................................................................................... 3 Affected Versions.............................................................................................................................4 Recursive Reflection Vulnerability (technique?)................................................................................. 4 Exploitation Technique.........................................................................................................................5 References............................................................................................................................................ 6 Introduction Another Java 0day! On one hand, this is exciting because it effects a lot of people and is therefor important. But there have been many instances of Java vulnerabilities coming out – and if someone does not have Java disabled by now, they are probably already infected. It's worth noting that unlike some Java vulnerabilities in the past, this one was first discovered when it was included in “commercial” malware packages, which were then linked to by ad-farms on legitimate sites, and used in mass malware installation campaigns. So even if your organization is quite far ahead when it comes to disabling or limited Java on your workstations, the particulars of the exploit are interesting because they may give hints as to how future Java (or .Net or Flash or other VM's with sandboxes) will suffer in the future. This is also the reason why we include an entire day of Java Sandbox Analysis in the upcoming INFILTRATE Master Class in April here in Miami Beach. It teaches you how to think about these problems, and nothing makes a better case study than an 0day. Once again the exploit is using 2 vulnerabilities together with an exploitation technique in order to fully exploit a target. We will analyze both below. Download: https://partners.immunityinc.com/idocs/Java%20MBeanInstantiator.findClass%200day%20Analysis.pdf

DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers Authored by Fernando Gont This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. Operational Security Capabilities for F. Gont IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH Internet-Draft W. Liu Intended status: BCP Huawei Technologies Expires: June 15, 2013 G. Van de Velde Cisco Systems December 12, 2012 DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers draft-ietf-opsec-dhcpv6-shield-00 Abstract This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 15, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Gont, et al. Expires June 15, 2013 [Page 1] Internet-Draft DHCPv6-Shield December 2012 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. DHCPv6-Shield Configuration . . . . . . . . . . . . . . . . . 4 3. DHCPv6-Shield Implementation Advice . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Gont, et al. Expires June 15, 2013 [Page 2] Internet-Draft DHCPv6-Shield December 2012 1. Introduction This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers [RFC3315]. This mechanism is analogous to the RA-Guard mechanism [RFC6104] [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation] intended for protection against rogue Router Advertisement messages. The basic concept behind DHCPv6-Shield is that a layer-2 device filters DHCPv6 messages meant to DHCPv6 clients, according to a number of different criteria. The most basic filtering criterion being that the aforementioned DHCPv6 messages are discarded by the layer-2 device unless they are received on a specified port of the layer-2 device. Before the DCHPv6-Shield device is deployed, the administrator specifies the layer-2 port(s) on which DHCPv6 packets meant for DHCPv6 clients are allowed. Only those ports to which a DHCPv6 server is to be connected should be specified as such. Once deployed, the DHCPv6-Shield device inspects received packets, and allows (i.e. passes) DHCPv6 messages meant for DHCPv6 clients only if they are received on layer-2 ports that have been explicitly configured for such purpose. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Gont, et al. Expires June 15, 2013 [Page 3] Internet-Draft DHCPv6-Shield December 2012 2. DHCPv6-Shield Configuration Before being deployed for production, the DHCPv6-Shield device MUST me configured with respect to which layer-2 ports are allowed to send DHCPv6 packets to DHCPv6 clients. Only those layer-2 ports explicitly configured for such purpose will be allowed to send DHCPv6 packets to DHCPv6 clients. Gont, et al. Expires June 15, 2013 [Page 4] Internet-Draft DHCPv6-Shield December 2012 3. DHCPv6-Shield Implementation Advice The following filtering rules MUST be enforced as part of an DHCPv6- Shield implementation on those ports that are not allowed to send DHCPv6 packets to DHCPv6 clients: 1. DHCPv6-Shield MUST parse the IPv6 entire header chain present in the packet, to identify whether it is a DHCPv6 packet meant for a DHCPv6 client. RATIONALE: [RFC6564] specifies a uniform format for IPv6 Extension Header, thus meaning that an IPv6 node can parse an IPv6 header chain even if it contains Extension Headers that are not currently supported by that node. Additionally, [I-D.ietf-6man-oversized-header-chain] requires that if a packet is fragmented, the first fragment contains the entire IPv6 header chain. DHCPv6-Shield implementations MUST NOT enforce a limit on the number of bytes they can inspect (starting from the beginning of the IPv6 packet), since this could introduce false- positives: legitimate packets could be dropped simply because the DHCPv6-Shield device does not parse the entire IPv6 header chain present in the packet. An implementation that has such an implementation-specific limit MUST NOT claim compliance with this specification, and MUST pass the packet when such implementation-specific limit is reached. 2. When parsing the IPv6 header chain, if the packet is a first- fragment (i.e., a packet containing a Fragment Header with the Fragment Offset set to 0) and it fails to contain the entire IPv6 header chain (i.e., all the headers starting from the IPv6 header up to, and including, the upper-layer header), DHCPv6-Shield MUST drop the packet, and SHOULD log the packet drop event in an implementation-specific manner as a security fault. RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies that the first-fragment (i.e., the fragment with the Fragment Offset set to 0) MUST contain the entire IPv6 header chain, and allows intermediate systems such as routers to drop those packets that fail to comply with this requirement. NOTE: This rule should only be applied to IPv6 fragments with a Fragment Offset of 0 (non-first fragments can be safely passed, since they will never reassemble into a complete datagram if they are part of a DHCPv6 packet meant for a DHCPv6 client received on a port where such packets are not allowed). Gont, et al. Expires June 15, 2013 [Page 5] Internet-Draft DHCPv6-Shield December 2012 3. When parsing the IPv6 header chain, if the packet is identified to be a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield MUST drop the packet, and SHOULD log the packet drop event in an implementation-specific manner as a security fault. 4. In all other cases, DHCPv6-Shield MUST pass the packet as usual. NOTE: For the purpose of enforcing the DHCPv6-Shield filtering policy, an ESP header [RFC4303] should be considered to be an "upper-layer protocol" (that is, it should be considered the last header in the IPv6 header chain). This means that packets employing ESP would be passed by the DHCPv6-Shield device to the intended destination. If the destination host does not have a security association with the sender of the aforementioned IPv6 packet, the packet would be dropped. Otherwise, if the packet is considered valid by the IPsec implementation at the receiving host and encapsulates a DHCPv6 message, it is up to the receiving host what to do with such packet. If a packet is dropped due to this filtering policy, then the packet drop event SHOULD be logged in an implementation-specific manner as a security fault. The logging mechanism SHOULD include a drop counter dedicated to DHCPv6-Shield packet drops. In order to protect current end-node IPv6 implementations, Rule #2 has been defined as a default rule to drop packets that cannot be positively identified as not being DHCPv6 packets meant for DHCPv6 clients (because the packet is a fragment that fails to include the entire IPv6 header chain). This means that, at least in theory, DHCPv6-Shield could result in false-positive blocking of some legitimate (non DHCPv6-server) packets. However, as noted in [I-D.ietf-6man-oversized-header-chain], IPv6 packets that fail to include the entire IPv6 header chain are virtually impossible to police with state-less filters and firewalls, and hence are unlikely to survive in real networks. [I-D.ietf-6man-oversized-header-chain] requires that hosts employing fragmentation include the entire IPv6 header chain in the first fragment (the fragment with the Fragment Offset set to 0), thus eliminating the aforementioned false positives. The aforementioned filtering rules implicitly handle the case of fragmented packets: if the DHCPv6-Shield device fails to identify the upper-layer protocol as a result of the use of fragmentation, the corresponding packets would be dropped. Finally, we note that IPv6 implementations that allow overlapping fragments (i.e. that do not comply with [RFC5722]) might still be subject of DHCPv6-based attacks. However, a recent assessment of Gont, et al. Expires June 15, 2013 [Page 6] Internet-Draft DHCPv6-Shield December 2012 IPv6 implementations [SI6-FRAG] with respect to their fragment reassembly policy seems to indicate that most current implementations comply with [RFC5722]. Gont, et al. Expires June 15, 2013 [Page 7] Internet-Draft DHCPv6-Shield December 2012 4. IANA Considerations This document has no actions for IANA. Gont, et al. Expires June 15, 2013 [Page 8] Internet-Draft DHCPv6-Shield December 2012 5. Security Considerations The mechanism specified in this document can be used to mitigate DHCPv6-based attacks. Attack vectors based on other messages (such as ICMPv6 Router Advertisements) are out of the scope of this document. As noted in Section 3, IPv6 implementations that allow overlapping fragments (i.e. that do not comply with [RFC5722]) might still be subject of DHCPv6-based attacks. However, most current implementations seem to comply with [RFC5722], and hence forbid IPv6 overlapping fragments. We note that if an attacker sends a fragmented DHCPv6 packets on a port not allowed to send such packets, the first-fragment would be dropped, and the rest of the fragments would be passed. This means that the victim node would tie memory buffers for the aforementioned fragments, which would never reassemble into a complete datagram. If a large number of such packets were sent by an attacker, and the victim node failed to implement proper resource management for the fragment reassembly buffer, this could lead to a Denial of Service (DoS). However, this does not really introduce a new attack vector, since an attacker could always perform the same attack by sending forged fragmented datagram in which at least one of the fragments is missing. [CPNI-IPv6] discusses some resource management strategies that could be implemented for the fragment reassembly buffer. Gont, et al. Expires June 15, 2013 [Page 9] Internet-Draft DHCPv6-Shield December 2012 6. Acknowledgements The authors would like to thank (in alphabetical order) Jean-Michel Combes, Juergen Schoenwaelder, and Mark Smith, for providing valuable comments on earlier versions of this document. This document is heavily based on the document [I-D.ietf-v6ops-ra-guard-implementation] authored by Fernando Gont. Thus, the authors would like to thank Ran Atkinson, Karl Auer, Robert Downie, Washam Fan, David Farmer, Marc Heuse, Nick Hilliard, Ray Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter van de Velde, James Woodyatt, and Bjoern A. Zeeb, for providing valuable comments on [I-D.ietf-v6ops-ra-guard-implementation], on which this document is based. Gont, et al. Expires June 15, 2013 [Page 10] Internet-Draft DHCPv6-Shield December 2012 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009. [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, April 2012. 7.2. Informative References [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011. [I-D.ietf-6man-oversized-header-chain] Gont, F. and V. Manral, "Security and Interoperability Implications of Oversized IPv6 Header Chains", draft-ietf-6man-oversized-header-chain-02 (work in progress), November 2012. [I-D.ietf-v6ops-ra-guard-implementation] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra-guard-implementation-07 (work in progress), November 2012. [SI6-FRAG] SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6 fragmentation/reassembly", 2012, <http:// blog.si6networks.com/2012/02/ ipv6-nids-evasion-and-improvements-in.html>. Gont, et al. Expires June 15, 2013 [Page 11] Internet-Draft DHCPv6-Shield December 2012 [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request). Gont, et al. Expires June 15, 2013 [Page 12] Internet-Draft DHCPv6-Shield December 2012 Authors' Addresses Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fgont@si6networks.com URI: http://www.si6networks.com Will Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2704 5473 Email: gunter@cisco.com Gont, et al. Expires June 15, 2013 [Page 13] Sursa: DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers ? Packet Storm

Security Implications Of IPv6 On IPv4 Networks Revision 02 Authored by Fernando Gont This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. Operational Security Capabilities for F. Gont IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH Internet-Draft W. Liu Intended status: Informational Huawei Technologies Expires: July 1, 2013 December 28, 2012 Security Implications of IPv6 on IPv4 Networks draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 Abstract This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 1, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gont & Liu Expires July 1, 2013 [Page 1] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Implications of Native IPv6 Support . . . . . . . . . 5 2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 5 3. Security Implications of Tunneling Mechanisms . . . . . . . . 7 3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8 3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 10 3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 10 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Additional Considerations when Filtering IPv6 Traffic . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Summary of filtering rules . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Gont & Liu Expires July 1, 2013 [Page 2] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 1. Introduction Most general-purpose operating systems implement and enable by default native IPv6 [RFC2460] support and a number of transition/ co-existence technologies. In those cases in which the corresponding devices are deployed on networks that are assumed to be IPv4-only, native IPv6 support and/or IPv6 transition/co-existence technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes. For example, o A Network Intrusion Detection System (NIDS) might be prepared to detect attack patterns for IPv4 traffic, but might be unable to detect the same attack patterns when a transition/co-existence technology is leveraged for that purpose. o An IPv4 firewall might enforce a specific security policy in IPv4, but might be unable to enforce the same policy in IPv6. o Some transition/co-existence mechanisms might cause an internal host with otherwise limited IPv4 connectivity to become globally reachable over IPv6, therefore resulting in increased (and possibly unexpected) host exposure. Some transition/co-existence mechanisms (notably Teredo) are designed to traverse Network Address Port Translation (NAPT) [RFC2663] devices, allowing incoming IPv6 connections from the Internet to hosts behind the organizational firewall or NAPT (which in many deployments provides a minimum level of protection by only allowing those instances of communication that have been initiated from the internal network). o IPv6 support might, either inadvertently or as a result of a deliberate attack, result in VPN traffic leaks if IPv6-unaware Virtual Private Network (VPN) software is employed by dual-stacked hosts [I-D.ietf-opsec-vpn-leakages]. In general, most of the aforementioned security implications can be mitigated by enforcing security controls on native IPv6 traffic and on IPv4-tunneled traffic. Among such controls is the enforcement of filtering policies, such that undesirable traffic is blocked. While IPv6 widespread/global IPv6 deployment has been slower than expected, it is nevertheless happening, and thus filtering IPv6 traffic (whether native or transition/co-existence) to mitigate IPv6 security implications on IPv4 networks should only be considered as a temporary solution to protect a network until IPv6 is deployed. Only in some exceptional cases (such as military operations networks) could this approach to mitigating the aforementioned security implications be thought of as a longer-term strategy. Gont & Liu Expires July 1, 2013 [Page 3] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 This document discusses the security implications of IPv6 and IPv6 transition/co-existence technologies on (allegedly) IPv4-only networks, and provides guidance on how to mitigate the aforementioned issues. Gont & Liu Expires July 1, 2013 [Page 4] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 2. Security Implications of Native IPv6 Support Most popular operating systems include IPv6 support that is enabled by default. This means that even if a network is expected to be IPv4-only, much of its infrastructure is nevertheless likely to be IPv6 enabled. For example, hosts are likely to have at least link- local IPv6 connectivity which might be exploited by attackers with access to the local network. [CORE2007] is a security advisory about a buffer overflow which could be remotely-exploited by leveraging link-local IPv6 connectivity that is enabled by default. Additionally, unless appropriate measures are taken, an attacker with access to an 'IPv4-only' local network could impersonate a local router and cause local hosts to enable their 'non-link-local' IPv6 connectivity (e.g. by sending Router Advertisement messages), possibly circumventing security controls that were enforced only on IPv4 communications. [THC-IPV6] is the first publicly-available toolkit that implemented this attack vector (along with many others). [IPv6-Toolkit] is a fully-featured trouble-shooting and security assessment tool that implements this attack vector (along with many others). [Waters2011] provides an example of how this could be achieved using publicly available tools (besides incorrectly claiming the discovery of a "0day vulnerability"). Native IPv6 support could also possibly lead to VPN traffic leakages when hosts employ VPN software that not only does not support IPv6, but that does nothing about IPv6 traffic. [I-D.ietf-opsec-vpn-leakages] describes this issue, along with possible mitigations. In general, networks should enforce on native IPv6 traffic the same security policies they currently enforce on IPv4 traffic. However, in those networks in which IPv6 has not yet been deployed, and enforcing the aforementioned policies is deemed as unfeasible, a network administrator might mitigate IPv6-based attack vectors by means of appropriate packet filtering. 2.1. Filtering Native IPv6 Traffic Some layer-2 devices might have the ability to selectively filter packets based on the type of layer-2 payload. When such Gont & Liu Expires July 1, 2013 [Page 5] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 functionality is available, IPv6 traffic could be blocked at those layer-2 devices by blocking e.g. Ethernet frames with the Protocol Type field set to 0x86dd [IANA-ETHER]. SLAAC-based attacks [RFC3756] can be mitigated with technologies such as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. In a similar way, DHCPv6-based attacks can be mitigated with technologies such as DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. However, neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that employ IPv6 link-local addresses, since configuration of such addresses does not rely on Router Advertisement messages or DCHPv6- server messages. Administrators considering the filtering of native IPv6 traffic at layer-3 devices are urged to pay attention to the general considerations for IPv6 traffic filtering discussed in Section 4. If native IPv6 traffic is filtered at layer-2, local IPv6 nodes would only get to configure IPv6 link-local addresses. In order to mitigate attacks based on native IPv6 traffic, IPv6 security controls should be enforced on both IPv4 and IPv6 networks. The aforementioned controls might include: deploying IPv6-enabled NIDS, implementing IPv6 firewalling, etc. In some very specific scenarios (e.g., military operations networks) in which only IPv4 service might be desired, a network administrator might want to disable IPv6 support in all the communicating devices. Gont & Liu Expires July 1, 2013 [Page 6] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 3. Security Implications of Tunneling Mechanisms Unless properly managed, tunneling mechanisms might result in negative security implications ([RFC6169] describes the security implications of tunneling mechanisms in detail). Of the plethora of tunneling mechanism that have so far been standardized and widely implemented, the so-called "automatic tunneling" mechanisms (such as Teredo, ISATAP, and 6to4) are of particular interest from a security standpoint, since they might be employed without prior consent or action of the user or network administrator. Therefore, tunneling mechanisms should be a concern not only to network administrators that have consciously deployed them, but also to network and security administrators whose security policies might be bypassed by exploiting these mechanisms. [CERT2009] contains some examples of how tunnels can be leveraged to bypass firewall rules. The aforementioned issues could be mitigated by applying the common security practice of only allowing traffic deemed as "necessary" (i.e., the so-called "default deny" policy). Thus, when such policy is enforced IPv6 transition/co-existence traffic would be blocked by default, and would only be allowed as a result of an explicit decision (rather than as a result of lack of awareness about such traffic). It should be noted that this type of policy is usually enforced at a network that is the target of such traffic (such as an enterprise network). IPv6 transition traffic should generally never be filtered e.g. by an ISP when it is transit traffic. In those scenarios in which transition/co-existence traffic is meant to be blocked, it is highly recommended that, in addition to the enforcement of filtering policies at the organizational perimeter, the corresponding transition/co-existence mechanisms be disabled on each node connected to the organizational network. This would not only prevent security breaches resulting from accidental use of these mechanisms, but would also disable this functionality altogether, possibly mitigating vulnerabilities that might be present in the host implementation of these transition/co-existence mechanisms. IPv6-in-IPv4 tunnelling mechanisms (such as 6to4 or configured tunnels) can generally be blocked by dropping IPv4 packets that contain a Protocol field set to 41. Security devices such as NIDS might also include signatures that detect such transition/ Gont & Liu Expires July 1, 2013 [Page 7] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 co-existence traffic. Administrators considering the filtering of transition/co-existence traffic are urged to pay attention to the general considerations for IPv6 traffic filtering discussed in Section 4 3.1. Filtering 6in4 Probably the most basic type of tunnel employed for connecting IPv6 "islands" is the so-called "6in4", in which IPv6 packets are encapsulated within IPv4 packets. These tunnels are typically result from manual configuration at the two tunnel endpoints. 6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol field of 41. 3.2. Filtering 6over4 [RFC2529] specifies a mechanism known as 6over4 or 'IPv6 over IPv4' (or colloquially as 'virtual Ethernet'), which comprises a set of mechanisms and policies to allow isolated IPv6 hosts located on physical links with no directly-connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. This transition technology has never been widely deployed, because of the low level of deployment of multicast in most networks. 6over4 encapsulates IPv6 packets in IPv4 packets with their Protocol field set to 41. As a result, simply filtering all IPv4 packets that have a Protocol field equal to 41 will filter 6over4 (along with many other transition technologies). A more selective filtering could be enforced such that 6over4 traffic is filtered while other transition traffic is still allowed. Such a filtering policy would block all IPv4 packets that have their Protocol field set to 41, and that have a Destination Address that belongs to the prefix 239.0.0.0/8. This filtering policy basically blocks 6over4 Neighbor Discovery traffic directed to multicast addresses, thus preventing Stateless Address Auto-configuration (SLAAC), address resolution, etc. Additionally, it would prevent the 6over multicast addresses from being leveraged for the purpose of network reconnaissance. Gont & Liu Expires July 1, 2013 [Page 8] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 3.3. Filtering 6rd 6rd builds upon the mechanisms of 6to4 to enable the rapid deployment of IPv6 on IPv4 infrastructures, while avoiding some downsides of 6to4. Usage of 6rd was originally documented in [RFC5569], and the mechanism was generalized to other access technologies and formally standardized in [RFC5969]. 6rd can be blocked by blocking IPv4 packets with the Protocol field set to 41. 3.4. Filtering 6to4 6to4 [RFC3056] is an address assignment and router-to-router, host- to-router, and router-to-host automatic tunnelling mechanism that is meant to provide IPv6 connectivity between IPv6 sites and hosts across the IPv4 Internet. The security considerations for 6to4 are discussed in detail in [RFC3964]. [RFC6343] provides advice to network operators about 6to4 (some of which relates to security mitigations). As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, could be easily blocked by filtering IPv4 that contain their Protocol field set to 41. This is the most effective way of filtering such traffic. If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4 traffic is allowed, then more finer-grained filtering rules could be applied. For example, 6to4 traffic could be filtered by applying filtering rules such as: o Filter outgoing IPv4 packets that have the Destination Address set to an address that belongs to the prefix 192.88.99.0/24. o Filter incoming IPv4 packets that have the Source Address set to an address that belongs to the prefix 192.88.99.0/24. These rules assume that the corresponding nodes employ the "Anycast Prefix for 6to4 Relay Routers" [RFC3068]. It has been suggested that 6to4 relays send their packets with their IPv4 Source Address set to 192.88.99.1. o Filter outgoing IPv4 packets that have the Destination Address set to the IPv4 address of well-known 6to4 relays. Gont & Liu Expires July 1, 2013 [Page 9] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 o Filter incoming IPv4 packets that have the Source Address set to the IPv4 address of well-known 6to4 relays. These last two filtering policies will generally be unnecessary, and possibly unfeasible to enforce (given the number of potential 6to4 relays, and the fact that many relays might remain unknown to the network administrator). If anything, they should be applied with the additional requirement that such IPv4 packets have their Protocol field set to 41, to avoid the case where other services available at the same IPv4 address as a 6to4 relay are mistakenly made inaccessible. If the filtering device has capabilities to inspect the payload of IPv4 packets, then the following filtering rules could be enforced: o Filter outgoing IPv4 packets that have their Protocol field set to 41, and that have an IPv6 Source Address (embedded in the IPv4 payload) that belongs to the prefix 2002::/16. o Filter incoming IPv4 packets that have their Protocol field set to 41, and that have an IPv6 Destination address (embedded in the IPv4 payload) that belongs to the prefix 2002::/16. 3.5. Filtering ISATAP ISATAP [RFC5214] is an Intra-site tunnelling protocol, and thus it is generally expected that such traffic will not traverse the organizational firewall of an IPv4-only. Nevertheless, ISATAP can be easily blocked by blocking IPv4 packets with a Protocol field of 41. The most popular operating system that includes an implementation of ISATAP in the default installation is Microsoft Windows. Microsoft Windows obtains the ISATAP router address by resolving the domain name isatap.<localdomain> DNS A resource records. Additionally, they try to learn the ISATAP router address by employing Link-local Multicast Name Resolution (LLMNR) [RFC4795] to resolve the name "isatap". As a result, blocking ISATAP by preventing hosts from successfully performing name resolution for the aforementioned names and/or by filtering packets with specific IPv4 destination addresses is both difficult and undesirable. 3.6. Filtering Teredo Teredo [RFC4380] is an address assignment and automatic tunnelling technology that provides IPv6 connectivity to dual-stack nodes that are behind one or more Network Address Port Translation (NAPT) [RFC2663] devices, by encapsulating IPv6 packets in IPv4-based UDP datagrams. Teredo is meant to be a 'last resort' IPv6 connectivity Gont & Liu Expires July 1, 2013 [Page 10] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 technology, to be used only when other technologies such as 6to4 cannot be deployed (e.g., because the edge device has not been assigned a public IPv4 address). As noted in [RFC4380], in order for a Teredo client to configure its Teredo IPv6 address, it must contact a Teredo server, through the Teredo service port (UDP port number 3544). To prevent the Teredo initialization process from succeeding, and hence prevent the use of Teredo, an organizational firewall could filter outgoing UDP packets with a Destination Port of 3544. It is clear that such a filtering policy does not prevent an attacker from running its own Teredo server in the public Internet, using a non-standard UDP port for the Teredo service port (i.e., a port number other than 3544). If the filtering device has capabilities to inspect the payload of IPv4 packets, the following (additional) filtering policy could be enforced: o Filter outgoing IPv4/UDP packets that have that embed an IPv6 packet with the "Version" field set to 6, and an IPv6 Source Address that belongs to the prefix 2001::/32. o Filter incoming IPv4/UDP packets that have that embed an IPv6 packet with the "Version" field set to 6, and an IPv6 Destination Address that belongs to the prefix 2001::/32. These two filtering rules could, at least in theory, result in false positives. Additionally, they would generally require the filtering device to reassemble fragments prior to enforcing filtering rules, since the information required to enforce them might be missing in the received fragments (which should be expected if Teredo is being employed for malicious purposes). The most popular operating system that includes an implementation of Teredo in the default installation is Microsoft Windows. Microsoft Windows obtains the Teredo server addresses (primary and secondary) by resolving the domain name teredo.ipv6.microsoft.com into DNS A records. A network administrator might want to prevent Microsoft Windows hosts from obtaining Teredo service by filtering at the organizational firewall outgoing UDP datagrams (i.e. IPv4 packets with the Protocol field set to 17) that contain in the IPv4 Destination Address any of the IPv4 addresses that the domain name teredo.ipv6.microsoft.com maps to. Additionally, the firewall would filter incoming UDP datagrams from any of the IPv4 addresses to which the domain names of well-known Teredo servers (such as Gont & Liu Expires July 1, 2013 [Page 11] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 teredo.ipv6.microsoft.com) resolve. As these IPv4 addresses might change over time, an administrator should obtain these addresses when implementing the filtering policy, and should also be prepared to keep this list up to date. The corresponding addresses can be easily obtained from a UNIX host by issuing the command 'dig teredo.ipv6.microsoft.com a' (without quotes). It should be noted that even with all these filtering policies in place, a node in the internal network might still be able to communicate with some Teredo clients. That is, it could configure an IPv6 address itself (without even contacting a Teredo server), and might send Teredo traffic to those peers for which intervention of the host's Teredo server is not required (e.g., Teredo clients behind a cone NAT). 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) The tunnel broker model enables dynamic configuration of tunnels between a tunnel client and a tunnel server. The tunnel broker provides a control channel for creating, deleting or updating a tunnel between the tunnel client and the tunnel server. Additionally, the tunnel broker may register the user IPv6 address and name in the DNS. Once the tunnel is configured, data can flow between the tunnel client and the tunnel server. [RFC3053] describes the Tunnel Broker model, while [RFC5572] specifies the Tunnel Setup Protocol (TSP), which can be used by clients to communicate with the Tunnel Broker. TSP can use either TCP or UDP as the transport protocol. In both cases TSP uses port number 3653, which has been assigned by the IANA for this purpose. As a result, TSP (the Tunnel Broker control channel) can be blocked by blocking TCP and UDP packets originating from the local network and destined to UDP port 3653 or TCP port 3653. Additionally, the data channel can be blocked by blocking UDP packets originated from the local network and destined to UDP port 3653, and IPv4 packets with a Protocol field set to 41. Gont & Liu Expires July 1, 2013 [Page 12] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 4. Additional Considerations when Filtering IPv6 Traffic IPv6 deployments in the Internet are continually increasing, and some hosts default to preferring IPv6 connectivity whenever it is available. This is likely to cause IPv6-capable hosts to attempt to reach an ever-increasing number of popular destinations via IPv6, even if this IPv6 connectivity is provided relies on a transition technology over an IPv4-only network. A large source of IPv6 brokenness today comes from nodes that believe that they have functional IPv6 connectivity, but the path to their destination fails somewhere upstream [Anderson2010] [Anderson2011] [Huston2010b] [Huston2012]. Upstream filtering of transition technologies or situations where a misconfigured node attempts to "provide" native IPv6 service on a given network without proper upstream IPv6 connectivity may result in hosts attempting to reach remote nodes via IPv6, and depending on the absence or presence and specific implementation details of "Happy Eyeballs" [RFC6555], there might be a non-trivial timeout period before the host falls back to IPv4 [Huston2010a] [Huston2012]. For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to ignore queries for AAAA DNS records, or even consider filtering AAAA records at the network ingress point to prevent end hosts from attempting their own DNS resolution. This will ensure that end hosts which are on an IPv4-only network will only receive DNS A records, and they will be unlikely to attempt to use (likely broken) IPv6 connectivity to reach their desired destinations. Additionally, it is generally deemed as good practice to signal the packet drop to the source node, such that the source node is able to react to such packet drop in a more appropriate and timely way. A firewall could signal the packet drop by means of an ICMPv6 error message (or TCP [RFC0793] RST segment if appropriate), such that the source node can e.g. quickly react as described in [RFC5461]. For obvious reasons, if the traffic being filtered is IPv6 transition/co-existence traffic, the signalling packet should be sent by means of the corresponding IPv6 transition/co-existence technology. Gont & Liu Expires July 1, 2013 [Page 13] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 5. IANA Considerations There are no IANA registries within this document. The RFC-Editor can remove this section before publication of this document as an RFC. Gont & Liu Expires July 1, 2013 [Page 14] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 6. Security Considerations This document discusses the security implications of IPv6 on IPv4 networks, and describes a number of techniques to mitigate the aforementioned issues. In general, the possible mitigations boil down to enforcing on native IPv6 and IPv6 transition/co-existence traffic the same security policies currently enforced for IPv4 traffic, and/or blocking the aforementioned traffic when it is deemed as undesirable. Gont & Liu Expires July 1, 2013 [Page 15] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 7. Acknowledgements The authors would like to thank Wes George, who contributed most of the text that comprises Section 4 of this document. The authors would like to thank (in alphabetical order) Ran Atkinson, Brian Carpenter, Panos Kampanakis, David Malone, Arturo Servin, Donald Smith, Tina Tsou, and Eric Vyncke, for providing valuable comments on earlier versions of this document. This document is based on the results of the the project "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI). Fernando Gont would like to thank the UK CPNI for their continued support. Gont & Liu Expires July 1, 2013 [Page 16] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 8. References 8.1. Normative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", RFC 5572, February 2010. 8.2. Informative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", Gont & Liu Expires July 1, 2013 [Page 17] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 RFC 2663, August 1999. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004. [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011. [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011. [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011. [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012. [I-D.ietf-v6ops-ra-guard-implementation] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra-guard-implementation-07 (work in progress), November 2012. [I-D.ietf-opsec-vpn-leakages] Gont, F., "Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks", draft-ietf-opsec-vpn-leakages-00 (work in progress), December 2012. [I-D.ietf-opsec-dhcpv6-shield] Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", draft-ietf-opsec-dhcpv6-shield-00 (work in progress), December 2012. [IANA-ETHER] IANA, "Ether Types", 2012, <http://www.iana.org/assignments/ethernet-numbers>. [CERT2009] Gont & Liu Expires July 1, 2013 [Page 18] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 CERT, "Bypassing firewalls with IPv6 tunnels", 2009, <http ://www.cert.org/blogs/vuls/2009/04/ bypassing_firewalls_with_ipv6.html>. [CORE2007] CORE, "OpenBSD's IPv6 mbufs remote kernel buffer overflow", 2007, <http://www.coresecurity.com/content/open-bsd-advisorie>. [Huston2010a] Huston, G., "IPv6 Measurements", 2010, <http://www.potaroo.net/stats/1x1/>. [Huston2010b] Huston, G., "Flailing IPv6", 2010, <http://www.potaroo.net/ispcol/2010-12/6to4fail.pdf>. [Huston2012] Huston, G., "Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment", 2012, <http://www.potaroo.net/ispcol/2012-05/notquite.pdf>. [Anderson2010] Anderson, T., "Measuring and combating IPv6 brokenness", RIPE 61, Roma, November 2010, <http://ripe61.ripe.net/presentations/162-ripe61.pdf>. [Anderson2011] Anderson, T., "IPv6 dual-stack client loss in Norway", 2011, <http://www.fud.no/ipv6/>. [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request). [IPv6-Toolkit] "IPv6 Toolkit", <http://www.si6networks.com/tools/ipv6toolkit>. [THC-IPV6] "The Hacker's Choice IPv6 Attack Toolkit", <http://www.thc.org/thc-ipv6/>. [Waters2011] Waters, A., "SLAAC Attack - 0day Windows Network Interception Configuration Vulnerability", 2011, <http://resources.infosecinstitute.com/slaac-attack/>. Gont & Liu Expires July 1, 2013 [Page 19] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 Appendix A. Summary of filtering rules +------------+------------------------------------------------------+ | Technology | Filtering rules | +------------+------------------------------------------------------+ | Native | EtherType 0x86DD | | IPv6 | | +------------+------------------------------------------------------+ | 6in4 | IP proto 41 | +------------+------------------------------------------------------+ | 6over4 | IP proto 41 | +------------+------------------------------------------------------+ | 6rd | IP proto 41 | +------------+------------------------------------------------------+ | 6to4 | IP proto 41 | +------------+------------------------------------------------------+ | ISATAP | IP proto 41 | +------------+------------------------------------------------------+ | Teredo | UDP Dest Port 3544 | +------------+------------------------------------------------------+ | TB with | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest | | TSP | Port 3653) | +------------+------------------------------------------------------+ Table 1: Summary of filtering rules NOTE: the table above describes general and simple filtering rules for blocking the corresponding traffic. More finer-grained rules might be available in each of the corresponding sections of this document. Gont & Liu Expires July 1, 2013 [Page 20] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 Authors' Addresses Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fgont@si6networks.com URI: http://www.si6networks.com Will Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Gont & Liu Expires July 1, 2013 [Page 21] Sursa: Security Implications Of IPv6 On IPv4 Networks Revision 02 ? Packet Storm

Sigur, in loc sa donam unor tineri de exemplu, donam puscariasilor. Mai bine donez niste gloante gardienilor.

[h=2]An SSL Client Using OpenSSL[/h] by admin under c++ Recently I wrote about how to use OpenSSL to connect to a plain data server, this time I’m modifying the same code to perform encrypted connections. Naturally this is more of an example for how to use the API than production ready code. It’s main purpose is to show the very small difference between using the library as I did last time and how that example can be altered to create a basic SSL client. The essential changes to the code below are the replacement of the connection function ‘connect_unencrypted(host_and_port)‘ with ‘connect_encrypted(host_and_port, store_path, store_type, &ctx, &ssl)‘ and the introduction of the SSL cleanup step ‘SSL_CTX_free(ctx)‘. All other changes are purely cosmetic; which really shows how simple adding SSL to your application connections can be. Externally you need to provide the root CA certificate for the connection to be verified by. That’s it. At this point I could warble through the connection function, but you should just read through it yourself and consult the SSL man pages. Note that there is a dreadful buffer overflow possibility in this code and no real error handling, just a bit of logging. This is to keep the example short and also because only you will know what valid handling should take place for each situation when you write your own code. So take a look and enjoy. To try this out yourself: Make sure that you have Firefox, GCC and OpenSSL (development sources and libraries) installed. Copy the following code to a file called ‘main.c‘ in a directory that you will be playing around in. Compile the code using ‘gcc main.c -o sslclient -lssl‘ if you are on Linux or ‘gcc main.c -o sslclient -lssl-lcrypto‘ if you are on OSX. Select an SSL (https) web site to connect to and find the Root CA’s certificate name in the site’s certificate. Either export the appropriate root CA from Firefox or obtain it directly from the CA online in pem format and copy it to a file ‘certificate.pem‘ in the same directory as the ‘sslclient‘ file. Run the following command: './sslclient servername:443 "GET / \r\n\r\n" certificate.pem f e' /* * File: main.cpp * * Licence: GPL2 */ /* Standard headers */ #include <stdlib.h> #include <stdio.h> #include <string.h> /* OpenSSL headers */ #include <openssl/bio.h> #include <openssl/ssl.h> #include <openssl/err.h> /** * Simple log function */ void slog(char* message) { fprintf(stdout, message); } /** * Print SSL error details */ void print_ssl_error(char* message, FILE* out) { fprintf(out, message); fprintf(out, "Error: %s\n", ERR_reason_error_string(ERR_get_error())); fprintf(out, "%s\n", ERR_error_string(ERR_get_error(), NULL)); ERR_print_errors_fp(out); } /** * Print SSL error details with inserted content */ void print_ssl_error_2(char* message, char* content, FILE* out) { fprintf(out, message, content); fprintf(out, "Error: %s\n", ERR_reason_error_string(ERR_get_error())); fprintf(out, "%s\n", ERR_error_string(ERR_get_error(), NULL)); ERR_print_errors_fp(out); } /** * Initialise OpenSSL */ void init_openssl() { /* call the standard SSL init functions */ SSL_load_error_strings(); SSL_library_init(); ERR_load_BIO_strings(); OpenSSL_add_all_algorithms(); /* seed the random number system - only really nessecary for systems without '/dev/random' */ /* RAND_add(?,?,?); need to work out a cryptographically significant way of generating the seed */ } /** * Close an unencrypted connection gracefully */ int close_connection(BIO* bio) { int r = 0; r = BIO_free(bio); if (r == 0) { /* Error unable to free BIO */ } return r; } /** * Connect to a host using an unencrypted stream */ BIO* connect_unencrypted(char* host_and_port) { BIO* bio = NULL; /* Create a new connection */ bio = BIO_new_connect(host_and_port); if (bio == NULL) { print_ssl_error("Unable to create a new unencrypted BIO object.\n", stdout); return NULL; } /* Verify successful connection */ if (BIO_do_connect(bio) != 1) { print_ssl_error("Unable to connect unencrypted.\n", stdout); close_connection(bio); return NULL; } return bio; } /** * Connect to a host using an encrypted stream */ BIO* connect_encrypted(char* host_and_port, char* store_path, char store_type, SSL_CTX** ctx, SSL** ssl) { BIO* bio = NULL; int r = 0; /* Set up the SSL pointers */ *ctx = SSL_CTX_new(SSLv23_client_method()); *ssl = NULL; /* Load the trust store from the pem location in argv[2] */ if (store_type == 'f') r = SSL_CTX_load_verify_locations(*ctx, store_path, NULL); else r = SSL_CTX_load_verify_locations(*ctx, NULL, store_path); if (r == 0) { print_ssl_error_2("Unable to load the trust store from %s.\n", store_path, stdout); return NULL; } /* Setting up the BIO SSL object */ bio = BIO_new_ssl_connect(*ctx); BIO_get_ssl(bio, ssl); if (!(*ssl)) { print_ssl_error("Unable to allocate SSL pointer.\n", stdout); return NULL; } SSL_set_mode(*ssl, SSL_MODE_AUTO_RETRY); /* Attempt to connect */ BIO_set_conn_hostname(bio, host_and_port); /* Verify the connection opened and perform the handshake */ if (BIO_do_connect(bio) < 1) { print_ssl_error_2("Unable to connect BIO.%s\n", host_and_port, stdout); return NULL; } if (SSL_get_verify_result(*ssl) != X509_V_OK) { print_ssl_error("Unable to verify connection result.\n", stdout); } return bio; } /** * Read a from a stream and handle restarts if nessecary */ ssize_t read_from_stream(BIO* bio, char* buffer, ssize_t length) { ssize_t r = -1; while (r < 0) { r = BIO_read(bio, buffer, length); if (r == 0) { print_ssl_error("Reached the end of the data stream.\n", stdout); continue; } else if (r < 0) { if (!BIO_should_retry(bio)) { print_ssl_error("BIO_read should retry test failed.\n", stdout); continue; } /* It would be prudent to check the reason for the retry and handle * it appropriately here */ } }; return r; } /** * Write to a stream and handle restarts if nessecary */ int write_to_stream(BIO* bio, char* buffer, ssize_t length) { ssize_t r = -1; while (r < 0) { r = BIO_write(bio, buffer, length); if (r <= 0) { if (!BIO_should_retry(bio)) { print_ssl_error("BIO_read should retry test failed.\n", stdout); continue; } /* It would be prudent to check the reason for the retry and handle * it appropriately here */ } } return r; } /** * Main SSL demonstration code entry point */ int main(int argc, char** argv) { char* host_and_port = argv[1]; /* localhost:4422 */ char* server_request = argv[2]; /* "GET / \r\n\r\n" */ char* store_path = argv[3]; /* /home/user/projects/sslclient/certificate.pem */ char store_type = argv[4][0]; /* f = file, anything else is a directory structure */ char connection_type = argv[5][0]; /* e = encrypted, anything else is unencrypted */ char buffer[4096]; buffer[0] = 0; BIO* bio; SSL_CTX* ctx = NULL; SSL* ssl = NULL; /* initilise the OpenSSL library */ init_openssl(); /* encrypted link */ if (connection_type == 'e') { if ((bio = connect_encrypted(host_and_port, store_path, store_type, &ctx, &ssl)) == NULL) return (EXIT_FAILURE); } /* unencrypted link */ else if ((bio = connect_unencrypted(host_and_port)) == NULL) return (EXIT_FAILURE); write_to_stream(bio, server_request, strlen(server_request)); read_from_stream(bio, buffer, 4096); printf("%s\r\n", buffer); if (close_connection(bio) == 0) return (EXIT_FAILURE); /* clean up the SSL context resources for the encrypted link */ if (connection_type == 'e') SSL_CTX_free(ctx); return (EXIT_SUCCESS); } Sursa: An SSL Client Using OpenSSL

Java vs. C#: Which Performs Better in the ‘Real World’? by Jeff Cogswell | January 17, 2013 Java and C# each have their fans (and detractors). But which language wins out in a set of real-world performance tests? Let’s compare Java and C#, two programming languages with large numbers of ardent fans and equally virulent detractors. Despite all the buzzing online (“I’m about to rant. Who else hates working in C#?” one blog might complain, even as another insists: “Java ruined my life.”), it’s hard to find real-life benchmarks for each language’s respective performance. What do I mean by real life? I’m not interested in yet another test that grindingly calculates a million digits’ worth of Pi. I want to know about real-world performance: How does each language measure up when asked to dish out millions of Web pages a day? How do they compare when having to grab data from a database to construct those pages dynamically? These are the kinds of stats that tech folk like to know when choosing a platform. Before we get started, we need to establish some terminology. When you write Java code, you usually target the Java Virtual Machine (JVM). In other words, your code is compiled to bytecode, and that bytecode runs under the management of the JVM. C#, meanwhile, generally runs under the Microsoft Common Language Runtime (CLR). C# is similarly compiled to bytecode. Java and C#, then, are really just languages. In theory you could write Java code that targets the Microsoft CLR, and you could write C# code that targets the JVM. Indeed, there are several languages that target the JVM, including Erlang, Python, and more. The most common languages targeting the CLR (in addition to C#) is Microsoft’s own Visual Basic.NET, as well as their own flavor of C++ called C++.NET. The CLR also offers support for several less-common languages, including Python and Microsoft’s own F#. Further, the two runtimes include frameworks that are a set of classes written by Oracle/Sun and Microsoft for the JVM and CLR, respectively. Oracle has its Java Platform, along with various APIs. Microsoft’s .NET framework is a huge set of classes supporting development for the CLR; indeed, most people simply refer to the system as .NET rather than CLR. As such, we need to lay some groundwork for what we’re trying to accomplish. First, we’re not really comparing the languages themselves. What we need to compare is the underlying runtime. But even more than that, we need to also compare the performance of the frameworks. Therefore I’m going to do multiple comparisons, but ultimately try to match up apples to apples. For example, it’s very possible to write your own HTTP listener in either C# or Java, and just send back an HTML page generated dynamically. But the reality is, almost nobody actually writes a low-level HTTP listener; instead, they tend to use existing HTTP servers. Most C# web apps rely on Microsoft’s IIS server. Server-side Java, on the other hand, can work with several different servers, including the Apache HTTP server and the Tomcat server. (Tomcat, for example, was built specifically to interact with server-side Java.) While we want to compare apples to apples, we want to stay realistic. The servers will very likely play a role in the responses, as one might be faster than the other. Even though the HTTP servers are not technically part of the runtime, they are almost always used, and will therefore play a factor—that’s why, after a first test in which we skip those servers and write our own small HTTP servers, we’ll try similar tests with the respective HTTP servers to get a more complete and accurate picture. Static files are another issue, and I’m going to stay clear of them. Some of you may disagree, but with today’s architectures, if you seek fast performance for static files such as JavaScript or CSS files, you can easily put them on a cloud server that has replication across the country, use DNS configurations to locate the closest one to the client, and send them down very quickly. So for that reason I’m going to skip that part. Plus, if you’re trying to maximize performance, you probably don’t want your Web application dishing out static files when it should be focusing on doing its real work of reading databases, building dynamic content, and so on. A Quick Note on the Hardware I want to make sure the hardware in question introduces as few extraneous variables as possible. My own development machine has a ton of software on it, including many services that start up and steal processor time. Ideally, I would devote one entire core to the Java or C# process, but unfortunately the core allocation works the other way; you can limit a process to a single core, but you can’t stop other processes from using that core. So instead I’m allocating large servers on Amazon EC2, with close-to-barebones systems. Because I don’t want to compare Linux to Windows, and C# is primarily for Windows (unless we bring Mono in, which we’re not), so I’ll run all tests on Windows. On the client end, I don’t want network latency to interfere with the results either. A moment of slowness during one test would throw off the results. So I made the decision to run the client code on the same machine. While I can’t force the OS to reserve cores to a single process, I can force each process into a single core, which is what I did. Collecting the Results The results are timed on the client side. The optimal way to do this involves capturing the time and saving it, capturing the time again as needed, and continuing that way, without performing any time calculations until everything is done. Further, don’t print out anything at the console until all is done. One mistake I’ve seen people make is to grab a time at given points, and also at each point calculate the time difference and print it to the console. Consoles are slow, especially if they’re scrolling. So we’ll wait until we’re finished before calculating the time differences and writing to the console. The Client Code It doesn’t really matter what we use for the client code as long as we use it consistently in all tests. The client code will mimic the browser and time how long it takes to retrieve a page from the server. I can use either C# or Java. I ended up using C# because there is a very easy WebClient class, and an easy timer class. First Test: Listening for HTTP Let’s get started. The first test will simply be code that opens an HTTP listener and sends out dynamically generated Web pages. First: the Java version. There are many ways we can implement this, but I want to draw attention to two separate approaches: one is to open a TCP/IP listener on port 80, and wait for incoming connections—this is a very low-level approach where we would use the Socket class. The other is to use the existing HttpServer class. I’m going to use the HttpServer class, and here’s why: If we really want to track the speed of a Java compared to C#, without the Web, we can run some basic benchmarks that don’t involve the Web; we could create two console applications that spin a bunch of mathematical equations and perhaps do some string searching and concatenation—but that’s a topic for another day. We’re focusing on the Web here, so I’ll start with the HttpServer, and similarly with the equivalent in C#. Right off the bat I find what appears to be an anomaly: the Java version takes almost 2000 times as long to complete each request. Processing 5 requests in a row takes a total of 17615 ticks when retrieving a string from a CLR program that uses the HttpListener class, whereas processing 5 requests to the Java server running the HttpServer class takes 7882975 ticks. (When I switch to milliseconds, I see numbers such as 4045 milliseconds to process 15 requests on the Java server, and only 2 milliseconds to process 15 requests on the C# server.) Adding some debugging info to the Java server, I discover that the function responsible for responding to incoming requests and sending out data actually runs quickly—nowhere near the three seconds or so being reported. The bottleneck appears to be somewhere in the Java framework, when the data is sent back to the client. But the problem doesn’t exist when communicating with the C# client. To get to the bottom of this one, I decide to switch to a different Java client. Instead of using the heavier HttpServer class, I instead create a simple TCP/IP socket listener using the ServerSocket class. I manually construct a header string and a body that matches what I’m sending down in the C# version. After that, I see a huge improvement. I can run a large number of tests; I perform 2000 requests, one after the other, but not gathering the time until the 2000 calls to the Java server are finished; then I perform a similar process with the C# server. In this case, I can use milliseconds for the measurement. Calling the Java server 2000 times takes 2687 milliseconds. Calling the C# server 2000 times takes 214 milliseconds. The C# one is still much faster. Because of this discrepancy, I feel compelled to try out the Java version on a Linux server. The server used is a “c1.medium” on Amazon EC2. I install the two different Java classes and see essentially the same speeds. The HttpServer class takes about 14 seconds to process 15 requests. Not very good. And finally, to be absolutely sure, I write an equivalent client program in Java that retrieves the data. It records similar times as well. Second Test: Full Website It’s rare that people roll their own HTTP servers. Instead, C# programmers usually use IIS; Java programmers have a few choices, including TomCat. For my tests I’m going to utilize those two servers. For C#, I’m going to specifically use the ASP.NET MVC 4 platform running on IIS 8. I’m going to take two approaches: first, returning a string of HTML from the controller itself; for the second I’ll return a view that includes a date/time lookup. For the Java tests, I can do two similar approaches. I can have a servlet return some HTML, or I can return the results of a JSP page. These are analogous to the C# controller and View approaches, respectively. I could use the newer Java Faces or any number of other frameworks; if you’re interested, you might try some tests against these other frameworks. The C# controller simply returns a string of HTML. Running my client test for 2000 iterations sees a time of 991 milliseconds total. That’s still faster than my Java socket version. The view version of the C# app creates a full standards-compliant HTML page, with an HTML element, head element, meta element, title element, body element, and an inner div element containing the text “The date and time is” followed by the full date and the full time. The date and time are retrieved through the DateTime.Now instance, and filled in dynamically with each request. Running the client test for 2000 iterations against this view version takes 1804 milliseconds; about twice as long as the direct one. The direct one returns shorter HTML, but increasing the size of the HTML string to match the view version shows no difference; it hovers around the 950-1000 millisecond time. Even adding in the dynamic date and time doesn’t result any noticeable increase. The view version takes twice as long as the controller version, regardless. Now let’s move on to Java. The servlet is just as simple as the controller in the C# version. It just returns a string that contains an HTML page. Retrieving 2000 instances takes 479 milliseconds. That’s roughly half the time as the C# controller—very fast indeed. Returning a JSP page is also fast. As with C#, it takes a bit longer than the controller. In this case, retrieving 2000 copies takes 753 milliseconds. Adding in a call in the JSP file to retrieve the date makes no noticeable difference. In fact, the Tomcat server apparently performs some optimization, because after a few more requests, the time to retrieve 2000 copies went all the way down to 205 milliseconds. Conclusion These results are quite interesting. Having worked as a professional C# programmer for many years, I’ve been told anecdotally that .NET is one of the fastest runtimes around. Clearly these tests show otherwise. Of course, the tests are quite minimal; I didn’t do massive calculations, nor did I do any database lookups. Our space is limited here, but perhaps another day soon I can add in some database tests and report back. Meanwhile, Java is the clear winner here. Image: Bjorn Hoglund/Shutterstock.com slashdot (Java vs. C#: Which Performs Better in the 'Real World'?) Sursa: Java vs. C#: Which Performs Better in the 'Real World'?

Detecting System Intrusions Prepared on January 15, 2013 by: Demyo Inc. is one hundred percent IT security oriented company with headquarters in Miami, Florida, USA. Demyo Inc. delivers comprehensive penetration testing, vulnerability assessment, incident response, and compliance audit services just to name a few. Find out more at: Demyo, Inc. info@demyo.com Introduction First things first, detecting system intrusion its not the same as Intrusion Detection System/Intrusion Prevention System (IDS/IPS). We want to detect system intrusion once attackers passed all defensive technologies in the company, such as IDS/IPS mentioned above, full packet capture devices with analysts behind them, firewalls, physical security guards, and all other preventive technologies and techniques. Many preventing technologies are using blacklisting [1] most of the time, and thus that’s why they fail. Blacklisting is allowing everything by default, and forbidding something that is considered to be malicious. So for attacker it is a challenge to find yet another way to bypass the filter. It is so much harder to circumvent a whitelisting system. Download: www.exploit-db.com/download_pdf/24155

PHP Kit 0.2a Authored by infodox PHPkit is a simple PHP based backdoor, leveraging include() and php://input to allow the attacker to execute arbitrary PHP code on the infected server. The actual backdoor contains no suspicious calls such as eval() or system(), as the PHP code is executed in memory by include(). Download: http://packetstormsecurity.com/files/download/119637/phpkit-0.2a.tar.gz Sursa: PHP Kit 0.2a ? Packet Storm

Cve-2011-3402 Technical Analysis Description: CVE-2011-3402 is well known as the Windows Kernel TrueType 0-day used in the Duqu attack(s). Recently this exploit has begun to appear in several crimeware exploit kits... Actually, not merely just the exploit, but the entire font file used by Duqu, now being harnessed to infect a large population with malware. This talk will mostly be an extremely low-level walk-through of the font program within this TrueType font, which is used to manipulate the Windows Kernel into executing the native x86 shellcode. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Cve-2011-3402 Technical Analysis

Zeus -- Registry Analysis Using Volatility Framework Description: In this video I will show you how to analysis a registry from the memory using Volatility Framework. In this video I’m using Zeus Memory for registry analysis, and l will show F-secure top10 malware registry launchpoints. Not all but some of them Download Zeus Memory : - http://malwarecookbook.googlecode.com/svn-history/r26/trunk/17/1/zeus.vmem.zip Most trojans, worms, backdoors, and such make sure they will be run after a reboot by introducing autorun keys and values into the Windows registry. Some of these registry locations are better documented than others and some are more commonly used than others. One of the first steps to take when doing forensic analysis is to check the most obvious places in the registry for modifications. Source : - Top10 malware registry launchpoints - F-Secure Weblog : News from the Lab Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Zeus -- Registry Analysis Using Volatility Framework

Gsm: Cell Phone Network Review Description: Did you notice 262 42 in your mobile phone network search list at the last CCC events? Did you and your friends buy SIM cards at the PoC and help test the network by calling each other, or by calling through the bridge to the DECT network services? Did you ever wonder about the details of this open source test network, set up by a team of volunteers in the middle of the city? We would like to tell you all the details of the cell phone network we operate at 29C3, and show you some fancy graphs based on the network activity! We will describe the process of setting up the test network we operate at 29C3, what legal and technical challenges we have faced, and we will describe the actual installation at the CCH. We will also compare this with the 262 42 test networks that were operated using the same open source software but otherwise very different installations at CCC Camp 2011 and 28C3. We will go on to show various statistics that we collect from the network while it has been running. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Gsm: Cell Phone Network Review

Ipv6 Domain Scanner Description: In this video I will show you how to use dnsdict6. In this video I will use this tool on Google and getting subdomain with ipv6 and services. Dnsdict6 tool is very powerful fast and easy to use. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Ipv6 Domain Scanner

[h=1]"Red October" - part two, the modules[/h]GReAT Kaspersky Lab Expert Posted January 17, 14:21 GMT Earlier this week, we published our report on “Red October”, a high-level cyber-espionage campaign that during the past five years has successfully infiltrated computer networks at diplomatic, governmental and scientific research organizations. In part one, we covered the most important parts of the campaign: the anatomy of the attack, a timeline of the attacker’s operation, the geographical distribution of the victims, sinkhole information and presented a high level overview of the C&C infrastructure. Today we are publishing part two of our research, which comprises over 140 pages of technical analysis of the modules used in the operation. When analyzing targeted attacks, sometimes researchers focus on the superficial system infection and how that occurred. Sometimes, that is sufficient, but in the case of Kaspersky Lab, we have higher standards. This is why our philosophy is that it’s important to analyze not just the infection, but to answer three very important questions: What happens to the victim after they’re infected? What information is being stolen? Why is “Red October” such a big deal compared to other campaigns like Aurora or Night Dragon? According to our knowledge, never before in the history of ITSec has an cyber-espionage operation been analyzed in such deep detail, with a focus on the modules used for attack and data exfiltration. In most cases, the analysis is compromised by the lack of access to the victim’s data; the researchers see only some of the modules and do not understand the full purpose of the attack or what was stolen. To get around these hiccups, we set up several fake victims around the world and monitored how the attackers handled them over the course of several months. This allowed us to collect hundreds of attack modules and tools. In addition to these, we identified many other modules used in other attacks, which allowed us to gain a unique insight into the attack. The research that we are publishing today is perhaps the biggest malware research paper ever. It is certainly the most complex malware research effort in the history of our company and we hope that it sets new standards for what anti-virus and anti-malware research means today. Because of its size, we've split "part 2" in several pieces, to make reading easier: [h=2]First stage of attack[/h] Exploits Dropper Loader Module Main component [h=2]Second stage of attack[/h] Modules, general overview Recon group Password group Email group USB drive group Keyboard group Persistence group Spreading group Mobile group Exfiltration group Sursa: "Red October" - part two, the modules - Securelist

Vba32 AntiRootkit is designed to analyze the computer for the anomalies that arise due to the presence of malware in the system. Due to this, you will be able to detect and neutralize both the known and unknown viruses that are present in your system in active state. This program is a good assistant in the work of a specialist struggling with complicated infections. Vba32 AntiRootkit advantages: Free of charge Does not require installation Can be used with any antivirus software installed on your computer Uses a unique feature of the detection of "clean" files Can be used in several modes Supports the maintenance of a system status report in html format Treatment of the system may be done using a scripting language Supports Windows 7 Help files in Russian and English languages Part of Vba32 Personal and Vba32 Check To analyze the system is just enough to run the utility and click Start button, or select the menu File->Logging State (if you wish to get the report in the html format). Done! md5: 033aaa0c8d172d68e97c6e1cc3fb6461 sha1: 8872c8df8fa008a1222333b895ac6b42caefb347 Download FREE version Download User Guide (CHM, English) Discussion forum Sursa: Vba32 AntiRootkit | FREE Utilities | VirusBlokAda