Malicious USB Interfaces In Airports

[Lawrence D'Oliveiro]

Seems there have been cases of crims hijacking USB charging outlets in
airports to connect special devices that can pwn your mobile device
<https://www.nzherald.co.nz/travel/news/airport-passengers-warned-of-phone-charging-scams/RGBS35ORBVBUDJIVO466TIFNAQ/>.

When I was in Hong Kong Airport a few years ago, it was very hard for
me to find a mains outlet to charge my laptop. Just about all the
ports built into the public seating areas were USB ones, for
phones/tablets.

It is possible to get USB cables that only connect the power wires for
charging, without enabling data transfer. Alternatively, here
<https://github.com/robertfisk/USG/wiki> is a USB “firewall”-type
device that tries to protect you from malicious devices. If you don’t
want to build your own, there’s a link in the readme to buy NZ-made
ones.

[yeti]

Maybe better only charge powerbanks on untrusted outlets and then later
charge your phone with them. That adds the benefit that power glitches
may only kill the powerbank and not the phone.

[Ralph Fox]

Post by Lawrence D'Oliveiro
Seems there have been cases of crims hijacking USB charging outlets in
airports to connect special devices that can pwn your mobile device
<https://www.nzherald.co.nz/travel/news/airport-passengers-warned-of-phone-charging-scams/RGBS35ORBVBUDJIVO466TIFNAQ/>.
When I was in Hong Kong Airport a few years ago, it was very hard for
me to find a mains outlet to charge my laptop. Just about all the
ports built into the public seating areas were USB ones, for
phones/tablets.
It is possible to get USB cables that only connect the power wires for
charging, without enabling data transfer. Alternatively, here
<https://github.com/robertfisk/USG/wiki> is a USB “firewall”-type
device that tries to protect you from malicious devices. If you don’t
want to build your own, there’s a link in the readme to buy NZ-made
ones.

For charging my phone at the airport, a USB data blocker gives complete
security for a tenth the price of that NZD $79.00 “firewall”-type device.

<https://www.aliexpress.com/item/1005005162014091.html>
<https://www.aliexpress.com/item/1005007101835777.html>

<https://www.temu.com/nz/usb-data-blocker-protects-data-with-plug-and-play-usb-converter-head-g-601099557440405.html>


Also, are there any *independent* tests of that NZD $79.00 “USG”
“firewall”-type device?

[Andy Burns]

Post by Lawrence D'Oliveiro
It is possible to get USB cables that only connect the power wires for
charging, without enabling data transfer. Alternatively, here
<https://github.com/robertfisk/USG/wiki> is a USB “firewall”-type
device that tries to protect you from malicious devices.

See also "USB condom"
<https://www.usbcompany.co.uk/accessories/usb-cond

[Scott Alfter]

Post by Andy Burns

Post by Lawrence D'Oliveiro
It is possible to get USB cables that only connect the power wires for
charging, without enabling data transfer. Alternatively, here
<https://github.com/robertfisk/USG/wiki> is a USB "firewall"-type
device that tries to protect you from malicious devices.

See also "USB condom"
<https://www.usbcompany.co.uk/accessories/usb-condom>
Not so simple with type-C and PD

This one's worked reasonably well for me:

https://amzn.to/3xaZQ2r

I suspect it blocks PD negotiation for higher power levels, but if all
you're charging is a phone, it should fall back to at least 5V 2.4-3A charging
of some sort. (My current phone doesn't support PD anyway...it uses
something called "Warp Charge" that is unlikely to be supported by any
public charger.)

(Your newsreader is inserting CRs at the ends of lines, BTW...might want to
fix that.)

[Ralph Fox]

Post by Scott Alfter
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to
fix that.)

I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.

CRLF is the correct, standard on-the-wire format.

[Andy Burns]

Post by Ralph Fox

Post by Scott Alfter
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to
fix that.)

I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.
CRLF is the correct, standard on-the-wire format.

Actually I think bare LF's are correct, no?

Thunderbird does on occasion do the wrong thing, if it sees 8-bit
characters (often an &nbsp; whitespace character, or two spaces at the
end of a paragraph) it decides to base-64 encode where it doesn't need
to, I think on this occasion it took objection to Lawrence's fancy
double quotes around the word 'firewall', unfortunately I've tried
various character encodings/charsets and nothing prevents the issue.

[Bob Eager]

Post by Andy Burns

Post by Ralph Fox
CRLF is the correct, standard on-the-wire format.

