[FD] Barracuda Networks Message Archiver 650 - Persistent Input Validation Vulnerability (BNSEC 703)

[Vulnerability Lab]

Document Title:
===
Barracuda Networks Message Archiver 650 - Persistent Input Validation 
Vulnerability


References (Source):

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

https://www.barracuda.com/support/knowledgebase/50160013lXe
Barracuda Networks Security ID (BNSEC): 703

BNSEC-00703: Remote authenticated persistent XSS in Barracuda Message Archiver 
v3.2
Solution #6604


Release Date:
=
2014-07-18


Vulnerability Laboratory ID (VL-ID):

751


Common Vulnerability Scoring System:

3.6


Product & Service Introduction:
===
The Barracuda Message Archiver is a complete and affordable email archiving 
solution, enabling you to effectively 
index and preserve all emails, enhance operational efficiencies and enforce 
policies for regulatory compliance. By 
leveraging standard policies and seamless access to messages, email content is 
fully indexed and backed up to enable 
administrators, auditors and end users quick retrieval of any email message 
stored in an organization’s email archive.

* Comprehensive archiving
* Exchange stubbing
* Search and retrieval
* Policy management
* Intelligent Storage Manager
* Roles-based interface
* Reporting and statistics

The Barracuda Message Archiver provides everything an organization needs to 
comply with government regulations in an 
easy to install and administer plug-and-play hardware solution. The Barracuda 
Message Archiver stores and indexes all 
email for easy search and retrieval by both regular users and third-party 
auditors. Backed by Energize Updates, delivered 
by Barracuda Central, the Barracuda Message Archiver receives automatic updates 
to its extensive library of virus, policy 
definitions to enable enhanced monitoring of compliance and corporate 
guidelines, document file format updates needed to 
decode content within email attachments, as well as security updates for the 
underlying Barracuda Message Archiver platform 
to protect against any potential security vulnerabilities.

