[Full-disclosure] List Charter

[John Cartwright]

[Full-Disclosure] Mailing List Charter
John Cartwright 
 

- Introduction & Purpose -

This document serves as a charter for the [Full-Disclosure] mailing 
list hosted at lists.grok.org.uk.

The list was created on 9th July 2002 by Len Rose, and is primarily 
concerned with security issues and their discussion.  The list is 
administered by John Cartwright.

The Full-Disclosure list is hosted and sponsored by Secunia.


- Subscription Information -

Subscription/unsubscription may be performed via the HTTP interface 
located at http://lists.grok.org.uk/mailman/listinfo/full-disclosure.

Alternatively, commands may be emailed to 
full-disclosure-requ...@lists.grok.org.uk, send the word 'help' in 
either the message subject or body for details.

 
- Moderation & Management -

The [Full-Disclosure] list is unmoderated. Typically posting will be
restricted to members only, however the administrators may choose to 
accept submissions from non-members based on individual merit and 
relevance.

It is expected that the list will be largely self-policing, however in
special circumstances (eg spamming, misappropriation) then offending 
members may be removed from the list by the management.

An archive of postings is available at 
http://lists.grok.org.uk/pipermail/full-disclosure/.
 

- Acceptable Content -

Any information pertaining to vulnerabilities is acceptable, for 
instance announcement and discussion thereof, exploit techniques and 
code, related tools and papers, and other useful information.

Gratuitous advertisement, product placement, or self-promotion is 
forbidden.  Disagreements, flames, arguments, and off-topic discussion 
should be taken off-list wherever possible.

Humour is acceptable in moderation, providing it is inoffensive. 
Politics should be avoided at all costs.

Members are reminded that due to the open nature of the list, they 
should use discretion in executing any tools or code distributed via
this list.
 

- Posting Guidelines -

The primary language of this list is English. Members are expected to 
maintain a reasonable standard of netiquette when posting to the list. 

Quoting should not exceed that which is necessary to convey context, 
this is especially relevant to members subscribed to the digested 
version of the list.

The use of HTML is discouraged, but not forbidden. Signatures will 
preferably be short and to the point, and those containing 
'disclaimers' should be avoided where possible.

Attachments may be included if relevant or necessary (e.g. PGP or 
S/MIME signatures, proof-of-concept code, etc) but must not be active 
(in the case of a worm, for example) or malicious to the recipient.

Vacation messages should be carefully configured to avoid replying to 
list postings. Offenders will be excluded from the mailing list until 
the problem is corrected.

Members may post to the list by emailing 
full-disclosure@lists.grok.org.uk. Do not send subscription/
unsubscription mails to this address, use the -request address 
mentioned above.


- Charter Additions/Changes -

The list charter will be published at 
http://lists.grok.org.uk/full-disclosure-charter.html.

In addition, the charter will be posted monthly to the list by the 
management.

Alterations will be made after consultation with list members and a 
consensus has been reached.

___
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] Is there a open source (tool) that is similar to cuckoo for analyzing android APK

[noname]

On 01/11/2013 05:27 AM, ??? wrote:
>
> Is there a open source (tool) that is similar to cuckoo for analyzing
> android APK?
>
> I know this site (http://anubis.iseclab.org/), but I hope to find
> virtual machine.
>
> Use the link below to report this message as spam.
> https://lavabit.com/apps/teacher?sig=3960223&key=1452462795
> 
>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
I know about these three. Haven't really used anything but androguard
though, so can't tell how much use these will be to you.
http://code.google.com/p/androguard/
http://code.google.com/p/apkinspector/
http://code.google.com/p/droidbox/ - sandbox tool for dynamic Android
malware analysis.
___
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] http://www.heise.de - Cross-site Scripting vulnerability

[osaft]

