2020-05-12

Yaesu FTM-400XDR - Undocumented Cross-Band Repeater Mode

I was in the market for a new dual-band amateur radio. I'm a bit of a Yaesu fan, and I was torn between trying to find a used workhorse like the  FT-8900R, or trying something a bit more modern, like the FTM-400XDR. The one thing I really wanted the '8900R for was its cross-band repeater. That was the only thing missing from the new '400XDR.

Cross-band repeater mode will listen on two different bands (usually 70cm and 2m) and repeat what's being "heard" on one of the bands, transmitting it on the other. You can use this for a variety of purposes, but it's most commonly used to boost the range of a small handheld radio when you can't feasibly take a high-powered radio with you -- such as into an office building, down in your basement storm shelter, or keeping in touch with a group of spread-out friends while in an area without good repeater coverage.

Lo and behold, the FTM-400XDR does have a cross-band repeater built-in. It's just not documented officially. It's actually pretty easy to set it up.

Start by configuring your radio's tuners the way you want them to work together. Check that the frequencies, repeater offsets, squelch are all correct, and disable APRS if you had it enabled.

In this case, I configured the top tuner to communicate with a local repeater, on medium power. It might be kind of hard to see, but there are indicators "-" and  "T-TRX" in the header of the top tuner that indicate a negative repeater offset, and "Tone Squelch on Transmit and Receive" which are common radio configurations for repeater use. You could instead set the upper tuner to a simplex frequency if you want to run it as a stand-alone temporary repeater.

The bottom tuner has to be on the other band. Since the repeater I wanted to talk through is on the 2m band, I selected a simplex frequency from within the 70cm band.  Since I plan on staying pretty close to my radio for this test, I set the power level on the bottom tuner to low power, and made sure there was no auto-repeater-shift offset. You'll notice there are no indicators in the header of the lower tuner. You would not want to accidentally link two other repeaters together. Don't cross the streams.



Power the radio off. Next, hold the SETUP, F and GM buttons under the power button at the same time. Keep holding them while you power the radio on.



When it powers up, you will see an "X-Repeater" indicator in the middle of the screen.



If you're setting up a stand-alone repeater, all users will have to configure their dual-band handheld radios for "split" operation. This varies by make and model, but you'll want them to transmit on the same frequency as the bottom tuner, and receive on the same frequency as the top tuner of the '400XDR. Anything transmitted by members of your party on the lower tuner's frequency will be repeated out to everyone else listening on the upper tuner's frequency.

To use the cross-band repeater with another repeater like I did, you'll want  to set your handheld radio to use the simplex frequency, without a repeater shift, that's displayed on the bottom tuner. The cross-band will relay bi-directionally, so whatever you transmit will be sent to the repeater configured on the upper tuner, and whatever the repeater transmits will be sent back to your handheld via the simplex frequency on the lower tuner.




To disable cross-band repeater mode, power the radio off, then use the same 3-finger-salute while powering it back on.

Caveats:
  • When the repeater isn't being actively used, you're still responsible for ensuring it is functioning properly. Your cross-band repeater has no way to identify itself. (e.g. CW ID) and lacks the sophistication of a real repeater.
  • You or someone you trust should be close enough to your cross-band repeater to shut it off quickly should it malfunction or otherwise transmit undesired activity (such as static, intentional interference, radio pirates).
  • Turn the radio off or disable cross-band repeater mode if you are not actively using it or are unable to monitor it.
  • Use the minimum power level possible for the communications required. This is just best-practice, but also, if you end up cross-band repeating a long-running discussion, you may overheat your radio and/or drain your car battery. Mobile radios like this are designed for a relatively low duty cycle -- transmitting only for a few minutes at a time, then given a chance to cool down while others talk. Low power (5 Watts) is probably safe for extended, continuous bidirectional operation.
  • The FTM-400XDR is capable of operating on Yaesu System Fusion (C4FM) digital modes, but under cross-band repeater mode, it will only operate in analog FM mode. You cannot cross-band repeat to a digital repeater from an analog handheld radio.
    • I do wonder if another Fusion radio could communicate through a cross-band repeater to a Fusion Repeater and vice/versa... I don't have a second Fusion radio to test this with.

