ASUS RT-N66U Firmware version 3.0.0.4.380.8228

[wouterv]

ASUS RT-N66U Firmware version 3.0.0.4.380.8228
- Fixed information disclosure vulnerability. Thanks to Haitan Xiang and Fand Wang.
- Fixed CVE-2018-5721 Stack-base buffer overflow vulnerability
- Fixed CVE-2018-8826 remote code code execution vulnerability. Thanks to Chris Wood.
- Fixed CVE-2018-5999 HTTP authorization bypass and CVE-2018-6000. An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program
- Fixed remote code execution vulnerability. Thanks to David Maciejak of Fortinet's FortiGuard Labs

- Fixed CVE-2017-14491: DNS - 2 byte heap based overflow
- Fixed CVE-2017-14492: DHCP - heap based overflow
- Fixed CVE-2017-14493: DHCP - stack based overflow
- Fixed CVE-2017-14494: DHCP - info leak
- Fixed CVE-2017-14495: DNS - OOM DoS
- Fixed CVE-2017-14496: DNS - DoS Integer underflow
- Fixed CVE-2017-13704: Bug collision
- Fixed AiCloud 2.0 Reflected XSS Vulnerability. Thanks to Guy Arazi and Niv Levi contribution.

Thanks to Guy Arazi for following vulnerabilities.
- AiCloud 2.0 Stored XSS Share link manager.
- AiCloud 2.0 Reflected XSS - "share a link"
- Download Master HTTP service DoS vulnerability.
- Download Master Reflected XSS Main login.

 

[hfm]

It seemed like after installing this the PPTP VPN was turned on automatically with a random username and password?

Should I be concerned that I didn't notice this was on previously? Hacked?

I never turned it on, I only see anything PPTP related in the logs after I upgraded to this new version, but I do suppose it's possible it was enabled previously. I saved my logs off and disabled it. I usually go through and disable all the things I'm not suing: AI Cloud, VPN, etc..etc.. so I know I've made sure this was disabled in the past. A little scary if this just magically got enabled after the firmware upgrade.

 

[wouterv]

What was the previous firmware version?
I suggest to revert the router to factory defaults and manual configure it again with a new username, password and wireless passphrases.

 

[hfm]

What was the previous firmware version?
I suggest to revert the router to factory defaults and manual configure it again with a new username, password and wireless passphrases.

I was previously using the 11/1/2017 firmware. I have check multiple times a week for updates to the firmware so I find out about any updates within a day or two.

I was just wondering if anyone else that has upgraded to this version from the previous version noticed this magically enabled.

 

[hfm]

I have logs going back two years and I only see these PPTP errors in the log as of the update to this new version

Mar 30 03:52:32 pptpd[18454]: CTRL: EOF or bad error reading ctrl packet length.
Mar 30 03:52:32 pptpd[18454]: CTRL: couldn't read packet header (exit)
Mar 30 03:52:32 pptpd[18454]: CTRL: CTRL read failed
Mar 30 21:26:08 pptpd[31511]: CTRL: EOF or bad error reading ctrl packet length.
Mar 30 21:26:08 pptpd[31511]: CTRL: couldn't read packet header (exit)
Mar 30 21:26:08 pptpd[31511]: CTRL: CTRL read failed
Apr  1 07:28:58 pptpd[620]: MGR: dropped small initial connection
Apr  1 07:28:59 pptpd[24513]: CTRL: EOF or bad error reading ctrl packet length.
Apr  1 07:28:59 pptpd[24513]: CTRL: couldn't read packet header (exit)
Apr  1 07:28:59 pptpd[24513]: CTRL: CTRL read failed

 

[hfm]

It keeps getting better.. seems this was also enabled at some point...

 

[RMerlin]

It means you had the web interface open to the WAN, and someone hacked your router.

 

[OzarkEdge]

It keeps getting better.. seems this was also enabled at some point...

Have you used the ASUS Router app lately... it was secretly creating a DDNS client and enabling Web access?

OE

 

[hfm]

It means you had the web interface open to the WAN, and someone hacked your router.

That is literally the first thing I check after every firmware update. It was always disabled and still is.

 