(Copy of the Vendor Homepage: http://www.barracudanetworks.com )


Abstract Advisory Information:
==
The Vulnerability Laboratory Research Team discovered a persistent web 
vulnerability in Barracudas Messsage Archiver 3.2 Appliance Application.


Vulnerability Disclosure Timeline:
==
2013-11-08: Researcher Notification & Coordination (Benjamin Kunz Mejri)
2013-11-10: Vendor Notification (Barracuda Networks - Bug Bounty Program)
2013-11-13: Vendor Response/Feedback (Barracuda Networks - Bug Bounty 
Program)
2014-06-31: Vendor Fix/Patch (Barracuda Networks Developer Team - Reward: 
$$$)
2014-00-00: Public Disclosure (Vulnerability Laboratory)


Discovery Status:
=
Published


Affected Product(s):

Barracuda Networks
Product: Message Archiver 650 - Appliance Application 3.1.0.914


Exploitation Technique:
===
Remote


Severity Level:
===
Medium


Technical Details & Description:

A persistent input validation web vulnerability has been discovered in the 
official Barracuda Networks Message Archiver 650 v3.2 appliance web-application.
The remote vulnerability allows remote attackers to inject own malicious script 
codes on the application-side of the vulnerable application module.

The vulnerability is located in the `Benutzer > Neu Anlegen > Rolle: Auditor > 
Domänen` module. Remote attackers are able to inject own malicious script 
codes in the vulnerable domain_list_table-r0 values. The execution of the 
script code occurs in the domain_list_table-r0 and user_domain_admin:1 
appliance 
application response context. The request method is POST and the attack vector 
is persistent on the application-side of the barracuda networks message 
archiver web appliance. 

The security risk of the persistent input validation web vulnerability is 
estimated as medium with a cvss (common vulnerability scoring system) count of 
3.6.
Exploitation of the vulnerability requires a low privileged or restricted 
application user account with low or medium user interaction. Successful 
exploitation 
of the vulnerability results in session hijacking, persistent phishing, 
persistent external redirects and persistent manipulation of module context.

Request Method(s):
[+] POST

Vulnerable Module(s):
[+] Benutzer > Neu Anlegen > Rolle: Auditor

Vulnerable Input(s):
[+] Domänen

Vulnerable Parameter(s):
[+] domain_list_table-r0

Affected Module(s):
[+] Rolle: Auditor Listing


Proof of Concept (PoC):
===
The persistent web vulnerability can be exploited b

[FD] Microsoft MSN HBE - Blind SQL Injection Vulnerability

[Vulnerability Lab]

Document Title:
===
Microsoft MSN HBE - Blind SQL Injection Vulnerability


References (Source):

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

Video: http://www.vulnerability-lab.com/get_content.php?id=1282

Vulnerability Magazine: 
http://vulnerability-db.com/magazine/articles/2014/07/17/vl-core-team-published-blind-sql-injection-vulnerability-video-poc-msrc


Release Date:
=
2014-07-17


Vulnerability Laboratory ID (VL-ID):

1183


Common Vulnerability Scoring System:

9.1


Product & Service Introduction:
===
MSN (originally The Microsoft Network; stylized as msn) is a collection of 
Internet sites and services provided by Microsoft. 
The Microsoft Network debuted as an online service and Internet service 
provider on August 24, 1995, to coincide with the 
release of the Windows 95 operating system. The range of services offered by 
MSN has changed since its initial release in 1995. 
MSN was once a simple online service for Windows 95, an early experiment at 
interactive multimedia content on the Internet, 
and one of the most popular dial-up Internet service providers. MSN was 
primarily a popular Internet portal. Microsoft used 
the MSN brand name to promote numerous popular web-based services in the late 
1990s, most notably Hotmail and Microsoft 
Messenger service, before reorganizing many of them in 2005 under another brand 
name, Windows Live. MSN.com was the 17th most 
visited domain name on the Internet.

(Copy of the Vendor Homepage: http://www.msn.com )


Abstract Advisory Information:
==
The vulnerability laboratory research team has discovered a critical blind sql 
injection vulnerability in one of the official MSN network web-application.


Vulnerability Disclosure Timeline:
==
2014-01-27: Researcher Notification & Coordination (Ateeq ur Rehman Khan)
2014-01-28: Vendor Notification (Microsoft Security Response Center)
2014-03-13: Vendor Response/Feedback (Microsoft Security Response Center)
2014-07-16: Vendor Fix/Patch  (by Vulnerability Laboratory Check)
2014-07-17: Public Disclosure (Vulnerability Laboratory)


Discovery Status:
=
Published


Exploitation Technique:
===
Remote


Severity Level:
===
Critical


Technical Details & Description:

A boolean-based blind SQL Injection web vulnerability has been detected in the 
official MSN (habitos.be.msn.com) web application Service.
The vulnerability allows remote attackers to inject own sql commands to 
compromise the affected web-application and connected dbms. 

The SQL Injection vulnerability is located in the item.asp file. The vulnerable 
parameter to inject the sql commands is `item_id`.
Remote attacker are able to inject own sql commands to the item_id value in the 
item.asp file GET method request. The issue is a 
blind injection and the attack type is boolean based. The security risk of 
theremote sql injection web vulnerability 
is estimated as critical with a cvss (common vulnerability scoring system) 
count of 9.1.

The remote sql injection web vulnerability can be exploited by remote attackers 
without privileged application user account 
and without required user interaction. Successful exploitation of the sql 
injection vulnerability results in application and 
web-service or dbms compromise.

Vulnerable Domain(s):
[+] habitos.be.msn.com

Vulnerable file(s):
[+] item.asp

Vulnerable Parameter(s):
[+] item_id


Proof of Concept (PoC):
===
The remote blind sql injection vulnerability can be exploited by remote 
attackers without user interaction or 
privileged web-application user account. For security demonstration or to 
reproduce the vulnerability follow the 
provided steps and information below. 


Request #1
http://habitos.be.msn.com/item.asp?item_id=98%27%20AND%208606=BENCHMARK(100,MD5(0x4964554a))%20AND%20%27xPUE%27=%27xPUE


Request #2
http://habitos.be.msn.com/item.asp?item_id=98%27%20AND%208606=BENCHMARK(500,MD5(0x4964554a))%20AND%20%27xPUE%27=%27xPUE


Solution - Fix & Patch:
===
The vulnerability can be patched by a secure restriction and parse or encode of 
the vulnerable item_id value GET method request.


Security Risk:
==
The security risk of the remote blind sql injection web vulnerability is 
estimated as critical.


Credits & Authors:
==
Vulnerability Laboratory [Research Team] - Ateeq ur Rehman Khan 
[at...@evolution-sec.com] (@OhTheITGuy) [www.vulnerability-lab.com]


Disclaimer & Information:
=
The information provided in this advisory is provided as it is without any 
warranty. Vulnerability Lab disclai

[FD] KL-001-2014-002 : Microsoft XP SP3 BthPan.sys Arbitrary Write Privilege Escalation

[KoreLogic Disclosures]

Title: Microsoft XP SP3 BthPan.sys Arbitrary Write Privilege Escalation
Advisory ID: KL-001-2014-002
Publication Date: 2014-07-18
Publication URL: 
https://www.korelogic.com/Resources/Advisories/KL-001-2014-002.txt


1. Vulnerability Details

 Affected Vendor: Microsoft
 Affected Product: Bluetooth Personal Area Networking
 Affected Versions: 5.1.2600.5512
 Platform: Microsoft Windows XP SP3
 CWE Classification: CWE-123: Write-what-where Condition
 Impact: Privilege Escalation
 Attack vector: IOCTL
 CVE ID: CVE-2014-4971

2. Vulnerability Description

 A vulnerability within the BthPan module allows an attacker to
 inject memory they control into an arbitrary location they
 define. This can be used by an attacker to overwrite
 HalDispatchTable+0x4 and execute arbitrary code by subsequently
 calling NtQueryIntervalProfile.

3. Technical Description

 A userland process can create a handle into the BthPan device
 and subsequently make DeviceIoControlFile() calls into that
 device. During the IRP handler routine for 0x0012b814 the user
 provided OutputBuffer address is not validated. This allows an
 attacker to specify an arbitrary address and write
 (or overwrite) the memory residing at the specified address.
 This is classicaly known as a write-what-where vulnerability and
 has well known exploitation methods associated with it.

 A stack trace from our fuzzing can be seen below. In our fuzzing
 testcase, the specified OutputBuffer in the DeviceIoControlFile()
 call is 0x.

STACK_TEXT:
b1e065b8 8051cc7f 0050  0001 nt!KeBugCheckEx+0x1b
b1e06618 805405d4 0001   nt!MmAccessFault+0x8e7
b1e06618 804f3b76 0001   nt!KiTrap0E+0xcc
b1e066e8 804fdaf1 8216cc80 b1e06734 b1e06728 nt!IopCompleteRequest+0x92
b1e06738 80541890    nt!KiDeliverApc+0xb3
b1e06758 804fb4a7 8055b1c0 81bdeda8 b1e0677c nt!KiUnlockDispatcherDatabase+0xa8
b1e06768 80534b09 8055b1c0 81f7a290 81f016b8 nt!KeInsertQueue+0x25
b1e0677c f83e26ec 81f7a290  b1e067a8 nt!ExQueueWorkItem+0x1b
b1e0678c b272b5a1 81f7a288  81e002d8 NDIS!NdisScheduleWorkItem+0x21
b1e067a8 b273a544 b1e067c8 b273a30e 8216cc40 bthpan!BthpanReqAdd+0x16b
b1e069e8 b273a62b 8216cc40 0258 81e6f550 
bthpan!IoctlDispatchDeviceControl+0x1a8
b1e06a00 f83e94bb 81e6f550 8216cc40 81d74d68 bthpan!IoctlDispatchMajor+0x93
b1e06a18 f83e9949 81e6f550 8216cc40 8217e6e8 NDIS!ndisDummyIrpHandler+0x48
b1e06ab4 804ee129 81e6f550 8216cc40 806d32d0 
NDIS!ndisDeviceControlIrpHandler+0x5c
b1e06ac4 80574e56 8216ccb0 81d74d68 8216cc40 nt!IopfCallDriver+0x31
b1e06ad8 80575d11 81e6f550 8216cc40 81d74d68 nt!IopSynchronousServiceTail+0x70
b1e06b80 8056e57c 06a8   nt!IopXxxControlFile+0x5e7
b1e06bb4 b1a2506f 06a8   nt!NtDeviceIoControlFile+0x2a
WARNING: Stack unwind information not available. Following frames may be wrong.

 Reviewing the FOLLOWUP_IP value from the WinDBG '!analyze -v'
 command shows the fault originating in the bthpan driver.

FOLLOWUP_IP:
bthpan!BthpanReqAdd+16b
b272b5a1 ebc2jmp bthpan!BthpanReqAdd+0x12f (b272b565)

 Reviewing the TRAP_FRAME at the time of crash we can see
 IopCompleteRequest() copying data from InputBuffer into the
 OutputBuffer. InputBuffer is another parameter provided to the
 DeviceIoControlFile() function and is therefore controllable by
 the attacker. The edi register contains the invalid address
 provided during the fuzz testcase.

TRAP_FRAME:  b1e06630 -- (.trap 0xb1e06630)
ErrCode = 0002
eax=006a ebx=8216cc40 ecx=001a edx=0001 esi=81e002d8 edi=
eip=804f3b76 esp=b1e066a4 ebp=b1e066e8 iopl=0 nv up ei pl nz na po cy
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs= efl=00010203
nt!IopCompleteRequest+0x92:
804f3b76 f3a5rep movs dword ptr es:[edi],dword ptr [esi]

 A write-what-where vulnerability can be leveraged to obtain
 escalated privileges. To do so, an attacker will need to
 allocate memory in userland that is populated with shellcode
 designed to find the Token for PID 4 (System) and then overwrite
 the token for its own process. By leveraging the vulnerability
 in BthPan it is then possible to overwrite the pointer at
 HalDispatchTable+0x4 with a pointer to our shellcode. Calling
 NtQueryIntervalProfile() will subsequently call
 HalDispatchTable+0x4, execute our shellcode, and elevate the
 privilege of the exploit process.

4. Mitigation and Remediation Recommendation

 None. A patch is not likely to be forthcoming from the vendor.

5. Credit

 This vulnerability was discovered by Matt Bergin of KoreLogic
 Security, Inc.

6. Disclosure Timeline

   2014.04.28 - Initial contact; sent Microsoft report and PoC.
   2014.04.28 - Microsoft acknowledges receipt of vulnerab

[FD] KL-001-2014-003 : Microsoft XP SP3 MQAC.sys Arbitrary Write Privilege Escalation

[KoreLogic Disclosures]

Title: Microsoft XP SP3 MQAC.sys Arbitrary Write Privilege Escalation
Advisory ID: KL-001-2014-003
Publication Date: 2014.07.18
Publication URL: 
https://www.korelogic.com/Resources/Advisories/KL-001-2014-003.txt


1. Vulnerability Details

 Affected Vendor: Microsoft
 Affected Product: MQ Access Control
 Affected Versions: 5.1.0.1110
 Platform: Microsoft Windows XP SP3
 CWE Classification: CWE-123: Write-what-where Condition
 Impact: Privilege Escalation
 Attack vector: IOCTL
 CVE ID: CVE-2014-4971

2. Vulnerability Description

 A vulnerability within the MQAC module allows an attacker to
 inject memory they control into an arbitrary location they
 define. This can be used by an attacker to overwrite
 HalDispatchTable+0x4 and execute arbitrary code by subsequently
 calling NtQueryIntervalProfile.

3. Technical Description

 A userland process can create a handle into the MQAC device and
 subsequently make DeviceIoControlFile() calls into that device.
 During the IRP handler routine for 0x1965020f the user provided
 OutputBuffer address is not validated. This allows an attacker
 to specify an arbitrary address and write (or overwrite) the
 memory residing at the specified address. This is classically
 known as a write-what-where vulnerability and has well known
 exploitation methods associated with it.

 A stack trace from our fuzzing can be seen below. In our
 fuzzing testcase, the specified OutputBuffer in the
 DeviceIoControlFile() call is 0x.

STACK_TEXT:  
b1c4594c 8051cc7f 0050  0001 nt!KeBugCheckEx+0x1b
b1c459ac 805405d4 0001   nt!MmAccessFault+0x8e7
b1c459ac b230af37 0001   nt!KiTrap0E+0xcc
b1c45a68 b230c0a1  00d3 000c mqac!AC2QM+0x5d
b1c45ab4 804ee129 81ebb558 82377e48 806d32d0 mqac!ACDeviceControl+0x16d
b1c45ac4 80574e56 82377eb8 82240510 82377e48 nt!IopfCallDriver+0x31
b1c45ad8 80575d11 81ebb558 82377e48 82240510 nt!IopSynchronousServiceTail+0x70
b1c45b80 8056e57c 06a4   nt!IopXxxControlFile+0x5e7
b1c45bb4 b1aea17e 06a4   nt!NtDeviceIoControlFile+0x2a

 Reviewing the FOLLOWUP_IP value from the WinDBG '!analyze -v'
 command shows the fault originating in the mqac driver.

OLLOWUP_IP: 
mqac!AC2QM+5d
b230af37 891emov dword ptr [esi],ebx

 Reviewing the TRAP_FRAME at the time of crash we can see
 IopCompleteRequest() copying data from InputBuffer into the
 OutputBuffer. InputBuffer is another parameter provided to the
 DeviceIoControlFile() function and is therefore controllable by
 the attacker. The edi register contains the invalid address
 provided during the fuzz testcase.

TRAP_FRAME:  b1c459c4 -- (.trap 0xb1c459c4)
ErrCode = 0002
eax=b1c45a58 ebx= ecx= edx=82377e48 esi= edi=
eip=b230af37 esp=b1c45a38 ebp=b1c45a68 iopl=0 nv up ei pl zr na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs= efl=00010246
mqac!AC2QM+0x5d:
b230af37 891emov dword ptr [esi],ebx  ds:0023:=

 A write-what-where vulnerability can be leveraged to obtain
 escalated privileges. To do so, an attacker will need to
 allocate memory in userland that is populated with shellcode
 designed to find the Token for PID 4 (System) and then overwrite
 the token for its own process. By leveraging the vulnerability
 in MQAC it is then possible to overwrite the pointer at
 HalDispatchTable+0x4 with a pointer to our shellcode. Calling
 NtQueryIntervalProfile() will subsequently call
 HalDispatchTable+0x4, execute our shellcode, and elevate the
 privilege of the exploit process.

4. Mitigation and Remediation Recommendation

 None. A patch is not likely to be forthcoming from the vendor.

5. Credit

 This vulnerability was discovered by Matt Bergin of KoreLogic
 Security, Inc.

6. Disclosure Timeline

   2014.04.28 - Initial contact; sent Microsoft report and PoC.
   2014.04.28 - Microsoft acknowledges receipt of vulnerability
report; states XP is no longer supported and asks if
the vulnerability affects other versions of Windows.
   2014.04.29 - KoreLogic asks Microsoft for clarification of their
support policy for XP.
   2014.04.29 - Microsoft says XP-only vulnerabilities will not be
addressed with patches.
   2014.04.29 - KoreLogic asks if Microsoft intends to address the
vulnerability report.
   2014.04.29 - Microsoft opens case to investigate the impact of the
vulnerability on non-XP systems.
   2014.05.06 - Microsoft asks again if this vulnerability affects
non-XP systems.
   2014.05.14 - KoreLogic informs Microsoft that the vulnerability
report is for XP and other Windows versions have
  

[FD] Strong Security Processes Require Strong Privacy Protections

[coderman]

"Strong Security Processes Require Strong Privacy Protections"

A request for all security conscious organizations handling
vulnerability reports to deploy privacy enhancing technologies.

---

With the Snowden disclosures and Google's Project Zero on the minds of
security professionals everywhere, it is time to evaluate one more
aspect of this renewed focus on 0day and targeted attacks:
vulnerability submission to vendors. [0][1]

Software vulnerabilities of use to nation states and espionage
organizations are recognized as a threat to privacy and basic human
rights. Their impact no longer dismissable or discounted given
evidence of misuse. I will not discuss hardware vulnerabilities in
this treatment as they entail different considerations and
constraints. [2]

Reporting vulnerabilities of this nature in turn requires strong
privacy protections commensurate with the five and six digit monetary
values they command, and the adversaries intent on discouraging their
discovery or mitigation. [3][4]

---

Therefore, any organization handling vulnerability reports must
support strong privacy for vulnerability submission. This is mandatory
even if most or all issues received via this channel are not 0day, not
high value, and entail very little risk to users.

The characteristics of a strong private reporting method are:

- Email must not be used. In the best circumstances email leaks too
much information. In common situations it is passed around clear text,
trivially interfered with, and winds through software with huge
usability and vulnerability problems. Email for initial security
vulnerability reporting must cease immediately. [5][6]

- Public web systems for vulnerability reporting must not be used.
Like email, this leaks too much information and is vulnerable to a
wide array of attacks destroying any privacy intended. [7][8]

- Submission of reports via hidden site required. This has become
fashionable in media organizations as the "secure drop" for
whistleblowers, and it is equally apropriate for vulnerability
reporting. This significantly raises the cost of surveilling a
vulnerability reporting service, and ensures that passive interception
of reported vulnerabilities is impossible. [9]

- Encryption of submitted reports required. PGP and GPG are wonderful
tools, despite encrypted email being a dismal failure. While the
hidden drop may protect the privacy of the reporter, encryption of the
report content to specific vulnerability researchers' keys ensures
privacy to the receiver. A compromise of the hidden site must not lead
to access of reported vulnerabilities. [10]

- Submitter anonymity the default. Submissions and communication must
accomodate an anonymous identity. If a researcher wishes to claim
credit they must opt-in and provide additional information. No
psuedonymous account requirements, no key linking across submissions.

- Obfuscated disclosure should be available if desired. Capturing 0day
in the wild used for espionage or cyber effects is a rare event.
Publicly disclosing when, where, and how you obtained such captures
ensures you're likely never to see any others. Researchers in position
to observe and inspect such events should be able to report the
vulnerabilities without credit and without indicating the origin. A
vendor could provide a "cover story" for how the vulnerability was
discovered internally, to best protect sources' ability to continue to
discover these types of weaponized exploits in the wild.

Finally, it goes without saying that this privacy applies during
reporting and mitigation phases of defect resolution. Once a patch is
prepared and public the details of the vulnerability should be public
as well, via email list, public blog, or any other useful medium.

---

As participants in the security industry it behooves us all to set an
example for others and to demonstrate a committment to security and
privacy via action.

Security conscious organizations handling vulnerability reports can
support strong privacy and send a clear message deploying private
reporting methods described above.

Security researchers must demand strong privacy from organizations
they collaborate with, even in the most trivial or minor of
circumstances, so that infrequent severe vulnerabilities may also be
reported in confidence.

Privacy is a basic human right we must all support. Let's demonstrate
our support by using privacy enhancing technologies to resolve risks
to privacy!


best regards,



0. "The NSA Revelations All in One Chart"
 https://projects.propublica.org/nsa-grid/

1. "Announcing Project Zero"
 No link as the announcement is only supported over HTTP; attempt
HTTPS and you're redirected to plain-text. This is an embarassment
that should be fixed, Google Project Zero!  (the other plain-text
sites below have not unreasonable exuses ;)

2. "New technologies are radically advancing our freedoms but they are
also enabling unparalleled invasions of privacy"
 https://www.eff.org/issues/priv

Re: [FD] Peeling the onion: Almost everyone involved in developing Tor was (or is) funded by the US government | PandoDaily

[Liz Gossell]

The weak point of Tor has always been exit nodes. Anyone who operates one is 
going to have access to the comms passing through the node. I’m sure if someone 
really wanted to eavesdrop Tor traffic they’d just DoS other exit nodes and run 
a significant number of alternative ones so that users don’t notice.

https://www.torproject.org/docs/faq.html.en#CanExitNodesEavesdrop

Lesson: If someone wants your traffic badly enough, they’re going to get it.

— Liz

On Jul 17, 2014, at 7:40 PM, Ivan .Heca  wrote:

>> Tor was originally sponsored by the US Naval Research Lab.
> 
> That would be a logical assumption if you read the article and associated
> references
> 
>> Does this automatically mean it's backdoored then?
> 
> is it? I think what the author was alluding to is their trying. Perry
> thinks they can
> 
> Extremely well funded adversaries that are able to observe large portions
> of the Internet can probably break aspects of Tor and may be able to
> deanonymize users. This is why the core tor program currently has a version
> number of 0.2.x and comes with a warning that it is not to be used for
> “strong anonymity”. (Though I personally don’t believe any adversary can
> reliably deanonymize *all* tor users . . . but attacks on anonymity are
> subtle and cumulative in nature).
> On 18/07/2014 9:27 AM, "Stephen Crane"  wrote:
> 
>> Tor was originally sponsored by the US Naval Research Lab. Does this
>> automatically mean it's backdoored then? Could someone insert a backdoor
>> into open-source software? Yes. Funding sources do little to change this.
>> Now, who is controlling exit nodes is a different story, but that's another
>> can of worms.
>> 
>> 
>> On Wed, Jul 16, 2014 at 5:10 PM, Ivan .Heca  wrote:
>> 
>>> Funding doubled, so engineering some back doors?
>>> 
>>> In 2012, Tor nearly doubled its budget, taking in $2.2 million from
>>> Pentagon and intel-connected grants: $876,099 came from the DoD, $353,000
>>> from the State Department, $387,800 from IBB.
>>> 
>>> That same year, Tor lined up an unknown amount funding from the
>>> Broadcasting Board of Governors to finance fast exit nodes.
>>> 
>>> http://pando.com/2014/07/16/tor-spooks/
>>> 
>>> ___
>>> Sent through the Full Disclosure mailing list
>>> http://nmap.org/mailman/listinfo/fulldisclosure
>>> Web Archives & RSS: http://seclists.org/fulldisclosure/
>>> 
>> 
>> 
> 
> ___
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/


___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Peeling the onion: Almost everyone involved in developing Tor was (or is) funded by the US government | PandoDaily

[Olaf Rühenbeck]

Hey there,

> Funding doubled, so engineering some back doors?
I guess what you might be witnessing here is the fact that theres not
one "big bad us gov", but multiple partys which might or might not
agree on mass survilance and collection. Therefore one party is funding
research in anonymization software to help protect free speech whilst
the other party is trying to subvert it. 
As somebody funding a project usually has a agenda, it might not always
be the obvious or the "evil" ;)
> [...]
> That same year, Tor lined up an unknown amount funding from the
> Broadcasting Board of Governors to finance fast exit nodes.
> 
> http://pando.com/2014/07/16/tor-spooks/
Well...

 Even the NSA might like to have tor around for some
"cybering" Maybe they didn't like that it was that slow to
work with... :p

Bzmmm


signature.asc
Description: PGP signature

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Peeling the onion: Almost everyone involved in developing Tor was (or is) funded by the US government | PandoDaily

[Rikairchy]

To my knowledge, TOR could easily be subverted. If you attack all your
known exit nodes, you can force your own nodes to have a higher priority
due to the relativity low traffic compared to those under attack. You could
then tag unencrypted packets and follow them back to the initiating
computer.

This scenario was proposed to me when I first started using TOR, and I was
under the impression that Anonymous had done something similar when they
exposed a number of illegal websites
On Jul 17, 2014 7:28 PM, "Stephen Crane"  wrote:

> Tor was originally sponsored by the US Naval Research Lab. Does this
> automatically mean it's backdoored then? Could someone insert a backdoor
> into open-source software? Yes. Funding sources do little to change this.
> Now, who is controlling exit nodes is a different story, but that's another
> can of worms.
>
>
> On Wed, Jul 16, 2014 at 5:10 PM, Ivan .Heca  wrote:
>
> > Funding doubled, so engineering some back doors?
> >
> > In 2012, Tor nearly doubled its budget, taking in $2.2 million from
> > Pentagon and intel-connected grants: $876,099 came from the DoD, $353,000
> > from the State Department, $387,800 from IBB.
> >
> > That same year, Tor lined up an unknown amount funding from the
> > Broadcasting Board of Governors to finance fast exit nodes.
> >
> > http://pando.com/2014/07/16/tor-spooks/
> >
> > ___
> > Sent through the Full Disclosure mailing list
> > http://nmap.org/mailman/listinfo/fulldisclosure
> > Web Archives & RSS: http://seclists.org/fulldisclosure/
> >
>
> ___
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/
>

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Peeling the onion: Almost everyone involved in developing Tor was (or is) funded by the US government | PandoDaily

[Jack Morgan]

Also, remember that Tor was developed as a weapon to be used against
advanced threats and States of some power, as a way of providing
discontents of means of communicating and resisting authority. Its one of
those plans that backfired against the US government when it started to be
used to avoid its own detection.

so yay for US cov-ops tech. Because there needs to be a justification for
things governments throw money at. Even if we don't see it.


On Thu, Jul 17, 2014 at 4:36 PM,  wrote:

> On 17/07/14 01:10, Ivan .Heca wrote:
> > Funding doubled, so engineering some back doors?
> >
> > In 2012, Tor nearly doubled its budget, taking in $2.2 million from
> > Pentagon and intel-connected grants: $876,099 came from the DoD, $353,000
> > from the State Department, $387,800 from IBB.
> >
> > That same year, Tor lined up an unknown amount funding from the
> > Broadcasting Board of Governors to finance fast exit nodes.
> >
> > http://pando.com/2014/07/16/tor-spooks/
> >
> > ___
> > Sent through the Full Disclosure mailing list
> > http://nmap.org/mailman/listinfo/fulldisclosure
> > Web Archives & RSS: http://seclists.org/fulldisclosure/
>
> You might find this interesting then.
> https://www.youtube.com/watch?v=CJNxbpbHA-I
>
> The code is not the weak point, the idea that State funded operations
> can co-op enough exit nodes to subvert the network and make a difference
> is.
>
> --
>
>
> ___
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/
>

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Mining website blacklists

[surivaton surivaton]

go check the AMCA blacklist of australia from wikileaks:
http://wikileaks.org/wiki/Australian_government_secret_ACMA_internet_censorship_blacklist,_18_Mar_2009

be warned 99/100 of those links are child porn.

On 7/16/14, Paredes  wrote:
> Hey,
>
> It's useful trick to use website black lists to
> find interesting websites. Some are down, some host interesting
> malware, and a lot are vulnerable to all manner of things you haven't
> seen since the 90s.
>
> Useful lists include:
>
> http://squidguard.mesd.k12.or.us/blacklists.tgz
> http://dsi.ut-capitole.fr/blacklists/
> http://malc0de.com/bl/
>
> That said, it's quite likely to come accross things you'd prefer not
> to have seen, as well as things that just seem like the suppression of
> freedom of speech.
>
> Paredes
>
>
> ___
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/
>

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Should it be better ...

[Pablo]

Another possible consequence: This 'link-friendly' advisories lets the 
originator (a person, an institution or a fake of anyone of those) track 
the individual that routinely click on that links. Maybe just to build a 
list of people (IP->ISP->Country->Client of the ISP->Your home) 
interested in security, maybe not only for that. Who knows!? Just don't 
click on them ... or do it, nobody is watching! ;)


