[FD] Exploiting java deserialization vulnerabilities in crypto contexts - a java applet case-study
Hi, regardless of being a deprecated technology, there are still many legacy applications relying on java applets out there. A bit of time ago we were involved in an atypical web application penetration test. The difficulty consisted in the fact that the java serialized payload responsible for triggerring the vulnerability was located inside the authenticated part of a digital certificate, signed client-side with a private key stored in a HSM module. In case you are interested, the full story is here: https://www.redtimmy.com/web-application-hacking/how-we-invented-enumjavalibs-while-finding-a-java-deserialization-bug-and-achieving-rce/ ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] Web Application Firewall bypass via F5 Big-IP partial URI decoding
Hi we have published a new post in our blog titled "How to hack a company by circumventing its WAF for fun and profit – part 2". We basically shows how the absence of URI decondig or partial URI decoding can both be abused to circumvent custom iRules. Full story is here: https://www.redtimmy.com/web-application-hacking/how-to-hack-a-company-by-circumventing-its-waf-for-fun-and-profit-part-2/ regards RedTimmy Security ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Re: [FD] ELF launcher for encrypted binaries decrypted on-the-fly and executed in memory
in that case it should be enough to: - mmap(..., PROT_READ | PROT_WRITE | PROT_MAYREAD | PROT_MAYEXEC, ...) - store the decrypted code into the above mmap'ed area - mprotect(..., PROT_READ | PROT_EXEC) - execute the decrypted code from the mmap'ed area regards > > > Hey, > > mprotect(RWX)... this is not working in a properly hardened > environment (like grsecurity/PaX mprotect restrictions ;). > > Cheers, > > -h > > > On Tue, Mar 3, 2020 at 5:30 PM RedTimmy Security > wrote: > > > > Hi all, > > think about a typical Red Team operation, in which tools that commonly > > trigger security alerts to SOC, such as “procmon” or “mimikatz”, are > > uploaded in a compromised machine and then launched without having > > antivirus, antimalware or endpoint protection solutions complaining about > > that. > > > > There are several ways this could be achieved. The most comprehensive one > > is probably to encrypt the whole ".text" section of a binary and find a way > > to decrypt it on-the-fly in memory at runtime, just before the code is > > executed. The binary should live in encrypted form in the filesystem so > > that no static analysis would be possible even if identified and copied > > somewhere else. It should be only decrypted on the fly in memory when > > executed, in order to prevent dynamic analysis too, unless the decryption > > key is known. Easier to say than to do. > > > > First, "text" is not the only section where valuable information can be > > retrieved. The content of relocations and dynamic symbol tables are places > > to look at too. Their analysis is normally enough to reveal the nature of > > the binary itself. A way to circumvent this fact has to be found. > > > > Similarly, ".rodata" and ".data" are valuable sources of information and > > nothing more than the "strings" command is necessary to get this > > information out of a binary. For example when symbols are resolved at > > runtime with dlopen() and dlsyms(), the string of the function to be > > resolved lives in the ".rodata" section. > > > > We have considered all these factors and described a method for the > > decryption at runtime of ELF binaries in a blog post: > > https://www.redtimmy.com/red-teaming/blue-team-vs-red-team-how-to-run-your-encrypted-binary-in-memory-and-go-undetected/ > > > > The proof of concept code (golden-frieza project) can be found on github: > > https://github.com/redtimmy/golden-frieza > > > > regards > > > > ___ > > Sent through the Full Disclosure mailing list > > https://nmap.org/mailman/listinfo/fulldisclosure > > Web Archives & RSS: http://seclists.org/fulldisclosure/ ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] ELF launcher for encrypted binaries decrypted on-the-fly and executed in memory
Hi all, think about a typical Red Team operation, in which tools that commonly trigger security alerts to SOC, such as “procmon” or “mimikatz”, are uploaded in a compromised machine and then launched without having antivirus, antimalware or endpoint protection solutions complaining about that. There are several ways this could be achieved. The most comprehensive one is probably to encrypt the whole ".text" section of a binary and find a way to decrypt it on-the-fly in memory at runtime, just before the code is executed. The binary should live in encrypted form in the filesystem so that no static analysis would be possible even if identified and copied somewhere else. It should be only decrypted on the fly in memory when executed, in order to prevent dynamic analysis too, unless the decryption key is known. Easier to say than to do. First, "text" is not the only section where valuable information can be retrieved. The content of relocations and dynamic symbol tables are places to look at too. Their analysis is normally enough to reveal the nature of the binary itself. A way to circumvent this fact has to be found. Similarly, ".rodata" and ".data" are valuable sources of information and nothing more than the "strings" command is necessary to get this information out of a binary. For example when symbols are resolved at runtime with dlopen() and dlsyms(), the string of the function to be resolved lives in the ".rodata" section. We have considered all these factors and described a method for the decryption at runtime of ELF binaries in a blog post: https://www.redtimmy.com/red-teaming/blue-team-vs-red-team-how-to-run-your-encrypted-binary-in-memory-and-go-undetected/ The proof of concept code (golden-frieza project) can be found on github: https://github.com/redtimmy/golden-frieza regards ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] Web Application Firewall bypass via Bluecoat device
Hi, we have published a new post in our blog titled "How to hack a company by circumventing its WAF through the abuse of a different security appliance and win bug bounties". We basically have [ab]used a Bluecoat device behaving as a request forwarder to mask our malicious payload, avoid WAF detection, hit an HTTP endpoint vulnerable to RCE and pop out a shell. Full story is here: https://www.redtimmy.com/web-application-hacking/how-to-hack-a-company-by-circumventing-its-waf-through-the-abuse-of-a-different-security-appliance-and-win-bug-bounties/ regards RedTimmy Security ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] [EnumJavaLibs]_ Remote Java classpath enumerator
Hi, we have just released EnumJavaLibs to perform java classes enumeration against java services. To discover a deserialization vulnerability is often easy. When source code is available, it comes down to finding calls to readObject() and finding a way for user input to reach that function. In case we don’t have source code available, we can spot serialized objects on the wire by looking for binary blobs or base64 encoded objects (recognized by ‘rO0..’). The hard part comes with exploitation. Sure you can throw all exploits from ysoserial at it and hope for the best, but if it doesn’t work there are not much other things you can try. The big piece of information which is missing at this point, is information about the classpath of the remote application. If we know what libraries are loaded, we might be able to construct a gadget chain (or adjust the existing ysoserial exploit to match the version of the library on the remote application, for example). That’s where the idea of EnumJavaLibs came from: just let it deserialize arbitrary objects from different (popular) 3rd party java libraries. More specifically: - Create a local database of the most common Java libraries - For each of these libraries, find a class that is serializable - Create an instance of this object, serialize it, and send it to the remote application - If we get a ClassNotFoundException back, we know the library is not on the classpath At Redtimmy Sec we have released the code of this project on GitHub, together with a tool that can build a database of libraries (JavaClassDB.py). You can download the pre-compiled version from: https://github.com/redtimmy/EnumJavaLibs/raw/master/bin/EnumJavaLibs.jar. The source code is instead over here -> https://github.com/redtimmy/EnumJavaLibs A wider description of how the tool works in our blog -> https://www.redtimmy.com/uncategorized/remote-java-classpath-enumeration-with-enumjavalibs/ Regards ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