[hfm]

Have you used the ASUS Router app lately... it was secretly creating a DDNS client and enabling Web access?

OE

AHHH.. I have used that once just to check it out. I suppose that is a possible angle. But as for the pptpd issue, I literally see zero logs for the pptpd daemon before this update I just performed.

 

[hfm]

UGH!

I have no idea how this happened but I found these in the log, starting on Feb 26... I NEVER NEVER NEVER open the web interface to the WAN, so I have no idea how this setting could have reverted miraculously. Unnerving.

It doesn't look like it will log an IP for a successful interface login though, since I don't see my own internal logins to the interface.. WHY? At least log successful UI logins, that would have been super helpful here. The logs are rather spartan to be honest. I suppose AT LEAST it was logging these "abnormal logins".

Also weird that if someone hacked it they didn't clear the logs? I'm truly baffled at how the setting would have gotten changed in the first place, but I just checked it and it was still disabled. This is REALLY odd. I would imagine if they could get to the router interface they might have been able to use another exploit to potentially completely bypass the login altogether. (I have a very strong password for the router.. ) Also my password wasn't changed, it's always worked. So if they were able to brute force that thing.. total props.. it should have taken years..

There are more logs in between these obviously, I just cherry picked all the failed attempts.. Removing IPs just because.. I have two years of logs but these just started happening on Feb 26. I did the last firmware update back in Nov/Dec when the previous version dropped and I know I double checked the WAN setting afterward, I always do... SIGH..

Feb 26 16:52:17 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Feb 26 16:52:20 httpd login lock: Detect abnormal logins at 5 times. The newest one was from xx.xx.xx.xx in login.
Mar 14 14:20:52 httpd login lock: Detect abnormal logins at 5 times. The newest one was from xx.xx.xx.xx in login.
Mar 14 19:27:01 httpd login lock: Detect abnormal logins at 5 times. The newest one was from xx.xx.xx.xx in login.
Mar 16 10:36:55 httpd login lock: Detect abnormal logins at 5 times. The newest one was from xx.xx.xx.xx in login.
Mar 18 09:28:59 httpd login lock: Detect abnormal logins at 5 times. The newest one was from xx.xx.xx.xx in login.
Mar 22 13:45:53 httpd login lock: Detect abnormal logins at 5 times. The newest one was from xx.xx.xx.xx in login.

 

[hfm]

WELP.. I just found this, which was fixed in the latest firmware

https://github.com/pedrib/PoC/blob/master/advisories/asuswrt-lan-rce.txt
Fixed CVE-2018-5999 HTTP authorization bypass and CVE-2018-6000. An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program

This could definitely be the culprit, it still doesn't explain how the interface was even available over the WAN.

 

[hfm]

Checking out this thread (thanks @OzarkEdge) for the mention.
https://www.snbforums.com/threads/asus-router-app-security-warning.42819/

I just tried this app again and I do not see it enabling WAN acccess, however. Would it be possible that this app was the "client" that enabled PPTP VPN?

Sorry for the thread spam I'm just live-posting my research at this point, had to drop it for a family thing.

 

[OzarkEdge]

Checking out this thread (thanks @OzarkEdge) for the mention.
https://www.snbforums.com/threads/asus-router-app-security-warning.42819/

I just tried this app again and I do not see it enabling WAN acccess, however. Would it be possible that this app was the "client" that enabled PPTP VPN?

Sorry for the thread spam I'm just live-posting my research at this point, had to drop it for a family thing.

Yes, I believe so. The app should be patched now, but I'll never use it. App updates are always breaking something... I don't need it breaking my firewall. Conceptually, it's an appealing tool, but it's on a ridiculous platform... at least Android is.

OE

 

[hfm]

Well I just uninstalled and reinstalled the Asus App.. and the "previous" router configuration that is available in the app (it seems it cached this and kept it even through uninstalling/reinstalling the app) and that config DOES have "remote connection" and DDNS enabled. I probably just didn't even realize the app changed those things without telling me.