Actually I think bare LF's are correct, no?

I think the RFC specifies CRLF. What the client shows is another matter.

Post by Andy Burns
I think on this occasion it took objection to Lawrence's fancy
double quotes around the word 'firewall', unfortunately I've tried
various character encodings/charsets and nothing prevents the issue.

I don't have the issue as I killfiled him way back!

[Ralph Fox]

Post by Andy Burns

Post by Ralph Fox

Post by Scott Alfter
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to
fix that.)

I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.
CRLF is the correct, standard on-the-wire format.

Actually I think bare LF's are correct, no?

The on-the-wire format for transmission is CRLF, *not* bare LF. See,
for example, RFC5537 "Netnews Architecture and Protocols" section 2
"Transport".

<https://www.rfc-editor.org/rfc/rfc5537#section-2>

| Transports for Netnews articles MUST treat news articles as
| uninterpreted sequences of octets, excluding the values %d00 (which
| may not occur in Netnews articles), %d13, and %d10 (which MUST only
| appear in Netnews articles as a pair in that order and which,
| together, denote a line separator). These octets are the US-ASCII
| [ASCII] characters NUL, CR, and LF respectively.


How a newsreader client or news server stores articles locally (CRLF
or bare LF) is up to that client or server. But when communicating
between client and server / server and client, the on-the-wire format
is CRLF.

Post by Andy Burns
Thunderbird does on occasion do the wrong thing, if it sees 8-bit
characters (often an &nbsp; whitespace character, or two spaces at the
end of a paragraph) it decides to base-64 encode where it doesn't need
to, I think on this occasion it took objection to Lawrence's fancy
double quotes around the word 'firewall', unfortunately I've tried
various character encodings/charsets and nothing prevents the issue.

Using the latest Thunderbird 115.11.1 on Windows...

* When I compose a reply to Lawrence's post with the 'curly' quotes
and put it in the Outbox, my reply is not base-64 encoded.
* I would like to try composing my reply with various character
encodings/charsets, but current Thunderbird 115.11.1 does not seem
to have that option any more. In Thunderbird, my composed reply
to Lawrence is always UTF-8.

Using Thunderbird 115.11.0 on Linux Mint...

Same thing.

[Andy Burns]

Post by Ralph Fox
Using the latest Thunderbird 115.11.1 on Windows...
* When I compose a reply to Lawrence's post with the 'curly' quotes
and put it in the Outbox, my reply is not base-64 encoded.

Several times I've half-arsedly looked into what causes my TB to use
base64, after looking in a hex editor, it always seems to occur after a
perfect storm combination of user-agents, content-types,
character-encodings etc

Maybe I have some ancient about:config setting that I can't remember?

I've never managed to get even close to being able to log a good
bugzilla ticket.

Post by Ralph Fox
* I would like to try composing my reply with various character
encodings/charsets, but current Thunderbird 115.11.1 does not seem
to have that option any more.

Tools/Accounts/[ServerName]/ServerSettings/DefaultTextEncoding

In Thunderbird, my composed reply

Post by Ralph Fox
to Lawrence is always UTF-8.
Using Thunderbird 115.11.0 on Linux Mint...
Same thing.

[Ralph Fox]

Post by Andy Burns

Post by Ralph Fox
Using the latest Thunderbird 115.11.1 on Windows...
* When I compose a reply to Lawrence's post with the 'curly' quotes
and put it in the Outbox, my reply is not base-64 encoded.

Several times I've half-arsedly looked into what causes my TB to use
base64, after looking in a hex editor, it always seems to occur after a
perfect storm combination of user-agents, content-types,
character-encodings etc
Maybe I have some ancient about:config setting that I can't remember?
I've never managed to get even close to being able to log a good
bugzilla ticket.

Post by Ralph Fox
* I would like to try composing my reply with various character
encodings/charsets, but current Thunderbird 115.11.1 does not seem
to have that option any more.

Tools/Accounts/[ServerName]/ServerSettings/DefaultTextEncoding

The above setting did not affect the charset of my reply. Even though
the above setting was (already) set to "windows-1252", Thunderbird used
the UTF-8 charset for the reply I composed to Lawrence's post.

Also, the above setting is only present for news servers, not for email
servers. I expect that a setting to control the charset of _outgoing_
messages would be available for both email and news.


