Security BSides Athens 2020

Given the current situation with most conferences having been canceled in 2020, Security BSides Athens 2020 (www.bsidesath.gr) took the decision to convert this year's event into a virtual conference. Based on that decision, we seized the opportunity to reach out to more people around Greece, and of course, welcoming anyone who wanted to join us from around the world (see here).

A virtual event has many challenges, especially when having to make sure everything is 100% ready before you hit the "go live" button. For the past 5 year, this annual meetup of Security BSides in Athens brought people together from all over the world, both Greeks and non-Greeks. We all have busy lives and we wanted to give people to opportunity to keep in touch with friends & colleagues that we tend to see once a year. Hence, even though we do not want this virtual get-together to be the norm, at the same time, it allows us to stay in touch. In our case, we used this year’s virtual event as an opportunity to a) increase the number of people who can “attend”, b) invest to a bigger/better event in 2021. In other words, as we do this for the community despite how much more work it needed, we are very happy that we are now in a position to say: Security BSides Athens 2020, was not cancelled! ;) 

A big -Thank You- to the whole team for supporting the event and spending their time putting this year's virtual conference together. It goes without saying that we couldn't have done this without our sponsors and speaker, who decided to support this year's Security BSides Athens 2020. 

We have now archived the Security BSides Athens 2020 and you can find all the relevant information (speakers, sponsors, participation, youtube videos, etc.) here: 2020.bsidesath.gr 

youtube-dl (how to) - best guide to get you started

####################################################################

###        youtube-dl - the best guide to get you started        ###

###                                                              ###

>> Installing

[Note]: Before you start; 

If you have upgraded to Catalina (on never have installed xcode and gcc before), then you will need to:

install Xcode (from Apple's App Store), then run the command: xcode-select --install 

then install gcc, and then install youtube-dl

[TIP]: You must run brew update first. Then you can either use the brew upgrade to update all packages, or, run brew upgrade youtube-dl to update only youtube-dl

//To install youtube-dl [1] under MacOS use:
brew install youtube-dl

//Once it is installed, update the application:
sudo youtube-dl -U

Re-encode screen recordings to work in iMovie

There was a case where I did some screen recordings but iMovie refused to see the video files .mp4 format. Video captures can be very useful as proof-of-concept and/or evidence of actions performed, for example during a security assessment, such as penetration testing sessions. 

In my case, it was showing only a "green screen" instead of what it was actually captured during the screen recording. Bear in mind that VLC could play the video file without any issues, but when loaded in iMovie, the same video file was failing to show properly.

If you have ffmpeg installed on your MacOS, you can very easily fix this problem, by re-encoding e.g. from an .mp4 file to a .mov file. 

Keep in mind, simply changing the "container" from an .mp4 video to .avi/.mov in most cases won't fix your problem. Hence, doing something like the following, as many others advice online, it will simply not work for you:
- ffmpeg -i Video.mp4 -c copy Video.mp4
- ffmpeg -i Video.mp4 -acodec copy -vcodec copy -f mov Video.mov


Re-encoding however, will fix your problem and ensure that iMovie can see the video as they were captured:

ffmpeg -i ScreenRec.mp4 -c:v libx264 -preset fast -profile:v baseline outRec.mov 

Of course, if you want to keep the same format, you can do:

ffmpeg -i ScreenRec.mp4 -c:v libx264 -preset fast -profile:v baseline outRec.mp4

New iOS text bug (aka text bomb) can crash your iPhone

A newly discovered bug is capable of crashing your Apple iPhone or iPad by simply receiving a text notification. The bug occurs when an iOS device user receives a text message or tries to read a tweet which is written using some Sindhi characters. 

This type of bug is known as a "text bomb", because a malicious individual can use it to prank, bully, cause Denial of Service (DoS), or even "troll" their targets by constantly forcing the receiver's app to crash. The original message sent had the Italian flag in it and it was using the hashtag: #CaptureTheFlag. 

It is being reported from different sources on social media that the text message other that your iPhone it also may crash your iPad, Apple Watch, and other Apple Gadgets.

The text bomb looks like any of the following group of Sindhi characters with any emoji in between: 

For obvious reasons I had to take a screenshot so not to be held responsible for propagating this. It was tested and it works. 

Text bombs aren’t something new. There have been numerous cases in the past few years where  random strings of text have caused mobile devices to behave in an unexpected way. However, this one is slightly different as it will crash the iPhone to crash if the phone received a message or notification in any social media chat applications. Unfortunately there is nothing much a user can do to avoid this other that wait to install the new update from Apple. The issue seems to be affecting  all Apple's mobile OS version from 13.3 onwards. 

Note: If you receive this type of message use alternative means, e.g. through your Mac laptop or Twitter app under Windows, to delete the received/posted message. This will allow your phone to be able to have access to the affected app without being forced to crash. If you phone hangs completely, you will need to keep pressing the power and volume up keys, until it reboots.

Ping an IP range from the command line interface (CLI)

If you ever wanted to do host discovery while no specific network scanning tools were available (e.g. nmap), or you wanted to avoid creating a script file (e.g. due to having no write permissions)? Here are a couple of useful commands depending on the OS of your choice:

Windows OS:
for /L %i IN (1,1,254) DO ping -n 1 -w 1 192.168.1.%i| FIND /i "Reply" >> IPs.txt

Note: command prompt has a limitation when asked to return the exact string using regex and returns the whole line. Here is an example of replacing find with findstr in order to use a regular expression (regex). 
findstr /r "[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*"

The regular expression can still be useful in cases such as:
ipconfig | findstr /r "[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*"


Linux OS:
for i in {1..254}; do (ping -c 1 -i 1 192.168.1.$i >/dev/null && echo "192.168.1.$i" &); done

Note: The above command will only list the discovered IP address, without any additional text.

Tip/Trick: Did you know you can use apr to achieve the same results but much faster. This seems to be reliable under Linux. The following command will list the discovered host on your network, including any additional information per IP (including the IPv6 address).
for ip in $(seq 1 254); do arp -n 192.168.1.$ip | grep on; done

The following command however, will list only the IP addresses without any additional text (also avoiding to specify the IP range twice)
for ip in $(seq 1 254); do arp -n 192.168.1.$ip | grep on | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' ; done