2020-02-02

02/02/2020! The first palindrome date since 11/11/1111

It's been almost a decade since I've seen an "only happens every several hundred years" thing floating around that seemed too out-there to be real.

So let's debunk the "first palindrome date since 11/11/1111" shall we? Surely these happen more frequently than that. And for shame not using ISO-8601 format. Fortunately, today also works as an ISO-8601 palindrome: 2020-02-02.

I whipped up a quick bash script to scan for dates n-days before and after today's date looking for palindromes in ISO-8601 format as well as the two other formats that are commonly (ab)used here in the United States, DD-MM-YY and DD-MM-YYYY. It's inefficient, relying on a lot of calls to date(1) and rev(1) but it is what it is.


#!/bin/sh
export i=1
while true
do
# ISO-8601 or GTFO.
idtb=`date -v-${i}d +%Y%m%d`
idtf=`date -v+${i}d +%Y%m%d`

# MM-DD-YYYY format
ydtb=`date -v-${i}d +%m%d%Y`
ydtf=`date -v+${i}d +%m%d%Y`

# MM-DD-YY format
dtb=`date -v-${i}d +%m%d%y`
dtf=`date -v+${i}d +%m%d%y`

if [ "$idtb" -eq "`echo $idtb | rev`" ]
then
echo YYYYMMDD $idtb was a palindrome.
fi

if [ "$idtf" -eq "`echo $idtf | rev`" ]
then
echo YYYYMMDD $idtf will be a palindrome.
fi

if [ "$ydtb" -eq "`echo $ydtb | rev`" ]
then
echo MMDDYYYY $ydtb was a palindrome.
fi

if [ "$ydtf" -eq "`echo $ydtf | rev`" ]
then
echo MMDDYYYY $ydtf will be a palindrome.
fi

if [ "$dtb" -eq "`echo $dtb | rev`" ]
then
echo MMDDYY $dtb was a palindrome.
fi

if [ "$dtf" -eq "`echo $dtf | rev`" ]
then
echo MMDDYY $dtf will be a palindrome.
fi
export i=`expr $i + 1`
done

A quick run for a minute or so shows a lot of palindromes past and future.
MMDDYY 021120 will be a palindrome.
MMDDYY 022220 will be a palindrome.
YYYYMMDD 20211202 will be a palindrome.
MMDDYYYY 12022021 will be a palindrome.
MMDDYY 121121 will be a palindrome.
MMDDYY 122221 will be a palindrome.
MMDDYY 112211 was a palindrome.
MMDDYY 111111 was a palindrome.
YYYYMMDD 20111102 was a palindrome.
MMDDYYYY 11022011 was a palindrome.
MMDDYY 012210 was a palindrome.
MMDDYY 011110 was a palindrome.
YYYYMMDD 20300302 will be a palindrome.
MMDDYYYY 03022030 will be a palindrome.
YYYYMMDD 20100102 was a palindrome.
MMDDYYYY 01022010 was a palindrome.
MMDDYY 031130 will be a palindrome.
MMDDYY 032230 will be a palindrome.  

2020-01-03

AppSec Lab: RasPwn with a MiFi-8800L JetPack Router

I'm hosting a few Application Security workshops later this year. I settled on RasPwn for the lab because it comes pre-configured with a bunch of vulnerable applications out of the box.

RasPwn acts as a stand-alone wireless access point using the Raspberry Pi's on-board Wi-Fi. If you plug in ethernet, it can route packets, but DNS forwarding seems broken. Some of the participants will have to be online and available during the workshops, so I wanted to make sure the lab has full Internet access. Additionally, it helps when folks can look up information about vulnerabilities while learning new concepts. I won't always be able to rely on on-site ethernet to provide Internet access to participants, so I decided to set up my MiFi 8800L hotspot as an Internet gateway on RasPwn, and I had to make sure DNS worked.

Hotspot setup:
When you plug in most WiFi hotspots over USB, some will only charge the internal battery, while others will immediately show up as a network device. Some also show up as a "virtual USB drive" with drivers and software. The Inseego MiFi-8800L touch-screen model prompts you when you plug it in, and has an option to serve Internet via USB only or USB+WiFi.