At one time you could specify the character encoding for an outgoing
message from its Compose window menu "Options >> Character Encoding".
<http://kb.mozillazine.org/Font_settings_in_Thunderbird#Character_encoding>.
Similar to how you still can in SeaMonkey. See this screen-shot from
SeaMonkey:
<Loading Image...>

[Dave Yeo]

Post by Ralph Fox

Post by Andy Burns

Post by Ralph Fox
Using the latest Thunderbird 115.11.1 on Windows...
* When I compose a reply to Lawrence's post with the 'curly' quotes
and put it in the Outbox, my reply is not base-64 encoded.

Several times I've half-arsedly looked into what causes my TB to use
base64, after looking in a hex editor, it always seems to occur after a
perfect storm combination of user-agents, content-types,
character-encodings etc
Maybe I have some ancient about:config setting that I can't remember?
I've never managed to get even close to being able to log a good
bugzilla ticket.

Post by Ralph Fox
* I would like to try composing my reply with various character
encodings/charsets, but current Thunderbird 115.11.1 does not seem
to have that option any more.

Tools/Accounts/[ServerName]/ServerSettings/DefaultTextEncoding

The above setting did not affect the charset of my reply. Even though
the above setting was (already) set to "windows-1252", Thunderbird used
the UTF-8 charset for the reply I composed to Lawrence's post.
Also, the above setting is only present for news servers, not for email
servers. I expect that a setting to control the charset of _outgoing_
messages would be available for both email and news.
At one time you could specify the character encoding for an outgoing
message from its Compose window menu "Options >> Character Encoding".
<http://kb.mozillazine.org/Font_settings_in_Thunderbird#Character_encoding>.
Similar to how you still can in SeaMonkey. See this screen-shot from
<http://img4.imagetitan.com/img.php?image=27_lchai5__text-encoding-menu-on-the-compose-window-in-seamonkey.png>

Have you looked at about:config, Tools-->Options-->Advanced-->Config
Editor...
In my old Thunderbird I see mailnews.send_default_charset;UTF-8 I guess
you could change it to Windows-1252. Or simply use SeaMonkey. With some
config editing, you could probably share your news directories, unless
Thunderbird has changed something.
Dave

[Ralph Fox]

Post by Dave Yeo

Post by Ralph Fox
At one time you could specify the character encoding for an outgoing
message from its Compose window menu "Options >> Character Encoding".
<http://kb.mozillazine.org/Font_settings_in_Thunderbird#Character_encoding>.
Similar to how you still can in SeaMonkey. See this screen-shot from
<http://img4.imagetitan.com/img.php?image=27_lchai5__text-encoding-menu-on-the-compose-window-in-seamonkey.png>

Have you looked at about:config, Tools-->Options-->Advanced-->Config
Editor...
In my old Thunderbird I see mailnews.send_default_charset;UTF-8 I guess
you could change it to Windows-1252.

That about:config preference is not in Thunderbird version 115.11.1
(the current release).

Post by Dave Yeo
Or simply use SeaMonkey. With some
config editing, you could probably share your news directories, unless
Thunderbird has changed something.
Dave

I am happy sending email in us-ascii or UTF-8.

The discussion was whether the sending charset had anything to do with
Andy's posts being base64 encoded. I think not. I suspect Andy's posts
are base64 encoded when they contain non-ASCII characters (no matter
what the charset) because I suspect Andy's Thunderbird preference
'mail.strictly_mime' is set to true.

[Andy Burns]

Post by Ralph Fox
I suspect Andy's posts
are base64 encoded when they contain non-ASCII characters

Yes, I did tests several months ago

Post by Ralph Fox
(no matter
what the charset) because I suspect Andy's Thunderbird preference
'mail.strictly_mime' is set to true.

With various charsets, with/without the "strictly" setting, on messages
that were 7-bit clean or otherwise.

My conclusion was that everything annoys somebody, but the least
annoying overall is to embrace UTF-8 and put up with base64 where it
isn't really required.

[Computer Nerd Kev]

Post by Andy Burns

I suspect Andy's posts are base64 encoded when they contain
non-ASCII characters

Yes, I did tests several months ago

(no matter what the charset) because I suspect Andy's
Thunderbird preference 'mail.strictly_mime' is set to true.

With various charsets, with/without the "strictly" setting, on
messages that were 7-bit clean or otherwise.
My conclusion was that everything annoys somebody,

True, personally UTF-8 annoys me more, but not enough to complain
to people using it.

Post by Andy Burns
but the least annoying overall is to embrace UTF-8