Regards,
Pablo.

El 10/07/2014 02:07 p.m., Fyodor escribió:


On Thu, Jul 10, 2014 at 7:51 AM, Pablo > wrote:


[Would] it be better to include the Advisory Details/exploit/code
in the body of the email to FD, and not in a link to a
blog/site/company so the list archive will be an archive and not a
index to some, possible down, link?


Yes, it is absolutely better to include full details in the body of 
the message rather than just a link.  I haven't been rejecting the 
link-only messages (as long as there is at least a brief summary), but 
they are annoying.  Not only are they a pain to read (need to open a 
browser and/or follow a link), but they screw up the archives.  Right 
now we're able to browse Bugtraq from more than 20 years ago, and it's 
fascinating:


http://seclists.org/bugtraq/1993/Nov/index.html

But if those messages were just links to other sites, how many would 
still work?  Hardly any.


Now it's perfectly fine to ALSO include a link to the advisory on a 
web site.  Just include full details in the body of the post too.  The 
main exception is binary attachments.  If an attachment is more than 
500K or a megabyte, just link it that attachment (in the descriptive 
text body of your post) to avoid clogging up people's mail spools. 
 Also, if you're posting someone else's work (like a news story or 3rd 
party blog or whatever), there may be copyright issues with just 
pasting the whole thing into your message.  Still, try to include at 
least the first few paragraphs or a summary so we know what it is.