If you use the Web UI, you can set this option as the default. There's no way to set it up from the touch-screen interface. All other Inseego (and their previous brand, Novatel) hotspots I've used can be set up to provide USB Internet access by default, using the web admin portal. See owners' manual for details on accessing the admin portal. It'll probably vary widely by model. Example from my 8800L:



RasPwn setup:
  • Download the RasPwn software and follow the install instructions on the download page. If you've messed with Raspberry Pi distributions before, this should be pretty self-explanatory.
  • Place the card into a Raspberry Pi 3 and power it up. You won't need a screen or keyboard for anything. I did have to power-cycle the Raspberry Pi after the first boot for the WiFi network to show up. You may have to do the same.  
  • When RasPwn boots up, you'll see a new WiFi network called RasPwnOS show up. Connect to it. The default WiFi password is In53cur3! 
  • SSH to 192.168.99.1. The username is pi and the password is pwnme!
    • ssh pi@192.168.99.1
  • Set up eth1 (for the hotspot's USB interface)
    • edit /etc/network/interfaces with vi or nano
    • insert the two lines below, preferably after "eth0" is specified:
      allow-hotplug eth1
      iface eth1 inet dhcp
    • Save the file
  • Change the IP masquerading rules for iptables to use eth1
    • edit /etc/iptables.up.rules with vi or nano
    • change the MASQUERADE rule from
      -A POSTROUTING -o eth0 -j MASQUERADE
      to
      -A POSTROUTING -o eth1 -j MASQUERADE
    • save the file
  •  Set up the DHCP server to issue an external backup resolver
    • edit /etc/udhcpd.conf with vi or nano
    • change the "opt dns" line from
      opt     dns     192.168.99.1 192.168.99.10
      to
      opt     dns     192.168.99.1 8.8.8.8
(Note: the DNS stuff is kind of hacky. You could configure the on-board bind9 DNS server to resolve recursively, but it's more complicated and this works just fine)
  • Reboot RasPwn and test Internet connectivity.
    • sudo reboot
    • Close your SSH window
    • Wait a minute or so
    • Reconnect to the RasPwnOS wifi network
    • Try browsing the internet. If it doesn't work, make sure the HotSpot is showing a USB connection. You may need to unplug it and plug it back in, or unplug the hotspot, reboot RasPwn again, and plug the hotspot in after RasPwn boots up all the way. 
Okay, so let's hack something!
  • Go to playground.raspwn.org from your RasPwn WiFi connection 
  • Pick an app and start hacking!
The first thing in the playground is the OWASP Bricks practice application. It's intentionally vulnerable and designed to be increasingly complex with each challenge building on what you learned with the previous ones.

Some of the exercises will require an intercepting proxy such as BurpSuite, Charles Proxy, or OWASP ZAP, but the first login page can be hacked with just a browser. I actually didn't read any documentation for Bricks, and had never played with it before setting up RasPwn. My first login attempt was "admin" with a password of "admin" and it logged me in.

It wasn't until I saw the SQL in the footer that I knew this was supposed to be an SQL Injection challenge.Whoops. Okay, let's try this again with foo and a password of bar.
Okay, so that's what "access denied" looks like. Now let's throw some SQL injection into the username field. Here, I used a username of "foo ' OR 1=1 -- " (note the space after the -- comment, that's needed for MySQL and maybe other databases to acknowledge a comment).

And we've successfully used SQL Injection to hack the first Bricks challenge.

Happy hacking, friends!

2019-10-20

OpenBSD 6.6 released early!

OpenBSD 6.6 was released earlier this week. Along with it come a number of exciting enhancements to not just hardware support, but improvements to the installer, and security enhancements to the userland as unveil and pledge continue to get integrated more. You can read the entire change log at the link above.

As I had mentioned when OpenBSD 6.5 came out, sysupgrade(8) was making snapshot upgrades a breeze for those of us running -CURRENT. A few weeks back, the team made a sysupgrade patch available to bring this functionality to OpenBSD 6.5, so that folks could take advantage of it to upgrade to OpenBSD 6.6 when it was released. I spent some time this week testing it on my VMM virtual machines running OpenBSD-Stable and indeed, it's just as easy as upgrading snapshots. Then I upgraded everything else, including my production servers.

To upgrade from OpenBSD 6.5, as root or with doas, just run these commands:
syspatch
sysupgrade (it'll download what it needs, reboot, do the upgrade, and reboot again, fully unattended)
pkg_add -u (to upgrade all of your binary packages to the latest version)

As per usual, I updated the OpenBSD/httpd/MariaDB/PHP walk-through

 

2019-09-25

Scams: Two Close Calls

Over on Twitter, Eric Mill tweeted:

My stories are a bit too long for Twitter, but let's unpack two scams that were pretty well done which I fell for -- at least partially -- recently. We'll also highlight some early telltale signs that something was wrong, which I embarrassingly either missed or shrugged off at first, so that perhaps you'll be able to spot these scams better.


Feel free to share your own "scammed" stories in the aforementioned Twitter thread, or here in the comments.

My bank's doppelganger phone number 

My debit card had been getting flaky in chip readers recently. In fact, the plastic around the embedded chip contacts was breaking. It was time for a new card. I turned the card over to find the customer service number, which was a bit difficult to read because it was inexplicably printed directly under the embossed credit card number. The conversation went like this:

Agent: Thank you for calling [my bank's name] Card Services, this is [name]. Who am I speaking with today?
Me: ... my real name ...
Agent: Good morning, [name]! How can we help you today?
Me: My card's pretty worn out and isn't working consistently. I need a replacement, please.
Agent: We can get your new card sent out right away! What's your card number?
Me: ... reads the card number ...
Agent: And the expiration date?
Me: ... reads the expiration date after a short pause ...
Agent: And for security purposes, the 3-digit CVV code.

I suspected something was fishy when the agent requested my expiration date, but a few things were going on in my head. *I* called them, not the other way around. Also, the agent was professional and friendly, and even answered the phone with my bank's name. But when I got asked for the CVV code, that's when I knew something was completely wrong. I took a very close look at the back of my card, and compared it to the phone number I was calling. One of the hardest-to-read digits of the phone number on the back of my card was an 8, instead of the 0 that I dialed. 

Having disclosed my first and last name, Primary Account Number and expiration date, I called my bank's real number and had my card disabled and ordered a replacement. My real bank didn't even need my whole card number to look my account up when I contacted them. That was the first red flag, and I had completely missed it.

The mobile phone carrier "Fraud Department"

I got a call unusually early on a Saturday morning from my mobile carrier's customer service number (It was in my contacts and it was the right number). The person on the line was from the fraud department, and explained that they'd seen unusual activity on my account. Someone had changed the address on my account and then mail-ordered a new iPhone X for a little over $1000. She explained that any time an address is changed right before a purchase, their system flags the transaction for review.

This sounds quite rational to me. But who had access to my account? My wife's caregiver had recently quit and moved out, and she had a phone on our account. When she quit, we made her leave the phone behind. Perhaps she was up to no good? I was confused and furious; I felt violated. I explained that our old roommate may be behind it.

"Do you recognize this address?" the agent asks, before rattling off some random address in The Bronx. There's no way our old roommate was in The Bronx. Her family is all in Texas and Oklahoma. I thought it was very strange that a fraud department representative would disclose this information to me. That was the first red flag. I chose to ignore it.

"Sir, we'll take care of this," she explains. "We never processed the transaction, because it was flagged for review. Let's get your account secured! I just sent you a one-time code to verify you're in possession of the phone tied to your account. Can you read it to me?" There's red flag #2. I was still far too flummoxed to see it.

I get an SMS message from my wireless carrier. In a rush, I don't even read the whole message. I rattle off the 8-digit number. But then something catches my eye as I bring the phone back up to my head. Right at the beginning of the text message, there's a big disclaimer along the lines of "For the security of your account, we will never contact you for this code."

Now the plot thickens, but I'm a bit sharpened up. I begin to suspect this is an elaborate ruse, and it worked pretty well.

"I am not comfortable with this call," I say, grabbing my laptop and trying to log in to my account. The password has already been changed, in under a minute. Even the temporary code I'd just been texted isn't working. "Is there a direct number I can call you back at?"

"I'm securing your account, sir. I assure you, I'm from the fraud department. We do this all the time. I understand you're angry. We're almost finished with the password reset," she says, quite professionally. Meanwhile, I'm issuing my own password reset through my carrier's website. I get the exact same text message this agent had "sent" me, with a different one-time code, obiously.

I tell her that something has come up and I'll have to call her back in a few minutes. I ask for her name again. "Jessica," she says.

"May I please have your direct phone number so I can call you back in a bit, Jessica?"

"Sure thing! Just call me back at the customer service number I'm calling from. I'm at extension 105."

I hang up, and finish resetting my password.

I call back while scrolling through my account to make sure nothing's been purchased or changed. I get my carrier's customer service, as expected. There is no way to dial an extension. I get a real human on the phone, and ask to be transferred to extension 105. There is no extension 105. There *IS* a fraud department, but they do not call subscribers directly. Customer service pulls up my account's history. They keep a record of every agent who's looked at my account. No one had opened my account since we added a line to the account for our recently-departed caregiver.

Attackers can easily spoof a call to make it look like it came from any phone number. Armed with only my carrier's customer service phone number, and a list of phone numbers assigned to my carrier, they can trawl through the list and perpetrate this scam over and over. Having a young woman with a southern twang make the calls, with obvious call-center background noise was icing on the cake.

2019-04-30

Former student pleads guilty in "USB Killer" case

A few weeks old, from the Department of Justice website, comes the first mention I've heard of a "USB Killer" being used nefariously at scale:

Akuthota admitted that on February 14, 2019, he inserted a “USB Killer” device into 66 computers, as well as numerous computer monitors and computer-enhanced podiums, owned by the college in Albany.  The “USB Killer” device, when inserted into a computer’s USB port, sends a command causing the computer’s on-board capacitors to rapidly charge and then discharge repeatedly, thereby overloading and physically destroying the computer’s USB port and electrical system.

Akuthota admitted that he intentionally destroyed the computers, and recorded himself doing so using his iPhone, including making statements such as “I’m going to kill this guy” before inserting the USB Killer into a computer’s USB port.  Akuthota also admitted that his actions caused $58,471 in damage, and has agreed to pay restitution in that amount to the College.

This is the predominant threat model that came to mind when USB Killer Hype kicked in about a year and a half ago. That is, someone repeatedly using it to attack unattended computers. While USB Killer devices are no longer one-off devices, and they have achieved a sort of "commercial viability," the kind that look convincing enough for a random person to insert into their own PC cost more than $60 USD. That's a lot of cash to spend on potentially destroying devices belonging to a random person by just leaving it laying around. Cheaper ones that are chunky (or have no case at all, or have cases emblazoned with menacing logos) are easier to come by, but obviously look more suspicious.
This is a pretty "clean" way for someone to destroy a computer they have physical access to, but ultimately, "physical access is total access" as the saying goes.

2019-04-28

OpenBSD 6.5 released early

A few days late posting this, but OpenBSD 6.5 hit the wire last week, ahead of the May 1 target release date. Our OpenBSD Web Server Guide -- using the built-in httpd -- has been updated. And the PHP-FPM quirks from OpenBSD 6.4 got ironed out.

As far as installation and daily use go, you probably won't notice much has changed in OpenBSD 6.5. There was a ton of work done in areas of hardware support and network-stack enhancements.

If your console supports it, you may notice a new default console font (called "Spleen"). I've seen this on my OpenBSD-Current laptop for a few months. At first, I didn't really like it, but it's quite readable and has grown on me when working in text-only mode. I'm considering setting it as my default xterm font as well.

If you use OpenBSD-CURRENT with snapshots, however, there's already some fun stuff unfolding there, with sysupgrade(8) among them. This makes in-place upgrades a breeze. While it's not available in OpenBSD 6.5, upgrading from one release to the next should get a lot easier in about a year's time. The 6.6 to 6.7 upgrade will be the first supported release with this tool, unless they backport it to 6.5 with an errata/patch -- unlikely, indeed...