Argh, down that road people end up using emojis everywhere like
they do on some web forums. I might start complaining if people
embraced Unicode that much on Usenet.

[Eric Pozharski]

Post by Ralph Fox

Post by Dave Yeo

Post by Ralph Fox
At one time you could specify the character encoding for an outgoing
message from its Compose window menu "Options >> Character Encoding".
<http://kb.mozillazine.org/Font_settings_in_Thunderbird#Character_encoding>.

*SKIP* [ 5 lines 3 levels deep]

Post by Ralph Fox

Post by Dave Yeo
Have you looked at about:config, Tools-->Options-->Advanced-->Config
Editor...
In my old Thunderbird I see mailnews.send_default_charset;UTF-8 I guess
you could change it to Windows-1252.

That about:config preference is not in Thunderbird version 115.11.1
(the current release).

(disclaimer: I'm TB ignorant, but) In FF-current setting 'User-Agent:'
is secret option (it's missing from about:preferences and about:config),
it must be created manually. I speculate, setting 'Content-Type:
charset=' in TB-current *might be* secret option. That being said, this
implies two things: more digging through documentation and/or search
results, and hoping one day it won't be ignored forever.

*CUT* [ 15 lines 2 levels deep]

[Spiros Bousbouras]

On Sat, 08 Jun 2024 16:15:04 +1200

Post by Ralph Fox

Post by Andy Burns

Post by Ralph Fox

Post by Scott Alfter
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to
fix that.)

I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.
CRLF is the correct, standard on-the-wire format.

Actually I think bare LF's are correct, no?

The on-the-wire format for transmission is CRLF, *not* bare LF. See,
for example, RFC5537 "Netnews Architecture and Protocols" section 2
"Transport".
<https://www.rfc-editor.org/rfc/rfc5537#section-2>
| Transports for Netnews articles MUST treat news articles as
| uninterpreted sequences of octets, excluding the values %d00 (which
| may not occur in Netnews articles), %d13, and %d10 (which MUST only
| appear in Netnews articles as a pair in that order and which,
| together, denote a line separator). These octets are the US-ASCII
| [ASCII] characters NUL, CR, and LF respectively.
How a newsreader client or news server stores articles locally (CRLF
or bare LF) is up to that client or server. But when communicating
between client and server / server and client, the on-the-wire format
is CRLF.

I believe the RFC quote refers to articles before decoding (if there was an
encoding step). Here the complaint is that Andy's message had CR at the end
of every line even after decoding. I don't believe there is any standard for
that and a newsreader should probably follow the customs of the underlying
operating system.

[Ralph Fox]

Post by Spiros Bousbouras
On Sat, 08 Jun 2024 16:15:04 +1200

Post by Ralph Fox

Post by Andy Burns

Post by Ralph Fox

Post by Scott Alfter
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to
fix that.)

I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.
CRLF is the correct, standard on-the-wire format.

Actually I think bare LF's are correct, no?

The on-the-wire format for transmission is CRLF, *not* bare LF. See,
for example, RFC5537 "Netnews Architecture and Protocols" section 2
"Transport".
<https://www.rfc-editor.org/rfc/rfc5537#section-2>
| Transports for Netnews articles MUST treat news articles as
| uninterpreted sequences of octets, excluding the values %d00 (which
| may not occur in Netnews articles), %d13, and %d10 (which MUST only
| appear in Netnews articles as a pair in that order and which,
| together, denote a line separator). These octets are the US-ASCII
| [ASCII] characters NUL, CR, and LF respectively.
How a newsreader client or news server stores articles locally (CRLF
or bare LF) is up to that client or server. But when communicating
between client and server / server and client, the on-the-wire format
is CRLF.

I believe the RFC quote refers to articles before decoding (if there was an
encoding step).

Yes.

Post by Spiros Bousbouras
Here the complaint is that Andy's message had CR at the end
of every line even after decoding. I don't believe there is any standard for
that and a newsreader should probably follow the customs of the underlying
operating system.

Andy's message _after_ decoding_ also has CRLF at the end of every
line. As I stated in my reply to Scott Alfter earlier in this thread.

I tested this by running Andy's base-64 message body through a
base-64 decoder outside of my newsreader (to avoid any possibility
that my newsreader might modify the line ends after decoding).

[Scott Alfter]

Post by Ralph Fox

Post by Scott Alfter
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to
fix that.)

I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.
CRLF is the correct, standard on-the-wire format.

Maybe they were extras in addition to whatever standard newline is present.
When I replied to his post, there was an extra Ctrl-M at the end of every
line. Right now, while I'm replying to your post, it's normal...no extra
characters that need deleting.

[Ralph Fox]

Post by Scott Alfter

Post by Ralph Fox

Post by Scott Alfter
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to
fix that.)

I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.
CRLF is the correct, standard on-the-wire format.

Maybe they were extras in addition to whatever standard newline is present.
When I replied to his post, there was an extra Ctrl-M at the end of every
line. Right now, while I'm replying to your post, it's normal...no extra
characters that need deleting.

Andy's message body is base-64 encoded. Mine is not.

When I run Andy's raw base-64 message body through a base-64 decoder,
the message _after_ decoding also has CRLF and only CRLF at the ends
of lines. I tested this with a base-64 decoder outside of my newsreader,
to avoid any possibility that my newsreader might be modifying the line
ends after decoding.

[Andy Burns]

Post by Ralph Fox
Andy's message body is base-64 encoded. Mine is not.
When I run Andy's raw base-64 message body through a base-64 decoder,
the messageafter decoding also has CRLF and only CRLF at the ends
of lines. I tested this with a base-64 decoder outside of my newsreader,
to avoid any possibility that my newsreader might be modifying the line
ends after decoding.

I accept that TB is doing that (I think not just mine) several times
I've tried to stop it, but I fear I can't ... it's usually "lured" into
doing base64 by a particular sequence of messages, suggestions welcome ...

[Ralph Fox]

Post by Andy Burns

Post by Ralph Fox
Andy's message body is base-64 encoded. Mine is not.
When I run Andy's raw base-64 message body through a base-64 decoder,
the messageafter decoding also has CRLF and only CRLF at the ends
of lines. I tested this with a base-64 decoder outside of my newsreader,
to avoid any possibility that my newsreader might be modifying the line
ends after decoding.

I accept that TB is doing that (I think not just mine) several times
I've tried to stop it, but I fear I can't ... it's usually "lured" into
doing base64 by a particular sequence of messages, suggestions welcome ...

Just to be clear, I am not complaining. My newsreader automatically
decodes base-64. I would not even know a message is base-64 encoded
unless I look at the raw message source (like TB's Ctrl+U).


As for why TB is doing that, I suspect it is because your Thunderbird's
preference 'mail.strictly_mime' is set to true. The default is false.

When preference 'mail.strictly_mime' is set to true, Thunderbird will
MIME-encode (quoted-printable or base-64) bodies containing characters
outside the 7-bit US-ASCII range.

When I set 'mail.strictly_mime' is set to true, compose a reply to
Lawrence's post with the 'curly' quotes, and put it in the Outbox,
in that case my reply _is_ base-64 encoded. But I do not know why
Thunderbird is choosing to use base-64 over quoted-printable.
* If the body contains over ~20% 8-bit _bytes_, MIME base-64 is
more efficient than MIME quoted-printable.
* But in this case the body has less than ~20% 8-bit bytes, so
quoted-printable would be more efficient.

[Sylvia Else]

Post by Lawrence D'Oliveiro
Seems there have been cases of crims hijacking USB charging outlets in
airports to connect special devices that can pwn your mobile device
<https://www.nzherald.co.nz/travel/news/airport-passengers-warned-of-phone-charging-scams/RGBS35ORBVBUDJIVO466TIFNAQ/>.
When I was in Hong Kong Airport a few years ago, it was very hard for
me to find a mains outlet to charge my laptop. Just about all the
ports built into the public seating areas were USB ones, for
phones/tablets.
It is possible to get USB cables that only connect the power wires for
charging, without enabling data transfer. Alternatively, here
<https://github.com/robertfisk/USG/wiki> is a USB “firewall”-type
device that tries to protect you from malicious devices. If you don’t
want to build your own, there’s a link in the readme to buy NZ-made
ones.

Third attempt - I'm not seeing this arrive in the NG.


Is this still an issue, at least as far as Android phones are concerned?

Sylvia.

[Andy Burns]

Post by Sylvia Else

Post by Lawrence D'Oliveiro
It is possible to get USB cables that only connect the power wires for
charging, without enabling data transfer.

Is this still an issue, at least as far as Android phones are concerned?

Most(?) modern phones ask if you want to just charge, or enable
file/media transfer ... but who knows if there might be a way to
maliciously spoof an extra USB endpoint?