Thanks,
Fyodor




___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Jamming WiFi tracking beacons

[Rikairchy]

I'm thinking of picking up a few Raspberry Pis, I was wondering if they
could be used as a way to track devices that search for wifi (unless this
is passive only), and recognise "friendly" devices while notifying an
administrator of foreign devices detected. Could this have any real world
application?
On Jul 17, 2014 7:37 PM, "Eric Rand"  wrote:

> There's a project on github for just that kind of thing:
>
> https://github.com/DanMcInerney/wifijammer
>
> Regardless of the hardware you choose to use, however, keep in mind that
> you're going to be using a much higher fraction of the radio amplifier
> in the wifi adapter's time than normal use, so there will be
> proportionally greater power consumption.
>
> (Radio theory isn't really infosec, but is a design consideration for
> something like this; I can talk about it out-of-band if you need to know)
>
> On 07/16/2014 02:26 AM, Keira Cran wrote:
> > Hey,
> >
> > It's great that companies like Apple recognising the threat of tracking
> > people via their devices wifi cards' MAC addresses, by randomising them.
> >
> > Naturally, I wondered i it was possible to jam the measurement beacon by
> > spoofing tons of wifi clients.  At one point in London, there was an
> > advertising firm with tracking bins [1] and I have a nice clip of a
> > technician looking puzzled at one beacon trying to figure out what's
> > wrong. (Unfortunately, it's bit too close to home (literally) to share.)
> > In the US I believe some ad "analytics" firms like SenseNetworks do
> > something similar. [2]
> >
> > Consider this a call to arms then, to put those unused raspberry pies
> > you have lying around to good use.
> >
> > best,
> > keira
> >
> > [1]
> >
> http://www.theguardian.com/world/2013/aug/12/city-london-corporation-spy-bins
> > [2] http://sensenetworks.com/
> >
> >
> > ___
> > Sent through the Full Disclosure mailing list
> > http://nmap.org/mailman/listinfo/fulldisclosure
> > Web Archives & RSS: http://seclists.org/fulldisclosure/
> >
>
>
> ___
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/
>

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Jamming WiFi tracking beacons

[Eric Rand]

R-pi doesn't come with a built-in wifi adapter, so you'll need to get
some add-ons to do that--and keeping in mind that there's only one USB
controller for all the networking and suchlike, there's a decided limit
to the amount of bandwidth that they can handle.

Listening for connects is very doable, though that's really more the
province of the Pineapple

[ http://wiki.wifipineapple.com/index.php/Main_Page ]

and similar projects--the Pineapple also gives you various other
functionalities, like spoofing and MITM facilitation.

Right tool for the job and all that.

On 07/17/2014 07:56 PM, Rikairchy wrote:
> I'm thinking of picking up a few Raspberry Pis, I was wondering if they
> could be used as a way to track devices that search for wifi (unless this
> is passive only), and recognise "friendly" devices while notifying an
> administrator of foreign devices detected. Could this have any real world
> application?
> On Jul 17, 2014 7:37 PM, "Eric Rand"  wrote:
> 
>> There's a project on github for just that kind of thing:
>>
>> https://github.com/DanMcInerney/wifijammer
>>
>> Regardless of the hardware you choose to use, however, keep in mind that
>> you're going to be using a much higher fraction of the radio amplifier
>> in the wifi adapter's time than normal use, so there will be
>> proportionally greater power consumption.
>>
>> (Radio theory isn't really infosec, but is a design consideration for
>> something like this; I can talk about it out-of-band if you need to know)
>>
>> On 07/16/2014 02:26 AM, Keira Cran wrote:
>>> Hey,
>>>
>>> It's great that companies like Apple recognising the threat of tracking
>>> people via their devices wifi cards' MAC addresses, by randomising them.
>>>
>>> Naturally, I wondered i it was possible to jam the measurement beacon by
>>> spoofing tons of wifi clients.  At one point in London, there was an
>>> advertising firm with tracking bins [1] and I have a nice clip of a
>>> technician looking puzzled at one beacon trying to figure out what's
>>> wrong. (Unfortunately, it's bit too close to home (literally) to share.)
>>> In the US I believe some ad "analytics" firms like SenseNetworks do
>>> something similar. [2]
>>>
>>> Consider this a call to arms then, to put those unused raspberry pies
>>> you have lying around to good use.
>>>
>>> best,
>>> keira
>>>
>>> [1]
>>>
>> http://www.theguardian.com/world/2013/aug/12/city-london-corporation-spy-bins
>>> [2] http://sensenetworks.com/
>>>
>>>
>>> ___
>>> Sent through the Full Disclosure mailing list
>>> http://nmap.org/mailman/listinfo/fulldisclosure
>>> Web Archives & RSS: http://seclists.org/fulldisclosure/
>>>
>>
>>
>> ___
>> Sent through the Full Disclosure mailing list
>> http://nmap.org/mailman/listinfo/fulldisclosure
>> Web Archives & RSS: http://seclists.org/fulldisclosure/
>>
> 


0xC6AA699A.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Jamming WiFi tracking beacons

[Rikairchy]

I thought the B+ model was four ports, two controllers. I'm not interested
in modifying (or even providing) a connection so much as looking for
unrecognised devices. I had the idea of using them in a mesh, with only one
actually connected to a live network. I thought it might be a way of
listening to what other devices are already broadcasting when they search
for a Wi-Fi connection
On Jul 17, 2014 11:02 PM, "Eric Rand" 
wrote:

> R-pi doesn't come with a built-in wifi adapter, so you'll need to get
> some add-ons to do that--and keeping in mind that there's only one USB
> controller for all the networking and suchlike, there's a decided limit
> to the amount of bandwidth that they can handle.
>
> Listening for connects is very doable, though that's really more the
> province of the Pineapple
>
> [ http://wiki.wifipineapple.com/index.php/Main_Page ]
>
> and similar projects--the Pineapple also gives you various other
> functionalities, like spoofing and MITM facilitation.
>
> Right tool for the job and all that.
>
> On 07/17/2014 07:56 PM, Rikairchy wrote:
> > I'm thinking of picking up a few Raspberry Pis, I was wondering if they
> > could be used as a way to track devices that search for wifi (unless this
> > is passive only), and recognise "friendly" devices while notifying an
> > administrator of foreign devices detected. Could this have any real world
> > application?
> > On Jul 17, 2014 7:37 PM, "Eric Rand" 
> wrote:
> >
> >> There's a project on github for just that kind of thing:
> >>
> >> https://github.com/DanMcInerney/wifijammer
> >>
> >> Regardless of the hardware you choose to use, however, keep in mind that
> >> you're going to be using a much higher fraction of the radio amplifier
> >> in the wifi adapter's time than normal use, so there will be
> >> proportionally greater power consumption.
> >>
> >> (Radio theory isn't really infosec, but is a design consideration for
> >> something like this; I can talk about it out-of-band if you need to
> know)
> >>
> >> On 07/16/2014 02:26 AM, Keira Cran wrote:
> >>> Hey,
> >>>
> >>> It's great that companies like Apple recognising the threat of tracking
> >>> people via their devices wifi cards' MAC addresses, by randomising
> them.
> >>>
> >>> Naturally, I wondered i it was possible to jam the measurement beacon
> by
> >>> spoofing tons of wifi clients.  At one point in London, there was an
> >>> advertising firm with tracking bins [1] and I have a nice clip of a
> >>> technician looking puzzled at one beacon trying to figure out what's
> >>> wrong. (Unfortunately, it's bit too close to home (literally) to
> share.)
> >>> In the US I believe some ad "analytics" firms like SenseNetworks do
> >>> something similar. [2]
> >>>
> >>> Consider this a call to arms then, to put those unused raspberry pies
> >>> you have lying around to good use.
> >>>
> >>> best,
> >>> keira
> >>>
> >>> [1]
> >>>
> >>
> http://www.theguardian.com/world/2013/aug/12/city-london-corporation-spy-bins
> >>> [2] http://sensenetworks.com/
> >>>
> >>>
> >>> ___
> >>> Sent through the Full Disclosure mailing list
> >>> http://nmap.org/mailman/listinfo/fulldisclosure
> >>> Web Archives & RSS: http://seclists.org/fulldisclosure/
> >>>
> >>
> >>
> >> ___
> >> Sent through the Full Disclosure mailing list
> >> http://nmap.org/mailman/listinfo/fulldisclosure
> >> Web Archives & RSS: http://seclists.org/fulldisclosure/
> >>
> >
>

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Jamming WiFi tracking beacons

[Eric Rand]

I hadn't seen the specs on the B+ model yet; mea culpa.

I think that the aircrack suite contains most of the functionality
you're looking for; seeding other sensors around with a mesh topology
might be a little bit of a challenge, but should still be doable.

On 07/17/2014 08:05 PM, Rikairchy wrote:
> I thought the B+ model was four ports, two controllers. I'm not interested
> in modifying (or even providing) a connection so much as looking for
> unrecognised devices. I had the idea of using them in a mesh, with only one
> actually connected to a live network. I thought it might be a way of
> listening to what other devices are already broadcasting when they search
> for a Wi-Fi connection
> On Jul 17, 2014 11:02 PM, "Eric Rand" 
> wrote:
> 
>> R-pi doesn't come with a built-in wifi adapter, so you'll need to get
>> some add-ons to do that--and keeping in mind that there's only one USB
>> controller for all the networking and suchlike, there's a decided limit
>> to the amount of bandwidth that they can handle.
>>
>> Listening for connects is very doable, though that's really more the
>> province of the Pineapple
>>
>> [ http://wiki.wifipineapple.com/index.php/Main_Page ]
>>
>> and similar projects--the Pineapple also gives you various other
>> functionalities, like spoofing and MITM facilitation.
>>
>> Right tool for the job and all that.
>>
>> On 07/17/2014 07:56 PM, Rikairchy wrote:
>>> I'm thinking of picking up a few Raspberry Pis, I was wondering if they
>>> could be used as a way to track devices that search for wifi (unless this
>>> is passive only), and recognise "friendly" devices while notifying an
>>> administrator of foreign devices detected. Could this have any real world
>>> application?
>>> On Jul 17, 2014 7:37 PM, "Eric Rand" 
>> wrote:
>>>
 There's a project on github for just that kind of thing:

 https://github.com/DanMcInerney/wifijammer

 Regardless of the hardware you choose to use, however, keep in mind that
 you're going to be using a much higher fraction of the radio amplifier
 in the wifi adapter's time than normal use, so there will be
 proportionally greater power consumption.

 (Radio theory isn't really infosec, but is a design consideration for
 something like this; I can talk about it out-of-band if you need to
>> know)

 On 07/16/2014 02:26 AM, Keira Cran wrote:
> Hey,
>
> It's great that companies like Apple recognising the threat of tracking
> people via their devices wifi cards' MAC addresses, by randomising
>> them.
>
> Naturally, I wondered i it was possible to jam the measurement beacon
>> by
> spoofing tons of wifi clients.  At one point in London, there was an
> advertising firm with tracking bins [1] and I have a nice clip of a
> technician looking puzzled at one beacon trying to figure out what's
> wrong. (Unfortunately, it's bit too close to home (literally) to
>> share.)
> In the US I believe some ad "analytics" firms like SenseNetworks do
> something similar. [2]
>
> Consider this a call to arms then, to put those unused raspberry pies
> you have lying around to good use.
>
> best,
> keira
>
> [1]
>

>> http://www.theguardian.com/world/2013/aug/12/city-london-corporation-spy-bins
> [2] http://sensenetworks.com/
>
>
> ___
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/
>


 ___
 Sent through the Full Disclosure mailing list
 http://nmap.org/mailman/listinfo/fulldisclosure
 Web Archives & RSS: http://seclists.org/fulldisclosure/

>>>
>>
> 


0xC6AA699A.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/