search

CERTCC / PoC-Exploits

Select proof-of-concept exploits for software vulnerabilities to aid in identifying and testing vulnerable systems.
BSD 3-Clause "New" or "Revised" License
181 stars 47 forks source link

raise IndexError("Layer [%s] not found" % lname) #7

Closed dansmits closed 5 months ago

dansmits commented 3 years ago

Hello,

I am getting the following error when running your program:

Initiating communications with PPTP server 192.168.8.1 Traceback (most recent call last): File "/home/kali/Project/./pptp_poc.py", line 96, in <module> call_reply = PPTPOutgoingCallReply(call_reply) File "/usr/lib/python3/dist-packages/scapy/base_classes.py", line 266, in __call__ i.__init__(*args, **kargs) File "/usr/lib/python3/dist-packages/scapy/packet.py", line 158, in __init__ self.dissect(_pkt) File "/usr/lib/python3/dist-packages/scapy/packet.py", line 875, in dissect s = self.do_dissect(s) File "/usr/lib/python3/dist-packages/scapy/packet.py", line 839, in do_dissect s, fval = f.getfield(self, s) File "/usr/lib/python3/dist-packages/scapy/fields.py", line 163, in getfield return s[self.sz:], self.m2i(pkt, self.struct.unpack(s[:self.sz])[0]) File "/usr/lib/python3/dist-packages/scapy/packet.py", line 1185, in __getitem__ raise IndexError("Layer [%s] not found" % lname) Here is a link to the pcap file when I run against my pptp server: https://drive.google.com/file/d/14D3PgPk839ug_PXKhWLYS-qQDVAyQJ73/view?usp=sharing

Any help would be greatly appreciated!

sei-vsarvepalli commented 3 years ago

What version is your PPTP server and the backend PPP? If PPTP server is greater than 1.5 and ppp is above 2.4.5 , the negotiations are slightly different. The current PoC will not work.

Let me know. The PCAP jus shows PPTP offset length missing in the early negotiations. The last successful PPTP packet is 

    192.168.8.1.1723 > 192.168.38.133.51890: Flags [P.], cksum 0x502c (correct), seq 157:189, ack 325, win 64240, 
length 32: pptp Length=32 CTRL-MSG Magic-Cookie=1a2b3c4d CTRL_MSGTYPE=OCRP CALL_ID(2048) 
PEER_CALL_ID(4900) RESULT_CODE(1:Connected) ERR_CODE(0:None) CAUSE_CODE(0) 
CONN_SPEED(2147483648) RECV_WIN(16) PROC_DELAY(0) PHY_CHAN_ID(0)

Vijay

dansmits commented 3 years ago

Okay, pptpd is version 1.4.0 and pppd is version 2.4.7 What versions did you use for development? Is there a version of openwrt that would be compatible with your PoC?

dansmits commented 3 years ago

I tried running a VM of Ubuntu Server 14.04 with pptpd v1.3.4 and pppd v2.4.5 and still received the same error. Here is a link to a pcap of this attempt: https://drive.google.com/file/d/1IaaL9kmcQrb3lODQ2JSDq1L2yKbhsLIY/view?usp=sharing

sei-vsarvepalli commented 3 years ago

I tried running a VM of Ubuntu Server 14.04 with pptpd v1.3.4 and pppd v2.4.5 and still received the same error. Here is a link to a pcap of this attempt: https://drive.google.com/file/d/1IaaL9kmcQrb3lODQ2JSDq1L2yKbhsLIY/view?usp=sharing Dan, Let me try to run this setup that you have mimicked and get back to you.

Thanks Vijay

sei-vsarvepalli commented 3 years ago

I am able to recreate this problem. It looks like something is way different in the newer kernel handling of GRE packets. It might take me sometime to test with a few environments to get to the bottom of this. Will update this issue once I have more clarity.

Vijay

WittsEnd2 commented 3 years ago

