Message-Id: <1363107808.12712.140661203394629.1AE57219@webmail.messagingengine.com>
Date: Tue, 12 Mar 2013 12:03:28 -0500
From: sec <sec@...tsploit.me>
To: full-disclosure@...ts.grok.org.uk
Subject: ASUS RT-N66U multiple vulns

Vulnerable product: ASUS RT-N66U
Vulnerabilities:
- Linux 2.6.22.19
- Old libraries and executables
Interesting vulnerabilities:
- "Hidden" root$ Samba share
- MiniUPnP confirmed listening on "WAN" interface
Workarounds:
- None official, may be able to fix things via telnet (undocumented)

All research performed on latest f/w ("3.0.0.4.270").

Contact timeline:
- 2013-02-19: Initial attempt to contact ASUS support.
- 2013-02-20:
   + "Escalated" support request acting on instructions from ASUS
   support.
   + Was asked to stop contacting ASUS.
   + Reiterated concerns about vulnerabilities, requested escalation to
   product engineers.
- 2013-02-2x: Misdirection, purposeful misunderstanding, handwaving,
denial from ASUS.
- 2013-02-27: Last-ditch effort to get ASUS to escalate or take
vulnerabilities seriously.
- 2013-03-12: Release to full-disclosure

Disclaimer: I was on a short timeline (product return to vendor window),
and didn't have a lot of time to analyze my results. And, of course, I
couldn't get any kind of support or confirmation of what I was seeing
from ASUS. Someone--who doesn't work for ASUS--with more time should
probably review my findings.

- The old kernel definitely seems to be unpatched. Any remote or local
vulnerabilities discovered in Linux post 2.6.22.19 almost certainly
apply unless they're platform-specific (i386/amd64 rather than MIPS32).
- None of the libs or executables appear to be patched. Major parts like
Samba appear three times in the source tarball, so trying to guess what
versions are running is definitely an exercise for someone with more
time. Safe to assume lots of unpatched vulns, I think.

More interestingly --

- There's a Samba "root$" share being exported, I think by default. Like
most things, the Samba definitions are stored in "nvram" (actually a
flash partition) rather than *.conf, so it's hard to be sure of the
exact permissions. I would assume the worst, especially given it's
explicitly referred to as "hidden". ASUS refused to discuss this with
me, or so I infer from their complete silence on the topic.

- Startlingly, MiniUPnP is actually the most recent version, but it's
listening on the "WAN" interface by default. I handed ASUS multiple
references to the recent reports of commodity routers with UPnP
listening on external interfaces. They took both a "definitely not
vulnerable" and "neither confirm nor deny" stance, depending which day
they were replying to me. I'm not sure which one takes priority over the
other. Once again assuming the worst.

Worth further investigation --

- The ASUS routers run a lot of in-house software that's probably not a
lot more secure than the rest of the device. See: wanduck (no idea),
networkmap (actively probes localhost, can't be disabled), u2ec
(something to do with USB printer sharing, can't be disabled).

- At least in "AP Mode", which is what I bought it for, I couldn't
change the WPS PIN from the factory default. Would anyone like to test
whether it's generated by MAC address?

- Despite having made the telnet-accessible environment as stupid and
useless as possible, it's at least possible to change settings via the
"nvram" util. May be possible to change the WPS PIN this way (it's in
there) along with a lot of the other insecure behavior.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists