Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
On 16 Mar 2014 23:36, T Imbrahim timbra...@techemail.com wrote: The thread read Google vulnerabilities with PoC. From my understanding it was a RFI vulnerability on YouTube, and I voiced my support that this is a vulnerability. I also explained a JSON Hijacking case as a follow up, and you said you didn't follow. So I am just saying that treating security that way, there are other parties like NSA who welcome them happily. I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock puppets. They are all first time posters from unusual free email providers jumping to defend the OP out of nowhere. If you search Google for their emails you only find references to this thread. They present similar (false and /or incorrect) arguments, talk about their extensive work experience, bash Google and its security team and send repeated emails with exactly the same text. This is turning into a madhouse... I hope this guy doesn't have access to a gun. Regards Pedro ___ 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] Fwd: Google vulnerabilities with PoC
On 17 Mar 2014 13:39, Źmicier Januszkiewicz ga...@tut.by wrote: Especially considering that all three use Tor to post on the list. I wonder why. Other header/content details can be interesting as well... Good catch, I didn't even remember checking the headers. Have a look at the comments posted in the softpedia article - I can smell more dirty socks in there. And for even more fun read his interview: http://m.softpedia.com/softpedia-interview-nicholas-lemonias-on-satellite-communication-vulnerabilities-420589.html He even posted it to this list but no one noticed it: http://marc.info/?l=full-disclosurem=139076233105401w=2 2014-03-17 10:24 GMT+01:00 Pedro Ribeiro ped...@gmail.com: On 16 Mar 2014 23:36, T Imbrahim timbra...@techemail.com wrote: The thread read Google vulnerabilities with PoC. From my understanding it was a RFI vulnerability on YouTube, and I voiced my support that this is a vulnerability. I also explained a JSON Hijacking case as a follow up, and you said you didn't follow. So I am just saying that treating security that way, there are other parties like NSA who welcome them happily. I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock puppets. They are all first time posters from unusual free email providers jumping to defend the OP out of nowhere. If you search Google for their emails you only find references to this thread. They present similar (false and /or incorrect) arguments, talk about their extensive work experience, bash Google and its security team and send repeated emails with exactly the same text. This is turning into a madhouse... I hope this guy doesn't have access to a gun. Regards Pedro ___ 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] Google vulnerabilities with PoC
On 13 Mar 2014 14:30, Nicholas Lemonias. lem.niko...@googlemail.com wrote: I suggest you to read on Content Delivery Network Architectures . YouTube.com populates and distributes stored files to multiple servers through a CDN (Content Delivery Architecture), where each video uses more than one machine (hosted by a cluster). Less populated video files are normally stored in various colocation sites. The YouTube architecture uses databases for storing metadata information of all uploaded files. https://www.owasp.org/index.php/Unrestricted_File_Upload Being a CDN means it is very hard to find out where your file went. I agree with was said on this thread by other people. As an external penetration testing consultant, I would put this on a client report as a low risk finding / possible vulnerability and recommend it to be fixed. As an internal vulnerability manager I would push the developers to fix it, but I would give it a low priority and only real press then once all the higher priority ones have been fixed. However in the real world it is not a vulnerability, and don't expect Google to pay you for it. Regards Pedro ___ 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] Google vulnerabilities with PoC
Keep in mind that YouTube allows files to be uploaded by definition. What you have achieved is upload a file for an extension type that is not allowed. It is definitely a vulnerability but a low risk one since you haven't demonstrated if it has any ill effects. Can you somehow find the URL to where the file was uploaded? I would guess not, since a well designed service like YouTube should hide those details and no leak them in any way. Maybe if you are able to find that you can combine with this vulnerability and get them to open their wallet? Regards Pedro On 13 Mar 2014 11:50, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Google vulnerabilities uncovered... http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml ___ 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/
[Full-disclosure] [CVE-2014-0334] XSS in CMS made simple, plus other security issues
Hi, CMS made simple has several security problems - XSS in admin console, weak CSRF protection and a possible PHP object insertion via unserialize. These vulnerabilities were considered unimportant by the CMS Made Simple developers. Their reasoning was that they had to be exploited by a logged in administrator user who is a trusted user anyway. When I explained to them that with XSS all you need to do is send a malicious link to the administrator, they responded back saying that they are confident in their CSRF protection. I then sent them an analysis of their CSRF protection (see the full advisory below), which I found to be quite weak. Finally they commited to implement a half-assed mitigation for the CSRF token weakness but said they will not fix the other issues. Timeline: - 27.11.2013: Initial contact to the emails listed in www.cmsmadesimple.com. No reply. - 03.12.2013: Message posted in the www.cmsmadesimple.com public forum asking to contact me back. A few hours later I was contacted by calguy and sent him a more complete version of this advisory with recommendations. - 09.12.2013: calguy responds saying these will not be fixed as you have to be an admin user anyway to exploit them. - 13.12.2013: After a few days arguing over email, Robert Campbell, CMS Made Simple project manager, responds with an official note saying they will double the CSRF token length in a future release but will not fix the rest of the issues. - 14.12.2013: Handed over to CERT asking for help to try to reason with the CMS Made Simple developers. - 28.02.2014: Public disclosure by CERT You can see the full report in my repo at https://github.com/pedrib/PoC/blob/master/cmsmadesimple-1.11.9.txt And the CERT report at http://www.kb.cert.org/vuls/id/526062 There are plenty of CMS out there that have a decent attitude towards security. Steer well clear of this one. Regards Pedro Ribeiro Agile Information Security ___ 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] [CVE-2014-2027] PHP objection insertion / arbitrary file deletion / possible RCE in egroupware = 1.8.005
Hi Egroupware = 1.8.005 contains a PHP object insertion vulnerability via unsafe use of the unserialize() function. There are lots of classes with magic methods which appear to be exploitable, some of them possibly for remote code execution. The advisory linked below contains an example of an arbitrary file deletion. The full report can be obtained from my repo in https://github.com/pedrib/PoC/raw/master/egroupware-1.8.005.txt The changelog can be seen at http://www.egroupware.org/changelog and new versions can be obtained from http://www.egroupware.org/download Regards Pedro ___ 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] [CVE-2014-1860] PHP object insertion / possible RCE in Contao CMS = 3.2.4
Hi, I have discovered a vulnerability that might lead to code execution in Contao CMS = 3.2.4 Contao CMS = 3.2.4 does not properly validate user input in several locations which is then passed directly into PHP's unserialize. This has been fixed in Contao 3.2.5 as per commit: https://github.com/contao/core/commit/8c9cb044bdc887a8202bb65a64545c025664f957 and https://github.com/contao/core/commit/1717336598fdcf1ed3f4ad488e140147cb31516d Announcements can be found at https://contao.org/en/news/contao-3_2_5.html https://contao.org/en/news/contao-2_11_14.html Thanks to the Contao developers for being so responsive. The full report can be found at my repo in https://github.com/pedrib/PoC/blob/master/contao-3.2.4.txt Regards, Pedro Ribeiro Agile Information Security ___ 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] [CVE-2014-1836] Arbitrary file deletion in ImpressCMS 1.3.6 and two XSS issues
Hi, I have discovered two vulnerabilities in ImpressCMS. These have been fixed in the new 1.3.6 version, which you can get at https://sourceforge.net/projects/impresscms/files/ImpressCMS%20Official%20Releases/ImpressCMS%201.3%20Branch/ImpressCMS%201.3.6/. One is an arbitrary file deletion and the other is two cross site scripting issues. Note that I was unable to exploit the XSS issues due to the inbuilt protection module, but someone smarter / with more time might be able to do it. The tickets containing the information are available here https://www.assembla.com/spaces/dW4voyNP0r4ldbeJe5cbLr/tickets?report%5Bestimate_show%5D=truereport%5Bid%5D=0report%5Bmilestone_id_cond%5D=1report%5Bmilestone_id_val%5D=4129593report%5Btitle%5D=All+Tickets+for+%27ImpressCMS+1.3.6%27report%5Btotal_estimate_show%5D=truereport%5Btotal_invested_hours_show%5D=truereport%5Bworking_hours_show%5D=true. The full report can be seen at my repo https://github.com/pedrib/PoC/blob/master/impresscms-1.3.5.txt Thanks in advance, and thanks to the ImpressCMS team for being so responsive. Regards, Pedro Ribeiro Agile Information Security ___ 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] [CVE-2013-6040] MW6 Technologies ActiveX buffer overflows and remote code execution
Hi,
MW6 Technologies (http://www.mw6tech.com/) is a manufacturer of
barcoding software. Among their products they have ActiveX controls to
process barcodes and labels.
I discovered that their ActiveX controls have multiple buffer
overflows, some of them leading to code execution.
I informed them in November last year, and they responded to me
basically saying that they don't care and won't fix it. I then asked
CERT to try to persuade them, but even with CERT asking them they
still didn't care.
CERT released the vulnerability details yesterday at
http://www.kb.cert.org/vuls/id/219470. In this post I will explain a
bit better what the problem is and how it can be exploited. The
excerpt below is from the original advisory sent to MW6.
===
Problem: The Data parameter is subject to a buffer overflow DEFINITELY
leading to arbitrary code execution.
COM Object - {2355C601-37D1-42B4-BEB1-03C773298DC8} MW6MaxiCode Class
File Description: MaxiCode ActiveX
File Version: 4, 0, 0, 1
To trigger the overflow enter a string larger than 4000 characters.
In the PoC (mw6maxicode.html) you see that Internet Explorer crashes
at trying to copy 42424242 to a register. By disassembling near the
crash location, you can see that both EAX and ECX can be manipulated
respectively with values 41414141 and 42424242. These are later used
to write operations leading to an arbitrary 4 byte write.
===
Problem: The Data parameter is subject to a buffer overflow DEFINITELY
leading to arbitrary code execution.
COM Object - {F359732D-D020-40ED-83FF-F381EFE36B54} MW6Aztec Class
File Description: Aztec ActiveX
File Version: 4, 0, 0, 1
To trigger the overflow enter a string larger than 9000 characters.
The attached PoC (mw6maztec.html) crashes when trying to read from
address 41414141. Further investigation shows that the value of EAX
030e20d0 is written into an arbitrary memory location, and this EAX
value is pointing to the Data buffer.
===
Problem: The Data parameter is subject to a buffer overflow PROBABLY
leading to arbitrary code execution.
COM Object - {DE7DA0B5-7D7B-4CEA-8739-65CF600D511E} MW6DataMatrix Class
File Description: DataMatrix ActiveX
File Version: 4, 0, 0, 1
To trigger the overflow enter a string larger than 1 characters.
This one I'm not 100% sure if I can control. The attached PoC
(mw6datamatrix.html) dies with the following message:
DATAMA_1!DllUnregisterServer+0xac5f:
02fbbcea 668984566c5c0100 mov word ptr [esi+edx*2+15C6Ch],ax
ds:0023:03006000=
The !exploitable windbg plugin says:
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - User Mode Write AV starting at
DATAMA_1!DllUnregisterServer+0xac5f
(Hash=0x3a50672d.0x5d486a2f)
User mode write access violations that are not near NULL are exploitable.
So the buffer overflow might be exploitable by someone willing to
spend more time on this.
===
All of these PoC were tested in Internet Explorer 8 and Windows XP
SP3. The PoC can be obtain from my repository at
https://github.com/pedrib/PoC in the folder mw6.
Regards,
Pedro Ribeiro
Director of Research
Agile Information Security
___
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] [CVE -2014-1201] Lorex security DVD ActiveX control buffer overflow
Hi, I have discovered a buffer overflow vulnerability that allows remote code execution in an ActiveX control bundled by a manufacturer of video surveillance systems. The company is Lorex Technologies, a major video surveillance manufacturer that is very popular in the US and East Asia. Their affected product range is the EDGE series, which has 16 products in it. I have confirmed that all 16 are vulnerable at this point in time. These security DVR's are remotely accessible, and when you access it on a Windows computer with Internet Explorer, they try to install the vulnerable ActiveX control INetViewX. The Lorex manual[1] instructs the user to blindly accept the ActiveX control install when prompted. The full list of devices, as well as links to the firware download, can be found in [2]. Their products offer remote video viewing capabilities, and you can find some of them on Shodan[3]. The buffer overflow can be triggered by a really long string (1+ characters) in the HTTP_PORT parameter. The instruction pointer can be very easily controlled in XP by the characters 109 to 113 in the string. Please refer to the PoC file lorex-testcase.html. You will see that the HTTP_PORT parameter is composed of D's, apart from chars 109 to 113 which are four A's. If you open this file in IE after installing the control, you will see that IE will crash with an EIP of 0x41414141. Changing the four A's to any other value will cause EIP to crash on that value. The list below tells a better story about what is affected and how it can be controlled: Win XP SP3 with IE6 - Fully exploitable as described Win XP SP3 with IE8 - Could not get it to crash () Win 7 x64 with IE10 fully patched - Fully exploitable, though not as easy as for XP (see analyze -v [4] and !exploitable [5] outputs) To verify this vulnerability you can download and extract the firmware using binwalk (http://code.google.com/p/binwalk/). To do so, please follow the instructions in [6], and then install the ActiveX control in INetViewProj1_02030330.cab. I have contacted Lorex and they initially said they would fix it, but went radio silent shortly afterwards. 17.11.2013 - Initial contact via support page 18.11.2013 - Email to sales, no response. 21.11.2013 - Second email to sales, received response by sales saying they will forward it to technical support and get back to me. 04.12.2013 - Third email to sales saying that technical support never contacted me back. No response. 08.01.2013 - MITRE assigns CVE-2014-1201 to this issue. 09.01.2013 - Public disclosure. All references can be found at: https://github.com/pedrib/PoC/lorexActivex/lorex-report.txt Proof of concept: https://github.com/pedrib/PoC/lorexActivex/lorex-testcase.html Regards, Pedro Ribeiro (ped...@gmail.com) Agile Information Security ___ 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] [CVE -2014-1201] Lorex security DVD ActiveX control buffer overflow
Can't seem to get github links to work, just go to the PoC repo and navigate from there if you are interested in seeing the files. On 9 Jan 2014 16:55, Pedro Ribeiro ped...@gmail.com wrote: Hi, I have discovered a buffer overflow vulnerability that allows remote code execution in an ActiveX control bundled by a manufacturer of video surveillance systems. The company is Lorex Technologies, a major video surveillance manufacturer that is very popular in the US and East Asia. Their affected product range is the EDGE series, which has 16 products in it. I have confirmed that all 16 are vulnerable at this point in time. These security DVR's are remotely accessible, and when you access it on a Windows computer with Internet Explorer, they try to install the vulnerable ActiveX control INetViewX. The Lorex manual[1] instructs the user to blindly accept the ActiveX control install when prompted. The full list of devices, as well as links to the firware download, can be found in [2]. Their products offer remote video viewing capabilities, and you can find some of them on Shodan[3]. The buffer overflow can be triggered by a really long string (1+ characters) in the HTTP_PORT parameter. The instruction pointer can be very easily controlled in XP by the characters 109 to 113 in the string. Please refer to the PoC file lorex-testcase.html. You will see that the HTTP_PORT parameter is composed of D's, apart from chars 109 to 113 which are four A's. If you open this file in IE after installing the control, you will see that IE will crash with an EIP of 0x41414141. Changing the four A's to any other value will cause EIP to crash on that value. The list below tells a better story about what is affected and how it can be controlled: Win XP SP3 with IE6 - Fully exploitable as described Win XP SP3 with IE8 - Could not get it to crash () Win 7 x64 with IE10 fully patched - Fully exploitable, though not as easy as for XP (see analyze -v [4] and !exploitable [5] outputs) To verify this vulnerability you can download and extract the firmware using binwalk (http://code.google.com/p/binwalk/). To do so, please follow the instructions in [6], and then install the ActiveX control in INetViewProj1_02030330.cab. I have contacted Lorex and they initially said they would fix it, but went radio silent shortly afterwards. 17.11.2013 - Initial contact via support page 18.11.2013 - Email to sales, no response. 21.11.2013 - Second email to sales, received response by sales saying they will forward it to technical support and get back to me. 04.12.2013 - Third email to sales saying that technical support never contacted me back. No response. 08.01.2013 - MITRE assigns CVE-2014-1201 to this issue. 09.01.2013 - Public disclosure. All references can be found at: https://github.com/pedrib/PoC/lorexActivex/lorex-report.txt Proof of concept: https://github.com/pedrib/PoC/lorexActivex/lorex-testcase.html Regards, Pedro Ribeiro (ped...@gmail.com) Agile Information Security ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
