Another SAPGui 7.40 0day
2017-02-21
Details will come soon(er or later depending on SAP's ignorance)
Exploiting a simple input field and getting code execution
2017-01-10
Remember the NNM exploit? Did you actually rewrote the egghunter by yourself? The calculator is now your best friend for sure.
Again a 0day... Despite I warned the developers last year, sent them the analysis, they released a new version of the software, with the exact same problems. Basically every input field is vulnerable to BOF.
Well now, I will show that it can even give me a shell. The PoC with a simple cmd is ready and working on Win 7 x64 (using the ascii encoded Win function() hunter).
I will not stop until I create a bind shell with only using ascii characters. Hopefully, I can achieve it. Thank god the devs "gave me" 5000 bytes to play with and a bit more if I need it.
Based on the NNM exploit, created in 2008, the same technique is stillvalid in 2017.
Will deliver the 0day with a shell once it is ready. It will definitely take "some" time.
Disabling DEP (nx) and ASLR in 32 bit and 64bit dlls and executables
2017-01-09
Again, simplifying complicated things is the goal. Experimented with a few tools, but powershell seems to be the proper "hexeditor" for this. This small code is also a payload candidate for the WoW64 Windows Function() hunter.
To be successful exploiting a binary with disabled DEP, you will need luck as well, to have OptIn as the setting of the OS. However, as ASLR is also turned off, you have much higher chance to create a workingROP chain in case the OS's nx setting is not "proper" one.
Check out the code on the Creations page.
Ideas how to shorten it even more, are welcome.
The aim is a short,fast and efficient code.
WoW64 Windows "factory" function() hunter is on the loose
2017-01-06
ASLR? Rebase? Please... That is the point, the somehow avoid the restrictions introduced by these security features. I have created it for Windows 7 SP1 Home x64, Windows 7 SP1 Pro x64, Windows Server 2008 R2 x64, Windows Server 2012 R2 x64, Windows 10 Pro x64 and Windows Server 2016 x64.
Tests were carried out on machines without EMET installed, and set DEP to reasonable option to let me live.The raw assembly code can be found at Creations
I grouped the codes to versions they work on. There are 3 groups, the two newest ones are already published. I will polish a little bit the Win7*+Win 2008 code and publish it shortly.
/* Win 7 + Win 2008 version of the code is now published - pay attention to the offsets while hunting for those functions */
The code was tested on a very broad range of dlls if it works how it should.
I am assuming, that you own the machine, or have permission to test such code. Knowing the exact OS version is the key to succeed with the code. For older OSs, probably the installed fixes also introduced changes to the offsets, so take that extra mile, and install the same OS locally to check for the offset.
Most probably the code can be improved, so feel free to contact me with suggestions.
TFTPD32 and TFTPD64 v4.52 - buffer overflow DoS
2017-01-06
As promised, things are coming slowly. Discovered it, had a great conversation with Philippe Jounin, he fixed the issue, and released v4.60 a few days ago which is DoS proof. No direct ret overwrite is possible or control of any registers. Prove me wrong, and teach me how it is being done.
The issue was, that a huge number of requests sent to the server overflowed the buffer which stored the error messages, and this caused a stack overwrite at one point.
FYI, the DoS only occurs on Win 7 and Win Server 2008 (R2). Of course others can be tested from around that era when these OSs were released.
SAPlpd is 0xDEADBEEF
2016-12-27
SAP SE has been notified and CVE request already sent.
The exploit will be only available once SAP confirmed the release of the fix. This vulnerabilityaffects tens of thousands of desktops and servers.
evil Update (2016-12-29) - No reply from SAP yet, so I had time to elevate the attack to a CVSS 10.0
pro Update (2016-12-30) - I have fixed the binary, however for legal reasons it can't be published
pro Update (2017-01-01) - Happy New Year Ladies and Gents! CVE ID assigned
pro Update (2017-01-05) - SAP acknowledged the report, now it is just the matter of time to have the fix
CVE-2016-10079 published - SAP is making controversial comments about releasing a fix and product maintenance. Dear SAP SE, next time do not waste my time with bs.
SAP HANA 2.0 rev 00 is in scope
2016-12-27
We'll see what happens with a 00 revision and patch level 00. The version levels are already promising.
Coming soon....
Don't expect big things, but they're on the way. Already contacted the developers/companies. Once communication gets rolling with them, I will disclose the details of the vulnerable software. If someone smarter checks and confirms my findings, that would be awesome...
If someone checks and brings them one step further and shows me the procedure, now that is the person who I call professor.
One thing is public, all of them are remote, unauthenticated exploits.
What's next?
If you have any software which you don't trust from security point of view, let me know, and I am sure we will agree how to proceed on its testing.
Make sure, that if you want me to disassemble the code and take a really deep look into it, I have the right to do it.
Many authors strictly disallow any kind of reverse engineering on their software to keep their bad code safe...until the moment, the code meets somebody, who has no fear to act against the law.
