My net Logitech MX Keys keyboard doesn't have a regular Print Screen button anymore. Instead there is this camera/snipping tool button above the numpad.
This button does capture a screenshot in Ubuntu 20.04, but it lacks all the alternative methods.
Using the Solaar app, I have configured alternatives to take screenshots of;
whole screen
active window
selected area
These are either stored in ~/Pictures or (with Control modifier) on the clipboard.
Enable the Snipping Tool Diversion:
I had to try out some different combinations of options for gnome-screenshot. Online were some suggestions. I have settled on two 'helpers'. Without these the command wouldn't work as expected.
GDK_BACKEND=x11, to use/select the right clipboard
-f /tmp/screenshot.png, to force taking the screenshot
My father in law loves modifying his model trains and was looking for a way to add interior lighting. I had some spare LED strips, which are also 12 Volt, just like his train tracks.
The issue we ran into however, was of course, that the LED wouldn't turn on if the power is reversed to make the trains go in the opposite direction.
I was thinking of a solution using 4 diodes to create a rectifier and then found the Diotec S250K, a bridge rectifier.
The S250K fits quite nicely on LED strips. Now the trains have their lights on in either direction.
Yubico has a write-up describing how to configure GPG4Win to use a Yubikey for PGP and even SSH authentication on Windows 10. I ran into 2 issues however and am sharing my steps and solution here.
Issue 1 - No such device
C:\>gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device
Running the card-status command I only got "No such device" errors. A suggestion I found was to use reader-port Yubico YubiKey in the scdaemon.conf, but that didn't fix the issue.
Enabling logging and debugging
In the scdaemon manual are some helpful options that helped me construct the following scdaemon.conf:
verbose
debug-level 4
log-file C:\scdaemon.log
Restarted the gpg-agent, connected the Yubikey and ran the card-status command again.
Along with other log lines, the log file now contained these lines:
A recent update of theGoogle Authenticatorapp on Android brought an export/import feature. This enables users to copy their 2FA codes to a new device.
The format of the export seems to not be publicly documented (yet?). I believe that this export function is quite interesting and would like to see innovative solutions for back-up or interoperability between devices. It would also be in the general public's interest if there would be a single import/export format for 2FA codes and this one looks promising to me.
This blog post contains my interpretation of the export data. I hope this enables other developers to come up with new cool solutions that use the exported secrets.
Python implementation is available in my Github Repo.
** NOTE THAT THE 2FA CODES ARE SECRETS THAT YOU SHOULD TREAT AS SUCH! **
An interesting blog about the update was published at Ctrl blog.
Back in 2016 I was at a hotel where they had nice looking light from beyond the bed with LED stips. We already had a board behind our bed that would be a nice location the some LED strips like that. Through some investigation I quickly learned that an easy install solution was not available for the requirements that I had;
LED strip with high PWM frequency
On/off and dim controllable in the dark while in bed
Nice looking
In some public places where they use LED bulbs or strips I notice the flickering when the frequency is too low. Especially when it's the only light source in the room and the lights are dimmed. This is quite annoying and feels like I'm experiencing a low frame rate in real life. So the first requirement for this project was the PWM frequency should be high enough to not notice the blinking.
The light should have a very basic interface where it would be possible for me and my girlfriend to turn on/off the light and control the dim level. Doing some research I found some nice looking buttons online that even had a ring of light to make finding the buttons easier at night.
Lots of LED drivers are available on the market, however I couldn't find one that would allow me to connect two buttons to turn the lights on/off and also control the dim level. So I had decided to build my own driver. Having some experience with ATmega and ATtiny the choice was use work around an ATtiny85.
I don't have an education in electronic engineering, using any information from this blog is at your own risk.
Most LED strips that I could find at the time required 12V power supply. I wanted my design to work with any power source that is suitable for the connected LED strip. Therefore power source is connected directly to the output and controlled with a MOSFET. The ATtiny that I choose as controller requires a maximum of 5V. I have some LM7805's laying around which convert any input voltage of 7-35V to 5V, with a maximum of 1A. This is quite suitable to power the ATtiny85.
Schemas
Choosing the right MOSFET turned out more difficult than expected. I asked some colleagues that also like to do electronics and finally choose the IRFZ44N. The board contains a port for small interactions with an expansion. The current code support a KlikAanKlikUit RF receiver (433MHz).
After designing the circuit I ordered the boards online from Aisler. Living in the Netherlands the order from Germany didn't take long to arrive. You probably can image how exited I was to put everything together and test it out.
The PCBs from Aisler
That went better than expected! The software I had written worked as planned and I could control the LED strip with the switches. Short presses turn the light on or off and keeping the button pressed cycles through 6 dim levels.
Mounting he LED strip behind the bed was done with some simple profiles. To make the light come from behind the bed I made some small pieces of wood that are used to make a 90° angle of the strips to the bed.
Experimenting the pot resistors, I wanted to dim the light rings because they were way to bright at night. Started with 1kΩ, then 10kΩ and finally 50kΩ.
(Never really got to finish this post, but wanted to publish it anyway. If you have questions, feel free to leave ask them below.)
What seems to be missing however is an actually vulnerable implementation. Allow me to explain.
Just like the currently available public exploit, my idea was to send SSH2_MSG_USERAUTH_SUCCESS instead of SSH2_MSG_USERAUTH_REQUEST. To get this done I choose to patch OpenSSH and let it handle the rest of the SSH protocol for me.
$ sed -i 's/SSH2_MSG_USERAUTH_REQUEST/SSH2_MSG_USERAUTH_SUCCESS/g' sshconnect2.c $ autoreconf $ ./configure $ make
Next I started the libssh 0.7.5 example ssh_server_fork, fired up my patched OpenSSH and... Nothing.
Looking at the server log:
[2018/10/22 01:15:55.264597, 3] ssh_packet_socket_callback: packet: read type 52 [len=124,padding=73,comp=50,payload=50] [2018/10/22 01:15:55.264732, 3] ssh_packet_process: Dispatching handler for packet type 52 [2018/10/22 01:15:55.264799, 3] ssh_packet_userauth_success: Authentication successful [2018/10/22 01:15:55.264853, 3] ssh_packet_socket_callback: Processing 80 bytes left in socket buffer ... [2018/10/22 01:15:55.267131, 3] ssh_message_channel_request_reply_default: Sending a default channel_request denied to channel 0 [2018/10/22 01:15:55.267222, 3] packet_send2: packet: wrote [len=12,padding=6,comp=5,payload=5] [2018/10/22 01:15:55.267363, 3] ssh_socket_unbuffered_write: Enabling POLLOUT for socket [2018/10/22 01:15:55.269561, 1] ssh_socket_exception_callback: Socket exception callback: 1 (0) [2018/10/22 01:15:55.269667, 1] ssh_socket_exception_callback: Socket error: disconnected
So, I was successfully authenticated, but then disconnected. As described in RFC4252 §6, message 52 is SSH_MSG_USERAUTH_SUCCESS.
Source code diving time! I'll not go into all the details that I went through to get to understand libssh and cut right to it. Looking at examples/ssh_server_fork.c, this is essentially what's going on:
setup the libssh server and, when a client connects
call handle_session
setup libssh callbacks, including the auth_password_function
while (sdata.authenticated == 0 || sdata.channel == NULL)
ssh_event_dopoll(event, 100)
So what is this sdata? If we look at the auth_password function that was assigned as callback function for auth_password_function, we see:
This part of the example implementation of ssh_server_fork is authenticating the user by the provided username and password and only if these match, sdata->authenticated is set to 1. The while-loop will therefore never exit when the exploit is used to authenticate.
The other examples provided in the libssh source package, all use a local state variable to check if the user properly authenticated. I have yet to find any service that implements libssh in a different way.
Not all libSSH servers will necessarily be vulnerable to the
authentication bypass; since the authentication bypass sets the internal
libSSH state machine to authenticated without ever giving any
registered authentication callbacks an opportunity to execute, servers
developed using libSSH which maintain additional custom session state
may fail to function correctly if a user is authenticated without this
state being created.
If you have found a service implementation that is actually vulnerable, I'd be very interested to hear about it in the comments.
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