On Thu, 10 Jan 2013 19:47:25 +0100
Stefan Schurtz  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Advisory: heise.de - Cross-site Scripting vulnerability
> Advisory ID:  SSCHADV2013-002
> Author:   Stefan Schurtz
> Affected Software:Successfully tested on heise.de
> Vendor URL:   http://www.heise.de
> Vendor Status:fixed
> 
> ==
> Vulnerability Description
> ==
> 
> http://www.heise.de is prone to a XSS vulnerability
> 
> ==
> PoC-Exploit
> ==
> 
> http://www.heise.de/foto/galerie/suche/photo/?suchwort=";
> onMouseMove=alert(document.cookie) '
> 
> ==
> Solution
> ==
> 
> fixed
> 
> ==
> Disclosure Timeline
> ==
> 
> 03-Jan-2013 - informed heise Security
> 04-Jan-2012 - fixed by developer
> 
> ==
> Credits
> ==
> 
> Vulnerability found and advisory written by Stefan Schurtz.
> 

Now thats valeable information. Thank god that you informed about this
groundbreaking issue, Stefan. I will update my personal heise.de right
away.

___
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] Multiple vulnerabilities in Floating Tweets for WordPress

[MustLive]

Hello list!

I want to warn you about multiple vulnerabilities in plugin Floating Tweets 
for WordPress.

These are Full path disclosure, Directory Traversal and Cross-Site Scripting 
vulnerabilities.

-
Affected products:
-

Vulnerable are Floating Tweets 1.0.1 and previous versions.

--
Details:
--

Full path disclosure (WASC-13):

http://site/wp-content/plugins/floating-tweets/dcwp_floating_tweets.php

http://site/wp-content/plugins/floating-tweets/dcwp_floating_tweets_widget.php

http://site/wp-content/plugins/floating-tweets/skin.php?skin=1

Directory Traversal (Windows) (WASC-33):

http://site/wp-content/plugins/floating-tweets/skin.php?widget_id=2&skin=1\1

DT allows to read only css-files (in folder /skins/ and subfolders). At 
turned off mq it's possible to use Null Byte Injection, which allows via DT 
to read arbitrary files.

XSS (persistent XSS) (WASC-08):

Three persistent XSS holes. For attack it's needed to bypass protection 
against CSRF (parameter savewidgets). E.g. using reflected XSS.

Floating Tweets XSS.html


http://site/wp-admin/admin-ajax.php"; 
method="post">









Floating Tweets XSS-2.html


http://site/wp-admin/admin-ajax.php"; 
method="post">









Floating Tweets XSS-3.html


http://site/wp-admin/admin-ajax.php"; 
method="post">









Examples of attack for these three XSS on IE7 and previous versions. With 
using of MouseOverJacking it's possible to attack any browsers. The code 
will execute right away at sending request and further at visiting 
http://site/wp-admin/widgets.php.

Floating Tweets XSS-4.html


http://site/wp-admin/admin-ajax.php"; 
method="post">









Example of attack on any browsers. The code will execute at main page and at 
any external pages of the site.


Timeline:
 

2012.08.30 - announced at my site.
2012.08.31 - informed developer.
2013.01.11 - disclosed at my site (http://websecurity.com.ua/6023/).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua 


___
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] Is there a open source (tool) that is similar to cuckoo for analyzing android APK

[김무성]

Is there a open source (tool) that is similar to cuckoo for analyzing android 
APK?
I know this site (http://anubis.iseclab.org/), but I hope to find virtual 
machine.
___
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] how to sell and get a fair price

[Źmicier Januszkiewicz]

Hey Mikhail,

Nice idea! Although it does not fit very well with "Information must be
free" principle I feel we all love and care about.

That aside, there are a few key stones missing in your arc, namely --
quality and trust. Nobody wants to pay for crap, you know, and right now I
just don't see how this trust and quality level could be established in
your project. I wouldn't pay j0nnyh4x0r for something I cannot read (and
allowing to read the info before buying just kills the whole point, isn't
it? Read-fix-release... no money spent), and for well-known and trustworthy
persons... why not just hire them and be happy?