Wow.. just wow. I guess there's how the interface was sitting there ready for exploit. I suppose it's possible that upgrading the firmware reverted the WAN access back to disabled and it was still disabled when I checked. Either that or whoever used that exploit to configured PPTP VPN then disabled it so no other hacker would "steal" their hacked device.

At any rate, this was bad.

 

[OzarkEdge]

Well I just uninstalled and reinstalled the Asus App.. and the "previous" router configuration that is available in the app (it seems it cached this and kept it even through uninstalling/reinstalling the app) and that config DOES have "remote connection" and DDNS enabled. I probably just didn't even realize the app changed those things without telling me.

Wow.. just wow. I guess there's how the interface was sitting there ready for exploit. I suppose it's possible that upgrading the firmware reverted the WAN access back to disabled and it was still disabled when I checked. Either that or whoever used that exploit to configured PPTP VPN then disabled it so no other hacker would "steal" their hacked device.

At any rate, this was bad.

Yeah, stupid bad. I have new found respect for proactively managing my router security on a regular basis, no thanks to ASUS.

OE

 

[hfm]

Wouldn't I see successful PPTP VPN connections in the log if it had ever been used?

Yes I just set up a secondary one and I see in the logs where I connected to it. Guessing it was never used.

Man Asus needs to log more stuff in their logs. Successful posts to the UI would be a really nice thing to see in the logs. It would be nice to have the option to turn on more verbose logging if desired.

 

[OzarkEdge]

Wouldn't I see successful PPTP VPN connections in the log if it had ever been used?

Yes I just set up a secondary one and I see in the logs where I connected to it. Guessing it was never used.

Probably so. When it happened to me last week, I immediately discovered 'remote access enabled' in the app interface, so I immediately fixed it at the router and ditched the app... I didn't stop to check any logs!

OE

 

[bbunge]

Have not had issues with either the iOS or Android Asus router app in several months. Did have one case where ddns was turned on with a generated name and WAN access turned on.Has not happened since that one time.
Make sure you have app update turned on for your phone or tablet. I use the Asus apps daily with no problems!

Sent from my P01M using Tapatalk

 

[hfm]

I started thinking about this again. I did a grep on pptp in the logs to see the first logged (I have logs going back 2 years on the system) pptp event.. This is what I came up with

# first logs for pptpd in the log stream..session?
Mar 24 16:25:09 pptpd[26737]: CTRL: EOF or bad error reading ctrl packet length.
Mar 24 16:25:09 pptpd[26737]: CTRL: couldn't read packet header (exit)
Mar 24 16:25:09 pptpd[26737]: CTRL: CTRL read failed

# session? Oddly interesting packets inbound here..
Mar 26 23:43:54 pptpd[17159]: MGR: initial packet length 5635 outside (0 - 220)
Mar 26 23:43:57 pptpd[17159]: MGR: dropped small initial connection
Mar 26 23:43:58 pptpd[3023]: CTRL: EOF or bad error reading ctrl packet length.
Mar 26 23:43:58 pptpd[3023]: CTRL: couldn't read packet header (exit)
Mar 26 23:43:58 pptpd[3023]: CTRL: CTRL read failed

# session?
Mar 27 21:50:42 pptpd[19435]: CTRL: EOF or bad error reading ctrl packet length.
Mar 27 21:50:42 pptpd[19435]: CTRL: couldn't read packet header (exit)
Mar 27 21:50:42 pptpd[19435]: CTRL: CTRL read failed

# same errors appear down below for good session?
Mar 28 05:22:15 pptpd[25147]: CTRL: EOF or bad error reading ctrl packet length.
Mar 28 05:22:15 pptpd[25147]: CTRL: couldn't read packet header (exit)
Mar 28 05:22:15 pptpd[25147]: CTRL: CTRL read failed

