1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

ASUS RT-N66U Firmware version 3.0.0.4.380.8228

Discussion in 'ASUSWRT - Official' started by wouterv, Mar 28, 2018.

  1. wouterv

    wouterv Very Senior Member

    Joined:
    Aug 4, 2013
    Messages:
    911
    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.
     
  2. Please support SNBForums! Just click on this link before you buy something from Amazon and we'll get a small commission on anything you buy. Thanks!
  3. hfm

    hfm Occasional Visitor

    Joined:
    Aug 19, 2013
    Messages:
    28
    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.

    [​IMG]
     
    Last edited: Apr 1, 2018
  4. wouterv

    wouterv Very Senior Member

    Joined:
    Aug 4, 2013
    Messages:
    911
    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.
     
  5. hfm

    hfm Occasional Visitor

    Joined:
    Aug 19, 2013
    Messages:
    28
    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.
     
  6. hfm

    hfm Occasional Visitor

    Joined:
    Aug 19, 2013
    Messages:
    28
    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

    Code:
    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
    
     
  7. hfm

    hfm Occasional Visitor

    Joined:
    Aug 19, 2013
    Messages:
    28
    It keeps getting better.. seems this was also enabled at some point...
    [​IMG]
     
  8. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    26,927
    Location:
    Canada
    It means you had the web interface open to the WAN, and someone hacked your router.
     
    hfm likes this.
  9. OzarkEdge

    OzarkEdge Senior Member

    Joined:
    Feb 14, 2018
    Messages:
    339
    Location:
    USA
    Have you used the ASUS Router app lately... it was secretly creating a DDNS client and enabling Web access?

    OE
     
    hfm likes this.
  10. hfm

    hfm Occasional Visitor

    Joined:
    Aug 19, 2013
    Messages:
    28
    That is literally the first thing I check after every firmware update. It was always disabled and still is.
     
  11. hfm

    hfm Occasional Visitor

    Joined:
    Aug 19, 2013
    Messages:
    28
    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.
     
  12. hfm

    hfm Occasional Visitor

    Joined:
    Aug 19, 2013
    Messages:
    28
    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..


    Code:
    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.
     
  13. hfm

    hfm Occasional Visitor

    Joined:
    Aug 19, 2013
    Messages:
    28
    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.
     
  14. hfm

    hfm Occasional Visitor

    Joined:
    Aug 19, 2013
    Messages:
    28
  15. OzarkEdge

    OzarkEdge Senior Member

    Joined:
    Feb 14, 2018
    Messages:
    339
    Location:
    USA

    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 likes this.
  16. hfm

    hfm Occasional Visitor

    Joined:
    Aug 19, 2013
    Messages:
    28
    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.
     
  17. OzarkEdge

    OzarkEdge Senior Member

    Joined:
    Feb 14, 2018
    Messages:
    339
    Location:
    USA
    Yeah, stupid bad. I have new found respect for proactively managing my router security on a regular basis, no thanks to ASUS.

    OE
     
  18. hfm

    hfm Occasional Visitor

    Joined:
    Aug 19, 2013
    Messages:
    28
    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.
     
    Last edited: Apr 1, 2018
  19. OzarkEdge

    OzarkEdge Senior Member

    Joined:
    Feb 14, 2018
    Messages:
    339
    Location:
    USA
    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! :eek:

    OE
     
  20. bbunge

    bbunge Senior Member

    Joined:
    Aug 11, 2014
    Messages:
    433
    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
     
  21. hfm

    hfm Occasional Visitor

    Joined:
    Aug 19, 2013
    Messages:
    28
    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

    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.
     
Please support SNBForums! Just click on this link before you buy something from Amazon and we'll get a small commission on anything you buy. Thanks!