So let's see how you would patch this vulnerability in your idea! ;-)

P.S. No offense intended.

Cheers,
Ź.

2013/1/10 Mikhail A. Utin 

> ** **
>
> List,
>
> Here is the link to Information Security Magazine issue with “Market for
> vulnerability information grows – Cashing on Zero-day exploits” for your
> information.
>
> I once shared my idea that ZDI is not right way to go. It should be a
> market place (web portal) for selling vulnerabilities based on action
> price. Like eBay. That would be the place to get fair price for your hard
> work and skills. I would like to see HP and MS betting on 0-days. After
> all,a  vulnerability and an exploit are intellectual products. Not sure
> copyright could be claimed, but why not?
>
> ** **
>
> http://www.bitpipe.com/data/demandEngage.action?resId=1354307828_722
>
> ** **
>
> Enjoy
>
> * *
>
> *Mikhail*
>
> CONFIDENTIALITY NOTICE: This email communication and any attachments may 
> contain confidential
> and privileged information for the use of the designated recipients named 
> above. If you are
> not the intended recipient, you are hereby notified that you have received 
> this communication
> in error and that any review, disclosure, dissemination, distribution or 
> copying of it or its
> contents is prohibited. If you have received this communication in error, 
> please reply to the
> sender immediately or by telephone at (617) 426-0600 and destroy all copies 
> of this communication
> and any attachments. For further information regarding Commonwealth Care 
> Alliance's privacy policy,
> please visit our Internet web site at http://www.commonwealthcare.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/

[Full-disclosure] DefenseCode Security Advisory (UPCOMING): Cisco Linksys Remote Preauth 0day Root Exploit

[DefenseCode]

DefenseCode Security Advisory (UPCOMING): Cisco Linksys Remote Preauth 
0day Root Exploit

Story behind the vulnerability...

Months ago, we've contacted Cisco about a remote preauth (root access) 
vulnerability
in default installation of their Linksys routers that we've discovered. 
We gave them
detailed vulnerability description along with the PoC exploit for the 
vulnerability.

They said that this vulnerability was already fixed in latest firmware 
release...
Well, not this particular vulnerability, since the latest official 
Linksys firmware -
4.30.14, and all previous versions are still vulnerable.

Exploit shown in this video has been tested on Cisco Linksys WRT54GL, 
but other
Linksys versions/models are probably also affected.
Cisco Linksys is a very popular router with more than 70,000,000 routers 
sold.
That's why we think that this vulnerability deserves attention.

According to our vulnerability disclosure policy, the vulnerability 
details will be
disclosed in following 2 weeks on http://www.defensecode.com/ , BugTraq and
Full Disclosure.
Due to the severity of this vulnerability, once again we would like to 
urge Cisco
to fix this vulnerability.

The vulnerability is demonstrated in the following video:
http://www.youtube.com/watch?v=cv-MbL7KFKE&hd=1

Kind Regards,
DefenseCode LTD.
E-mail: defensecode[at]defensecode.com
Website: http://www.defensecode.com
Advisory URL: 
http://www.defensecode.com/article/upcoming_cisco_linksys_remote_preauth_root_exploit-33

___
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] [SE-2012-01] 'Fix' for Issue 32 exploited by new Java 0-day code

[Security Explorations]

Hello All,

We were notified today of ongoing attacks with the use of a new
Java vulnerability affecting latest version 7 Update 10 of the
software [1][2].

Due to the unpatched status of Issue 50 [3] and some inquiries
received regarding whether the attack code found exploited this
bug, we had a quick look at the exploit code found in the wild.
Below, we are providing you with the results of our analysis.

The 0-day attack code that was spotted in the wild today is yet
another instance of Java security vulnerabilities that stem from
insecure implementation of Reflection API [4].

