Leaderboard

Dupa ce l-am ajutat pe sandabot, inregistrandu-i un domeniu gratis (vezi topicul: https://rstforums.com/forum/68045-imprumut-8-a.rst) , am primit cred ca vreo 15 PM-uri in aceeasi zi, de la membrii de pe forum, sa le inregistrez si lor un domeniu. Asa ca m-am decis sa impart metoda cu voi, se gaseste si pe forum-ul meu, postata de un user de pe forum.. Eu am folosit-o deja pentru 3 domenii si a mers brici. Domeniul este pentru 1 an. Tutorial Intram aici: Get Online - America Get Your Business Online 1. Apasam pe "Get on the web", dupa care pe Create your website -> Click 2. Sign in with Google -> Cu Gmail-u. 3. Dupa ce v-ati logat dati Continue. 4. OK , veti fi redirectionati la Intituit Website 5. Alegem: Choose a Domain (Yourname.com) for your website 6. Tastati ce nume vreti la site + domeniu. 7. Dupa ce ati terminat dati Get Domain (0.0$ deci ne trebe card) 8. Bagati datele cardului vostru real sau al unui prieten/coleg/cunoscut. 9. Congratulations your order is Complete. Gata ati facut domeniu. 10. Trebuie sa mutati NS-urile. Confirmarea contului se face in maxim 30m-1h. 11. Dupa ce v-a venit confirmarea si domeniu functioneaza dati la Edit DNS si configurati voi cum vreti mutati ns-urile astea la host-u vostru! Puteti sa folositi datele voastre reale, inclusiv Credit Card-ul, chiar e recomandat, cu exceptia numelui si a adresei, restul nu are nicio treaba, nu are de ce sa vie frica. Puteti folosi acelasi Credit Card, pentru mai multe domenii, la mine a mers. De unde pot face rost de Credit Card-uri? 1. Cel mai simlu si recomandat, folosit cardul vostru/fratelui/prietenului/colegului..... nu se intampla absolut nimic, si stati fara grija suspendarii contului. 2. Sper ca v-am ajutat , metoda merge 100% , am testat , este legala! Domeniul va functiona si nu va fi suspendat. Tutorial realizat de mine in totalitate!Daca doriti copierea acestuia postati si sursa.T-T! Video tutorial: PS: Puteti citi intreg topic-ul din sursa, in care sunt abordate mai multe probleme. Sursa: Thieves Team Programing&Security Board ? View topic - [METODA] Domenii gratis .com,.net,.biz,.info

Java Pwn2Own James Forshaw - 19th April 2013 inShare On 16th April Oracle released Java 7 Update 21 (which you should install now if you haven’t already!) This release fixes all the Java vulnerabilities disclosed to Oracle during the recent Pwn2Own 2013 competition held at the CanSecWest security conference in Vancouver on the 6th March 2013, alongside a significant number of other bugs. I was the first winner of the Java exploit competition at this event, and this blog provides an both an overview of my winning entry, and an insight into just how difficult it is to fully secure a complex system such as Java against a determined attacker. But let’s start with the bug itself, CVE-2013-1488, which is surprisingly innocuous and one which could easily be missed during a code security review. It was an issue I found in the java.sql.DriverManager class which is a trusted part of the framework. As the documentation states this class’s purpose is for “… managing a set of JDBC drivers.” and is an extensible Java framework for accessing relational databases. Within the source code> for this class a Java vulnerability hunter would be drawn to the two AccessController.doPrivileged blocks like a moth to a flame, they allow the Java libraries to temporarily elevate its privileges to perform a security critical action. The first block does not do very much (it simply gets a system property) but the second one is far more interesting: Figure 1 The reason this code is interesting is because it is performing a non-trivial task during this block of elevated privileges. Even more importantly, an attacker can directly interact with this process because of the use of the which will instantiate a sequence of objects from a manifest of class names provided in the applet’s JAR file: Figure 2 That in and of itself might not be massively helpful to an attacker, mainly because all objects that can created through this process have to implement the java.sql.Driver interface, so we cannot just find any arbitrary class and reuse it. We could try and find an existing driver which did something bad when created with its default ‘empty’ constructor, but doesn’t sound too likely either. But looking closer at the lines which are actually doing the work, there is something else interesting going on: Figure 3 Whilst it isn’t immediately obvious these lines are doing a lot more than they seem, the code is actually looping through an “iterator” which creates each object from a list of class names in turn via the reflection API Class.newInstance(). It then concatenates that object with a string and tries to log the result (ironically by default there is no log enabled and this result is thrown away). Whilst it isn’t explicit in the code, and thus might be missed unless you are paying close attention, what this is actually doing is calling the toString method on every object it creates during a privileged block. To say this is probably bad is maybe understating the issue, but what can we do with it? Exploiting this comes down to a variation of the “Trusted Method Chain” attack. This is a technique in platforms such as Java and .NET which allows an attacker to construct a chain of method calls from parts of the trusted Java class libraries and the JVM, which result in some action which circumvents security restrictions. I can’t claim credit for the discovery of this technique, and so for a better description in the Java world I would defer to the legendary Sami Koivu here. The reason you need to do this is because unsigned Java code running in the browser plugin is untrusted. If you try and perform a security critical action (such as opening a file) the security manager installed to protect the sandbox will notice you and stop the action. But if all the calls on the stack are trusted (i.e. from built in classes) then the manager will trust you to perform the action, leading to the potential for a sandbox escape. From this we need some way of going from a toString method call to a sandbox escape, and that doesn’t sound like it should be easy. But looking over the history of Java exploitation, it turns out there are a number of examples of doing just this, the previous link to Sami’s blog has one (fixed obviously) and there is another very well-known one related to the Rhino Javascript Engine, CVE-2011-3544 discovered by Michael Schierl (which is also fixed). So a similar technique might be worth pursuing in this case, perhaps if we could create a Javascript Error object in a similar fashion to CVE-2011-3544 it would work for us, we could get it called by DriverManager and we could escape the sandbox? But how could we do that, as I’ve just said this has been fixed? Well “yes”, but perhaps not in the way you would expect. The actual implementation of the Rhino Script Engine NativeError class wasn’t changed; instead the script engine code was modified to ‘capture’ the access control context under which it was instantiated during its default constructor. Any Javascript method is then run within an AccessController.doPrivileged block with the captured context, so that the Javascript code can only ever do as much damage as the thing which created it. This means that, if untrusted Java applet code created the engine, all Javascript would run at most with the applet’s permissions. However what if the engine was created by trusted code running with elevated permissions? Well, if we look at the code for the RhinoScriptEngine class we can actually see the fix in action: Figure 4 If running in a sandbox, the constructor checks whether it is running under a fully privileged context, if it isn’t then an exception occurs and the current context is captured, otherwise accCtxt is left as its default value of null. When it comes to running Javascript code, if accCtxt is null then it is run with the permissions of the direct caller, which is exactly the scenario we want, as it breaks the fix applied to solve CVE-2011-3544 and allows us to repurpose the same technique to create our trusted chain. It is worth noting that this isn’t actually the original fix, its behaviour resulted in a code change which made it less vulnerable to these attacks, but as I will demonstrate it didn’t matter for this vulnerability. So the final piece of the puzzle is how to create the RhinoScriptEngine class under a privileged context, well the answer has been staring us in the face all along: we can use our own ServiceLoader iterator combined with a Set class to create a trusted chain between the toString method and instantiation of the RhinoScriptEngine class. The reason this works is that the Set class’s toString method will iterate over the values of the iterator object, which, in turn, causes the ServiceLoader iterator to instantiate an attacker supplied list of objects. This list can then be recovered at a later time for the purposes of exploitation. Take, for example, the following class which implements the Driver interface and derives from AbstractSet but uses a “fake” iterator: Figure 5 When called by the DriverManager code the order of operations is as follows: Figure 6 Once the script engine object is created, we now just need a second driver which again derives from a Set class, this time we use it to call toString on our custom Error object, by adding it to the Set, and it’s “game over”: Figure 7 In conclusion, to exploit that single, seemingly innocuous bug required repurposing a massive amount of unrelated code to disable the security manager and therefore break out of the sandbox. I guess that is why Oracle considering it to have a Medium Access Complexity within the CVSSv2 scoring scheme. But that is also why I think something like Java can never be secured against hostile code running within a sandboxed environment: the attacker has too much control to craft the environment to exploit the tiniest of weaknesses. The large amount of “trusted” code bundled with the JRE just acts to amplify that power. Sursa: Context ? Information Security

[h=3]Yet Another Java Security Warning Bypass[/h]posted by: Nico Waisman Not so long ago we posted about a JavaSecurity Warning bypass that used a serialized applet instance. That bypass was fixed in Java 7 update 13 so we had to keep looking at new ways of defeating the warning pop-up that requires user interaction in order to run applets. We continued auditing the code that performed the checks when starting an applet and ended up arriving at the method “sun.plugin2.main.client.PluginMain.performSSVValidation(Plugin2Manager)” This method will end up calling some other methods in the com.sun.javaws.ui.SecureStaticVersioning class that will show us that annoying security warning pop up. But just take a quick look at the performSSVValidation method implementation: public static boolean performSSVValidation(Plugin2Manager paramPlugin2Manager) throws ExitException { boolean bool = Boolean.valueOf(paramPlugin2Manager. getParameter("__applet_ssv_validated")). booleanValue(); if (bool) return false; LaunchDesc localLaunchDesc = null; AppInfo localAppInfo = null; [...] // ... more code that calls com.sun.javaws.ui.SecureStaticVersioning to perform more checks [...] } What is that __applet_ssv_validated parameter?? Obviously this is an internal undocumented parameter and, as you can see, it turns out that if it is set to true, no checks are performed. The first thing we tried was to simply set that parameter to true in our evil applet, but it didn't work. While debugging we noticed that the parameter was not set on the applet despite our setting it to true. Basically sun.plugin2.main.server.MozillaPlugin.addParameter(String, String) is filtering the parameters: private void addParameter(String paramString1, String paramString2) { if ((paramString1 != null) && (paramString1.charAt(0) != '_') && (!paramString1.equals("PARAM"))) this.params.put(paramString1, paramString2); } But as you may know, Java provides another way of launching applets in a browser besides using the applet, object or embed tags. Java Web Start technology is what we can use. Now the applet description is provided by using a JNLP file and parameters can be set to the applet by using the <param> tag. We can see that when using Java Web Start, the performSSVValidation method is also called So lets try to launch an applet with Java Web Start and set the __applet_ssv_validated parameter to true with a JNLP file like this one: <?xml version="1.0" encoding="utf-8"?> <jnlp spec="1.0" xmlns:jfx="http://javafx.com" href="applet_security_bypass.jnlp"> <information> <title>Applet Test JNLP</title> <vendor>demo</vendor> <description>basic applet test</description> <offline-allowed/> </information> <resources> <j2se version="1.7" href="http://java.sun.com/products/autodl/j2se" /> <jar href="basicApplet.jar" main="true" /> </resources> <applet-desc name="Demo Applet" main-class="Main" width="1" height="1"> <param name="__applet_ssv_validated" value="true"></param> </applet-desc> <update check="background"/> </jnlp> And by know you have already realized that this just works and parameters are not filtered. The Security Warning pop-up message is not displayed and our applet happily runs! Ironically on Tuesday 16th April, exactly while I was at the Infiltrate MasterClass teaching how to audit and exploit Java, Oracle released update 21 which fixed this bypass and a ton of others. The time investment for stealthily exploiting Java is increasing but finding bypasses like this makes it worth the time! Esteban Guillardoy Sursa: Immunity Products: Yet Another Java Security Warning Bypass