# reboots , FW upgrade here I think.. Easy to see due to ntp sync
Aug 1 00:00:18 pptpd[331]: MGR: Config file not found!
Mar 29 04:15:49 rc_service: udhcpc 475:notify_rc stop_pptpd
Mar 29 04:15:50 rc_service: udhcpc 475:notify_rc start_pptpd
Mar 29 04:15:50 rc_service: waitting "stop_pptpd" via udhcpc ...
Mar 29 04:15:51 rc_service: udhcpc 556:notify_rc stop_pptpd
Mar 29 04:15:51 rc_service: udhcpc 556:notify_rc start_pptpd
Mar 29 04:15:51 rc_service: waitting "stop_pptpd" via udhcpc ...
Mar 29 04:15:51 pptpd[683]: MGR: Config file not found!
Mar 29 04:15:52 pptpd[731]: MGR: Config file not found!
Mar 29 04:15:53 pptpd[733]: MGR: Couldn't create host socket
Mar 29 04:15:53 pptpd[733]: createHostSocket: Address already in use

# reboot.. notice NTP synced after this Config file error..
Aug 1 00:00:15 pptpd[332]: MGR: Config file not found!
Mar 29 04:20:34 rc_service: udhcpc 370:notify_rc stop_pptpd
Mar 29 04:20:34 rc_service: udhcpc 370:notify_rc start_pptpd
Mar 29 04:20:34 rc_service: waitting "stop_pptpd" via udhcpc ...
Mar 29 04:20:35 pptpd[618]: MGR: Config file not found!

# session?
Mar 30 03:52:32 pptpd[18454]: CTRL: EOF or bad error reading ctrl packet length.
Mar 30 03:52:32 pptpd[18454]: CTRL: couldn't read packet header (exit)
Mar 30 03:52:32 pptpd[18454]: CTRL: CTRL read failed

# session?
Mar 30 21:26:08 pptpd[31511]: CTRL: EOF or bad error reading ctrl packet length.
Mar 30 21:26:08 pptpd[31511]: CTRL: couldn't read packet header (exit)
Mar 30 21:26:08 pptpd[31511]: CTRL: CTRL read failed

# session?
Apr 1 07:28:58 pptpd[620]: MGR: dropped small initial connection
Apr 1 07:28:59 pptpd[24513]: CTRL: EOF or bad error reading ctrl packet length.
Apr 1 07:28:59 pptpd[24513]: CTRL: couldn't read packet header (exit)
Apr 1 07:28:59 pptpd[24513]: CTRL: CTRL read failed

# weird this one is hanging out by itself.. probably happened when I changed a setting (added account..)
Apr 1 20:57:58 pptpd[5701]: MGR: Config file not found!


# I connected myself here from my phone
Apr 1 20:59:51 pptp[5761]: pppd 2.4.7 started by admin, uid 0
Apr 1 20:59:51 pptp[5761]: Connect: ppp10 <--> pptp (xxx.xxx.xxx.xxx)
Apr 1 20:59:54 pptp[5761]: MPPE 128-bit stateless compression enabled
Apr 1 20:59:57 pptp[5761]: Cannot determine ethernet address for proxy ARP
Apr 1 20:59:57 pptp[5761]: local IP address xxx.xxx.xxx.xxx
Apr 1 20:59:57 pptp[5761]: remote IP address xxx.xxx.xxx.xxx
# notice these events are the same ones in the previous logs that had no "Connect"
Apr 1 21:01:45 pptpd[5760]: CTRL: EOF or bad error reading ctrl packet length.
Apr 1 21:01:45 pptpd[5760]: CTRL: couldn't read packet header (exit)
Apr 1 21:01:45 pptpd[5760]: CTRL: CTRL read failed
Apr 1 21:01:48 pptp[5761]: Connection terminated.
Apr 1 21:01:48 pptp[5761]: Modem hangup
# there's no more past this as I disabled it...

I only have a couple explanations of what the odd pptp log events could be.

1. Port scanners? Does it not create a Connect since it never got an established connection on the protocol?
2. I would imagine privilege escalation could mean someone could remove log lines... but then why wouldn't they all be removed, easiest way to do that would be remove any log line containing pptp before disconnecting every session.. doesn't jive..that there's any left over from a historical standpoint.. EDIT: HAH.. if they were grepping "pptp\[[0-9]+\]" lines and not just straight "pptp" string,.. that could explain the leftover logs...
3. some random junk it logs from time to time..

I also scoured through my NAS logs, I find no evidence of any connections to shared volumes etc.. from IPs that shouldn't normally connect to any of those services.