The new attack is a combination of two vulnerabilities. The first
flaw allows to load arbitrary (restricted) classes by the means
of findClass method of com.sun.jmx.mbeanserver.MBeanInstantiator
class. This can be accomplished by the means of this code:

   public static Class loadClass(String name) throws Throwable {
 JmxMBeanServerBuilder jmxbsb=new JmxMBeanServerBuilder();
 JmxMBeanServer 
jmxbs=(JmxMBeanServer)jmxbsb.newMBeanServer("",null,null);
 MBeanInstantiator mbi=jmxbs.getMBeanInstantiator();

 return mbi.findClass(name,(ClassLoader)null);
   }

The problem stems from insecure call to Class.forName() method.

The second issue abuses the new Reflection API to successfully
obtain and call MethodHandle objects that point to methods and
constructors of restricted classes. This second issue relies on
invokeWithArguments method call of java.lang.invoke.MethodHandle
class, which has been already a subject of a security problem
(Issue 32 that we reported to Oracle on Aug 31, 2012).

The company had released a fix for Issue 32 in Oct 2012. However,
it turns out that the fix was not complete as one can still abuse
invokeWithArguments method to setup calls to invokeExact method
with a trusted system class as a target method caller. This time
the call is however done to methods of new Reflection API (from
java.lang.invoke.* package), of which many rely on security checks
conducted against the caller of the target method.

Oracle's fix for Issue 32 relies on a binding of the MethodHandle
object to the caller of a target method / constructor if it denotes
a potentially dangerous Reflection API call. This binding has a
form of injecting extra stack frame from a caller's Class Loader
namespace into the call stack prior to issuing a security sensitive
method call. Calls to blacklisted Reflection APIs are detected with
the use of isCallerSensitive method of MethodHandleNatives class.
The blacklisting however focuses primarily on Core Reflection API
(Class.forName(), Class.getMethods(), etc.) and does not take into
account the possibility to use new Reflection API calls. As a result,
the invokeWithArguments trampoline used in the context of a system
(privileged) lookup object may still be abused for gaining access to
restricted classes, their methods, etc.

The above is important in the context of a security check that is
implemented by the Lookup class. Its checkSecurityManager method
compares the Class Loader (CL) namespace of the caller class of a
target find[*] method (findStatic, findVirtual, etc.) with the CL
namespace of a class for which a given find operation is conducted.
Access to restricted packages is not checked only if Class Loader
namespaces are equal (the case for public lookup object, but also
for a trusted method caller such as invokeWithArguments invoked for
not blacklisted method).

The exploit vector used by the attack code is the same as the one
we used for second instance of our Proof of Concept code for Issue
32 (reported to Oracle on 17-Sep-2012). This exploit vector relies
on sun.org.mozilla.javascript.internal.GeneratedClassLoader class
in order to define a fully privileged attacker's class in a system
Class Loader namespace. From that point all security checks can be
easily disabled.

This is not the first time Oracle fails to "sync" security of Core
and new Reflection APIs. Just to mention the Reflection API filter.

This is also not the first time Oracle's own investigation / analysis
of security issues turns out to be not sufficiently comprehensive.
Just to mention Issue 50, which was discovered in the code addressed
by the company not so long ago...

Bugs are like mushrooms, in many cases they can be found in a close
proximity to those already spotted. It looks Oracle either stopped
the picking too early or they are still deep in the woods...

Thank you.

Best Regards
Adam Gowdiak

-
Security Explorations
http://www.security-explorations.com
"We bring security research to the new level"
-

References:
[1] Malware don't need Coffee: 0 day 1.7u10 spotted in the Wild - 
Disable Java Plugin NOW !
 
http://malware.dontneedcoffee.com/2013/01/0-day-17u10-spotted-in-while-disable.html
[2] New year, new Java zeroday!
 
http://labs.alienvault.com/labs/index.php/2013/new-year-new-java-zeroday/
[3] [SE-2012-01] Cri