[Info-vax] What to do with my VAX.....

[Arne Vajhøj]

On 11/20/2020 9:46 AM, seasoned_geek wrote:
> Before you try and spin this into one of your academic imaginary worlds where only you exist, I haven't thought about this in a long time. Winging from memory rather than bothering to look up. The scenario was, as I recall,
> 
> 1) published XML standard being used
> 2) single message containing the short XML transaction (like a CC request for authorization)
> 3) SALT
> There was some other piece here that is in my notes on another machine and archived in a long discussion elsewhere.
> 
> You know for a fact the message starts with:
> <?xml version="1.0" encoding="UTF-8"?>
> to be safe you can stop with just: <?xml version="

Actually you can't.

Your approach requires a full block which is 16 bytes for AES.

> When the SALT has a TOD sensitivity such that between 2pm and 4pm local time only the last 5 really change (what I had stumbled into with some casual testing) you now only need the password. You know, that's not as difficult as it sounds given the helpful pages like this:

Symmetric encryption use IV not salt.

And with a decent implementation all bytes should change.

> Password
> 
> Your password:
> 
>      Must be between eight and 32 characters long.
>      Must include at least one number or special character and one letter.
>      Can contain any letters a to z and any numbers from 0 through 9.
>      Can contain some special characters, including @ (at sign) . (period) - (hyphen or dash) _ (underscore).
>      Cannot contain spaces or non-English characters (such as é).
>      Is case-sensitive.
>      Must be different from your first name, last name, and username.
> 
> ======

Which is pretty irrelevant since password is not used as key for
encrypting traffic in standard protocols.

> I now have all I really need to put my little BOT-NET to work
> generating entries for a PostgreSQL database. Each table will be
> named based on the SALT value. Each BOT is given a very simple task. 
> "Take this list of 100 valid generated passwords using this SALT
> value and encrypt <?xml version= returning the result for each." 
> That's it. Once per hour each of your hundreds or thousands of bots
> gets a tiny packet, possibly less than 1K in size. It does an
> imperceptibly small amount of calculations and returns, possibly 2K.
> If you have identified that between 2-4pm the generated SALT will
> only very within the last 5-digits you now just have 99,999 tables.
> The password rules mean you don't have all permutations of 32
> characters, just a severely limited subset. You are searching for the
> pre-amble of __exactly__ one known message. The side effect is you
> _can_ now decrypt every other single XML packet you happen to sniff.
> 
> Operation one just builds the database. It gets better over time. How
> much time depends on how many BOTS you have and how heavy you want to
> load them. Operation two is the sniffer. It wakes up near 2pm and
> shuts down near 4pm. Btw, there was nothing magic about 2-4pm, it was
> just what I was trying. You could most likely use 7-9am if you wanted
> people buying coffee, gas, etc. on the way to work.
> 
> Operation three receives the sniffed packets and does a partial keyed
> hit of the encrypted data to the table for the SALT. Upon match it
> decrypts the packet and routes it to another step that does some more
> verification before involving a human. If you are low budget and low
> tech, perhaps you send it straight to a human? This is very doable
> today I believe. I simply have too much going on in life to devote a
> bunch of non-billed effort into it. Storage is certainly getting
> really cheap - assuming you don't want to pay some hosting service
> for a 100 TB you can get a "portable" (perhaps with two guys carrying
> it) 32TB NAS for under $2500. 
> https://www.newegg.com/p/14P-001N-00010?Description=32tb%20nas&cm_re=32tb_nas-_-14P-001N-00010-_-Product&quicklink=true
>
>  Each "record" in each table only has the VARCHAR password and the
> VARCHAR target encrypted output. Given the previous example that
> means 32 or fewer characters for the password (many probably closer
> to eight). What? At most another 32 characters for the target which
> will be the alternate key? You don't even need a big BOT-NET, just
> time.
But since HTTPS and SSL in general does not work as you describe, then
it is rather pointless.

> Believe it or not; a large number of transactions on the Web are just one XML object in a "secured" packet.

They are not.

Before the XML in the body comes all the HTTP headers.

And those are also encrypted.

Arne