Re: payswarm vocabs http vs https

Books (cont.)

Joel Scambray et. al, Hacking Web Applications Exposed, 2nd Ed.

On Sat, Jan 26, 2013 at 3:00 PM, Brent Shambaugh
<brent.shambaugh@gmail.com>wrote:

> For what is worth, here are a few things I've found interesting, or would
> like to learn more about:
>
> TCP/IP/HEX
>
> IBM Red Book: http://www.redbooks.ibm.com/abstracts/gg243376.html
> Hexadecimal: http://en.wikipedia.org/wiki/Hexadecimal
>    - Hex Editor: http://en.wikipedia.org/wiki/Hex_editor
>    - Hex Dump: http://en.wikipedia.org/wiki/Hexdump
>
>
> Patvera Maltego (network visualization used for social engineering)
>
> http://www.paterva.com/web6/products/maltego.php
>
>
> Social Engineering Risks (the weakest link)
>
> - Social Engineering:
> http://en.wikipedia.org/wiki/Social_engineering_%28security%29
> - Hacking the Human, Ian Mann
>
>
> Rainbow Tables, Dictionary Attacks, Brute Force Attacks  (for Cracking)
>
> https://en.wikipedia.org/wiki/Rainbow_table
> https://en.wikipedia.org/wiki/Dictionary_attack
> https://en.wikipedia.org/wiki/Brute_force_attack
>
>
> Rainbow Series (Collection of infosec books)
>
> - https://en.wikipedia.org/wiki/Rainbow_Series
>
>
> BackTrack Linux (penetration testing distribution)
>
> - http://www.backtrack-linux.org/
>
>
> Wireshark (packet analyzer)
>
> - http://www.wireshark.org/
>
>
> Network Security Conferences, such as:
>
> - DEFCON: https://www.defcon.org/   (curiously, no mention of the
> semantic web)
> - Blackhat: http://www.blackhat.com/
>
>
> Metasploit (platform for exploitation)
>
> - MetaSploit http://www.metasploit.com/
> - http://en.wikipedia.org/wiki/Metasploit_Project
>
>
> SNORT (network intrusion detection and prevention)
>
> - http://en.wikipedia.org/wiki/Snort_%28software%29
>
>
> netstat (network statistics)
>
> - https://en.wikipedia.org/wiki/Netstat
>
>
> ISO/IEC 27000-series (standards for information security)
>
> - https://en.wikipedia.org/wiki/ISO/IEC_27000-series
>
>
> Books:
>
> The Network Security Bible, Eric Cole
>
>
> Magazines:
>
> Phrack Magazine: http://phrack.org/
>
>
>
>
>
>
>
>
> On Fri, Jan 25, 2013 at 11:10 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:
>
>> On 01/25/2013 09:02 PM, Manu Sporny wrote:
>> > #4 is dangerous. JSON-LD does have a feature where it allows you to
>> > load any other context from the Web. Those contexts can override
>> > 'source' and 'destination'.
>>
>> Dave Longley and I just talked this attack vector through and it doesn't
>> seem like it's a valid attack. Here's the attack in a nutshell:
>>
>> 1. A buyer is attempting to swap the source/destination fields on who
>>    gets paid for a particular asset. There are two places that they
>>    could corrupt the source/destination: the listing, the contract
>>    before payment is made.
>> 2. The buyer finds a seller that is overlaying their own JSON-LD
>>    context and poisons the DNS that the seller is using to load their
>>    own context. The buyer's poisoned context swaps source/destination
>>    in the PaySwarm listing.
>> 3. The buyer poisons the PA's DNS with their poisoned context that
>>    swaps source/destination in the listing and the PaySwarm contract.
>>
>> #2 fails because swapping source/destination in the listing creates an
>> invalid payee for the digital good. The PaySwarm Authority will reject
>> the listing because it doesn't contain a destination field.
>>
>> #3 fails because the PaySwarm Authority (and this part is implementation
>> dependent) uses the listing to figure out who should be paid what, and
>> the listing is invalid at this point. Even if the listing were valid,
>> the poisoned JSON-LD context isn't applied until /after/ payment is
>> made, so the money would still go to the right place. The poisoned
>> JSON-LD context could still be written to the database with
>> source/destination swapped, which would cause a transaction audit to
>> fail, at which point the attack would be detected.
>>
>> So, a successful attack results in no monetary damage, but a corruption
>> of the transaction record (that is easily detected and fixed).
>>
>> However, that this attack didn't work out is just a result of the way
>> PaySwarm is designed. There could be other fields that the seller could
>> sign in the future that would affect the flow of payment. So, it's
>> probably best that we implement some sort of more heavy-weight
>> requirement that all JSON-LD Contexts used in PaySwarm transactions MUST
>> be loaded over HTTPS. This makes it so that implementers don't have to
>> worry about this sort of attack vector at all, which will simplify
>> implementations and lead to a tighter security model in general.
>>
>> I've raised an issue in the JSON-LD group to discuss the issue in more
>> depth:
>>
>> https://github.com/json-ld/json-ld.org/issues/213
>>
>> -- manu
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>> President/CEO - Digital Bazaar, Inc.
>> blog: Aaron Swartz, PaySwarm, and Academic Journals
>> http://manu.sporny.org/2013/payswarm-journals/
>>
>>
>