Hello,

I am working with dansmits on this. I might have found a fix for the layers issue (below is the fix that I did); however, I am running into a new issue. I seem to make it all the way through to send the buffer overflow; however, it is not behaving as expected. Particularly, it seems that the PPTPD server is not expecting the EAP packet, and is discarding it. Would you happen to have any idea what this might be? A copy of the log is below.

# from line 96
print(bytes_hex(vr))
cstream.sr1(vr,verbose=debug)
call_reply = cstream.sr1(PPTPOutgoingCallRequest(call_id=call_id),verbose=debug)
# call_reply = PPTPOutgoingCallReply(call_reply)
call_id = format(raw(call_reply[0])[12], '02x') + format(raw(call_reply[0])[13], '02x')
print(call_id)
call_id = int(call_id.encode('utf-8'),16)
using channel 136
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth eap> <magic 0x7389f1a3>]
rcvd [LCP ConfReq id=0x1 <magic 0xaabbccdd>]
sent [LCP ConfAck id=0x1 <magic 0xaabbccdd>]
sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth eap> <magic 0x7389f1a3>]
sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth eap> <magic 0x7389f1a3>]
sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth eap> <magic 0x7389f1a3>]
sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth eap> <magic 0x7389f1a3>]
sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth eap> <magic 0x7389f1a3>]
sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth eap> <magic 0x7389f1a3>]
sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth eap> <magic 0x7389f1a3>]
sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth eap> <magic 0x7389f1a3>]
sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth eap> <magic 0x7389f1a3>]
rcvd [EAP Request id=0x0 MD5-Challenge <Value 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41> <Name "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Discarded non-LCP packet when LCP not open
rcvd [LCP EchoReq id=0x4]
Modem hangup
Connection terminated.
~
WittsEnd2 commented 3 years ago

To follow up, this is an attempt on the Mango-v2 with kernel version 3.025

sei-vsarvepalli commented 3 years ago

Hello @WittsEnd2

I am also triaging close to where you are. There is definitely new behavior in modem hangup happening looks like from ppp and not pptpd. Once I have more info I will update.

Thanks Vijay

sei-vsarvepalli commented 3 years ago

Hello @WittsEnd2

Tested this behavior as normal. You can install a broken version of pppd to check the overflow behavior. You can install of 2.4.8 from GitHub and test the buffer-overflow if needed.

You should see the log information if pppd is set to debug under /etc/ppp/pptpd-options 

May  6 17:26:58 rojo pppd[608743]: EAP: trimming really long peer name down

Please test it out and let me know. I will leave it open for a few days, after that merge to close this issue.

Vijay

WittsEnd2 commented 3 years ago

Hello @sei-vsarvepalli,

What configuration did you use? I am trying to test on a vulnerable device, but I an getting a response saying it it is not vulnerable using your new script. I had to change if pkt.getlayer(PPP).proto == 49699 to if pkt.getlayer(PPP).proto == 49185 in order to successfully get further.

@WittsEnd2

sei-vsarvepalli commented 3 years ago

I edited the ppp and recompiled it to become vulnerable again. I can recreate the crash, but may need to check again if the vulnerability is detected by the script. May need to modify the detection of crash in a different way.

Vijay

WittsEnd2 commented 3 years ago

What is your test environment/setup like? I probably didn't explain it clear enough, but I have a feeling that my configuration files for pppd/pptpd (e.g. /etc/ppp/pppd.conf) might be slightly off rather than the code itself. It probably doesn't help either that I am testing this off of a GL-mt300n-v2 mango haha.

sei-vsarvepalli commented 3 years ago

Hello @WittsEnd2 Here is my pptpd-options file. The crash may not always happen, especially your environment!

/etc/ppp# grep -v '^#' pptpd-options | sed '/^$/d'
name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
proxyarp
nodefaultroute
lock
nobsdcomp
novj
novjccomp
nologfd