Utku Sen - Blog

Hash Olympics - A Hash Cracking Contest Without Good Hardware

2021-05-17T10:39:08+03:00

I was always a big fan of “Crack The Hash” contests where all participants are given a hash value, some hints and they try to crack it in a short amount of time. I wanted to make a similar contest for my Twitch followers. While hash cracking contests are fun, they require good hardware to be successful. Unfortunately, my followers are mostly students and due to the economic crises in Turkey, they are not able to buy computers with good hardware.

So, I had to create a contest format in which both rich and poor students can participate equally. It should be a contest of knowledge and hardworking, not money. As a result, I created a format named “Hash Olimpiyatları (Hash Olympics)”. In this format, I announce an attack combination one week before the contest (see details at process and rules section). In one week, the participants are doing analyze and preparing the best lists for the given attack combination. They are not cracking hashes by themselves but they are sending required lists (wordlist, mask, rule) to me before the contest. I’m cracking the hashes in the target database live at Twitch with the lists that they sent.

Contest Process

Contest is held with a moderator (streamer) and participants.
Moderator finds an actual database leak, removes the PII data and saves the hashes.
Name of the leak is not announced before the contest. However, if there is a password policy, it should be announced.
Moderator should define an attack combination by using the elements below (the combination would be different in every contest)
Wordlist size
Number of Hashcat rules
Number of Hashcat masks (and its complexity limit)

Example combinations: 1) A wordlist with 30 passwords, 15 rules, 0 mask - 2) A wordlist with 50 passwords, 10 rules, 1 mask

Participants should prepare those lists to crack most of the hashes. The lists will be sent to the moderator via e-mail before the contest. An example scenario:

Moderator announced the following attack combination: A wordlist with 5 passwords, 5 rules, 1 mask. The participant should send those lists:

| Passwd.txt | Rules.txt | Mask.txt |
|------------|-----------|----------|
| 123456     | :         | ?l?l?l?d |
| 1234567    | l         |          |
| qwerty     | u         |          |
| 19231923   | c         |          |
| besiktas   | ^X        |          |

Moderator starts a live stream during the contest
Moderator announces the target leak
Moderator starts to crack hashes in the leaked database with the lists sent by participants
Moderator takes a note of: Number of cracked total hashes, unique hashes and percentages
Moderator announces the winner

Our experience

We run two hash oliympics. It was lots of fun and everything went smoothly. The participants spent one week by analyzing previously leaked databases to create optimal attack combinations.

In the first contest, the attack combination was: A wordlist of 30 passwords, 15 Hashcat rules, 0 Hashcat mask. The target database was containing 50,000 hashes. The results were very close.

| Participant     | Total Cracked Hashes| Cracked Hash Percentage|
|-----------------|---------------------|------------------------|
| Mustafa Akbulut | 1206                | %2,687                 |
| Tolunay Yılmaz  | 1196                | %2,665                 |
| Hakan Sonay     | 1194                | %2,660                 |

In the second contest, I wanted to increase the scope of the attack combination. It was: A wordlist of 50 passwords, 15 Hashcat rules, 1 Hashcat mask (mask had specific limits). The result was very close again. The third and fourth places have only 3 hash differences. It was crazy.

| Participant     | Total Cracked Hashes | Cracked Unique Hashes | Cracked Hash Percentage |
|-----------------|---------------------|---------------------|----------------------------|
| Ebubekir Türker | 271752              | 44405               | %47,372                    |
| Nur Pabuççu     | 271698              | 44351               | %47,363                    |
| Can Taşdemir    | 271688              | 44341               | %47,361                    |
| Canberk Ayran   | 271685              | 44338               | %47,360                    |

Conclusion

Hash oliympics was a good experience for both having fun and teaching people how to analyze databases and using the Hashcat efficiently. People who can’t afford good hardware could also have fun. That was my point and we achieved that. You can contact me if you have any questions.

Share this:

Türkçe Wordlist Çalışmasında İkinci Faz

2020-12-20T10:39:08+03:00

Giriş

Bildiğiniz gibi geçen sene, Rockyou wordlistindeki Türkçe kelime içeren parolaları bulmak için bir çalışma yapmıştım. Bu çalışmanın iki önemli eksiği vardı:

Veri seti kısıtlıydı
Türk kullanıcıların içinde Türkçe kelime içermeyen parolalarını tespit edemiyordu

Bu iki problemin üstesinden gelmek için gönüllülerle birlikte Ahmet Külekçi, Rauf Giray Doğan, Murat Öztürk) çeşitli Hack forumlarında dolaşıp sızdırılmış veri tabanlarının dehashed (kırılmış) versiyonlarını indirdik. (Analiz edilen verilerin listesi repo açıklamasında mevcut)

Yeni verilerle hem parola içinde, hem de e-posta adreslerinin içinde Türkçe kelime tespiti yapmam mümkün oldu. Örneğin şu iki satırı ele alalım:

excalibur111@hotmail.com:karakartal1903

haznedarlibaba@gmail.com:ilovekpop

Hem karakartal1903 hem de ilovekpop parolalarını listeye alabildim.

Tekrarlayanlar çıkartıldıktan sonra 218.176.522 adet satır analiz edilmek için hazırdı. Corpus’u da biraz temizledikten sonra elimde 14.398 Türkçe kelime kaldı. Toplamda 3.141.305.563.756 adet string karşılaştırması yapmam gerekiyordu. Bir önceki yazıda açıkladığım gibi bu karşılaştırma klasik iç içe for loop ile yapılamıyor, felaket uzun sürüyor (Go da başarısız oldu). Aho-Corasick algoritması ile kısa sürede tamamlandı.

Bunun yanında Türkiye kaynaklı sitelerden sızan da önemli miktarda veri vardı. Bunları temizledikten sonra doğrudan wordlistin içine aldım. Sonuç olarak elimizde 5.017.676 adet Türkçe (ya da Türk kullanıcıların kullandığı) parola kaldı.

Türkçe wordliste buradan erişebilirsiniz: https://github.com/utkusen/turkce-wordlist

Projeye siz de kendi analizleriniz ile katkıda bulunabilirsiniz. Detaylar için buraya bakabilirsiniz: https://github.com/utkusen/turkce-wordlist/CONTRIBUTING.md

Share this:

Siber Güvenlik Sektöründeki Maaş Dağılımı Araştırması

2020-11-01T10:39:08+03:00

Giriş

Son bir senedir siber güvenlik sektöründeki maaşlarla ilgili çok sayıda şikayet ve soru aldım. Genel olarak insanlar sektördeki maaş dağılımlarına hakim değil ve aldıkları ücretin iyi mi kötü mü olduğuna karar veremiyorlar. Ben de bu bilgiye çok hakim değildim. O yüzden herkesin konu hakkında bir fikir edinmesi için bir maaş anketi yaptım.

Anketi paylaşırken spam girdilerden korkuyordum ancak neredeyse hiç spam olmadı. Birkaç trol girdinin dışında problem yaşanmadı. Girdi zamanlarına baktığımda arka arkaya çok sayıda bir giriş yapılmadığını da gördüm. Dolayısıyla anketteki veriler güvenilir gözüküyor. Yazım yanlışı olan ve outlier girdileri temizledikten sonra elimde 259 maaş bilgisi kaldı. Veri setini buradan indirebilirsiniz: https://utkusen.com/blog/assets/maas.csv

Ankette insanlar aşağıdaki rollerden birini seçerek maaş bilgilerini girdi:

Ofansif Güvenlik Testçi (web, network… penetration testing, red teaming vs.)
Defansif Güvenlik Mühendisi (SOC/SIEM/EDR yönetimi, network güvenlik analizi, tersine mühendislik vs.)
Güvenlik Analisti(rapor analizleri, vulnerability management vs. )
Güvenlik Mimarı (web ya da network mimarisinin oluşturulması/analizi)
Yazılımcı (güvenlik ürünlerinin kodlanması)
Ürün Yöneticisi (Güvenlik ürünlerinin geliştirme/verim/bakım vs. süreçleri)
Bilgi Güvenliği Uzmanlığı (Policy yönetimi, uyumluluk, KVKK vs.)
Koordinatör (testlerin ya da süreçlerin yönetimi)
Satış/Destek (pre-sales engineer, ürün desteği vs.)
Takım Lideri (defansif/ofansif ekiplerin yönetimi vs.)
Yönetici (üst düzey sorumlu)

Bu yazıda öncelikle tüm sektörün ortak grafiğini paylaşıp daha sonra bu roller özelinde grafikler paylaşacağım.

Grafik Açıklamaları

Grafiklerin X ekseninde yıl cinsinden tecrübe, Y ekseninde TL cinsinden maaş değerleri yer almaktadır. Yuvarlak elemanlar her bir girdiyi ifade ederken kare olanlar o tecrübe sütunundaki maaş ortalamasını(median) göstermektedir.

Tüm Sektör

Tüm maaş dağılımları

Tecrübeye göre ortalama(median) maaşlar

Ofansif Güvenlik

Defansif Güvenlik

Güvenlik Analisti

Güvenlik Mimarı

Yazılımcı

Ürün Yöneticisi

Bilgi Güvenliği

Koordinatör

Yeterli girdi bulunmamaktadır.

Satış/Destek

Takım Lideri

Yönetici

Share this:

Security by Obscurity is Underrated

2020-09-08T10:39:08+03:00

🔥 This article widely discussed at Hackernews and Reddit

In the information security field, we have developed lots of thoughts that can’t be discussed (or rarely discussed):

Never roll your own crypto
Always use TLS
Security by obscurity is bad

And goes like this. Most of them are very generally correct. However, I started to think that people are telling those because everyone is telling them. And, most of the people are actually not thinking about exceptional cases. In this post, I will raise my objection against the idea of “Security by obscurity is bad”.

Risk, Defense in Depth and Swiss Cheese

One of the main goal of defensive security is reducing the risk for the target business. According to the OWASP’s methodology, the risk of an issue is calculated with the formula below:

Risk = Likelihood * Impact

According to this formula, a Remote Code Execution issue poses more risk than a Cross Site Scripting one since the RCE causes more impact. This is easy. But what about the likelihood metric. According to the OWASP, likelihood refers that:

At the highest level, this is a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker

So, if we can reduce the likelihood, we can reduce the overall risk. That’s good. It’s actually very similar to a very common idea called “Defense in Depth”. It’s also referred as “Swiss Cheese Model”

According to this model, you need to build your defense mechanisms in a layered model so that even the attackers pass the first one, they will get caught on the others.

Security by Obscurity

So let’s talk about security by obscurity. It’s a bad idea to use it as a single layer of defense. If the attacker passes it, there is nothing else to protect you. But it’s actually would be good to use it as an “additional” layer of defense. Because it has a low implementation cost and it usually works well.

Let’s think about a couple of scenarios here:

I have a server that runs the SSH with it’s default port 22 and my credentials are: root:123456. What is the likelihood of being compromised?

It’s almost 100% since the hackers are conducting brute force attacks to the services with common credentials globally.

SSH runs in port 22 and my credentials are utku:123456. What is the likelihood of being compromised?

Well, we have eliminated the global brute forcers since we are not using a common username. The likelihood and risk are reduced. However, we still have to deal with targeted attackers. A targeted attacker can guess the username as utku since it’s my name.

SSH runs in port 64323 and my credentials are utku:123456. What is the likelihood of being compromised?

Now we changed the default port number. Does it help? Firstly, we’ve eliminated the global brute forcers again since they scan only the common ports. What about the others? To find this out, I did a small survey on my Twitter to find out people’s port scan behaviors.

I'm trying to prove a point for my new article. I need your answers for the question below. (please be honest)

-When you do a port scan with nmap to find open ports on the target, are you specify a custom port range to scan all 65,535 ports? (with -p0-65535 parameter)
— Utku Şen (@utkusen) September 7, 2020

As you can see here, lots of people tend to scan the default/most popular ports only. So, if you switch your port from 22 to 64323, you will eliminate some of them. You will reduce the likelihood and risk.

The same thing goes for software vulnerabilities as well. If a vulnerability found in the Microsoft Remote Desktop Protocol, everybody will scan for the port 3389 globally. You can reduce your risk just by changing the default port.

Other Applications

Of course, it’s possible to use the same methodology in other fields other than changing the defaults. For example, the following ideas might be a good idea for some specific cases (not always)

Obfuscating codes: Of course, it’s common knowledge. Hackers are people too. If you obfuscate your code well, they will need to spend more time to find issues. They may give up eventually.
Using random variable names for a web application: Instead of using clear variable names, you can switch them with random strings. It might help just like the code obfuscation.
Using Symmetric Encryption in the Database: When you write data to the database, use a function like encryption_algorithm(data,key). Likewise, when you read data, use a function like decryption_algorithm(data,key). If the attacker can read your backend code, obviously he/she can decrypt your database. But if there is an issue that allows an attacker to read data from the database, but not the backend code (like SQL Injection), the gathered data won’t be helpful for the attacker.

Real Life Applications

Security by obscurity is widely used in physical/real-life security. For example, the president goes from point A to point B with his 30 cars convoy. But he’s not sitting on his own presidential car so that the attacker won’t target him easily. He can be in any car and it reduces the risk of an attack.

Camouflaged animals are using security by obscurity as well. Obscurity reduces the likelihood of being killed. Therefore, they gained this ability in the evolutionary process.

Conclusion

Security by obscurity is not enough by itself. You should always enforce the best practices. However, if you can reduce the risk with zero cost, you should do that. Obscurity is a good layer of security.

Share this:

Torture-Proof Authentication

2020-02-26T10:39:08+03:00

Authentication is one of the biggest problems of security since the beginning of the internet. In most cases, we are using passwords for authentication. But it usually causes problems since people are using weak passwords, reusing the same passwords on different platforms or simply giving them away with phishing scams. Not only for websites/applications, we were also using them to unlock our mobile phones. However, companies like Apple provided more user-friendly authentication options such as Touch ID and Face ID where you can unlock your phone with your biometric data.

Authentication with biometric data is cool, but I’m not really a big fan of that. It’s easy to put someone’s finger on their iPhone by force. It’s a great risk for people who are living under oppressive regimes or criminals who want to negotiate after being captured.

What about regular passcodes. It’s something that’s only available in your mind. But this doesn’t mean that you are not at risk. They can torture you to get that passcode, and eventually, you will give up.

What do we need then? We need an authentication mechanism that can’t be captured even by the torture. Assuming that we will compromise under torture, this mechanism should aware that we are under stress.

An Experiment: Authentication via Body Motions

My base hypothesis was everyone has a unique wrist motion. I was thinking that we can create a machine learning model around that, differentiate and authenticate people by analyzing their wrist motion data coming from smartwatches. How would it help with the torture case? Since you will be under huge stress after torture, your wrist movements will be different even if you push yourself to act like as normal. Hence, you won’t be able to authenticate.

To test this, I created an Apple Watch application which records my wrist movements when I’m walking from the kitchen to my computer. I recorded 100 walking events and trained it. My expectation was: When I walk again to my computer, it should correlate the data with the model and authenticate me. Besides that, when another person walks in, it should detect the anomaly and won’t authorize. This experiment is failed for two reasons:

1) To get a proper model, 100 records isn’t enough, you may need to record it 500 times. This kills the usability.

2)I turned out it’s not so hard to mimic someone else’s movement. This kills the security and the entire concept

A Futuristic Approach

We need a microcomputer that goes under the skin and stays there for a long time. This little computer will have our password (or private key etc.) for authentication and needs to be physically destroyed when it goes out of the skin. The password will be transferred to the device that you want to authenticate via a wireless medium such as NFC or Bluetooth (or some future model)

This computer will also measure the heartbeat and cortisol levels of the user. If the measurement goes beyond the defined threshold, authentication won’t occur until the user gets calm. There won’t be any backdoor to bypass this control. This will be a common knowledge and your kidnappers won’t torture you since they would know there is no chance to trigger the authentication mechanism by force.

More Realistic Approaches

We don’t know when we will have microcomputers with a heart rate detector. But there are things that can be done with today’s technology (or in the near future)

Touch ID with heart rate measurement: Apple Watches and various devices can measure the heart rate from outside of the skin. So when a user tries to authenticate with fingerprint, the device should control his/her heart rate, and won’t allow if it’s above the defined threshold.

Face ID with a crazy machine learning model: Imagine a machine learning model that can differentiate your normal face from a stressed one. This can be possible in the near future. So when you try to unlock your phone with a stressed face, the device won’t allow you to do it.

Panic button: When the user thing zhe’s going to be arrested (or kidnapped), zhe will press a button which will lock all kind of authorization attempts on all devices. This can’t be unlocked by the user zhimself. The user should define three trusted people that can trigger the unlock event. The devices won’t unlock if all these three people agree on that.

Share this:

An Introduction to Arcade Security

2019-12-25T10:39:08+03:00

TL;DR This article contains my experiences on testing amusement arcade’s security. I found a DoS vulnerability on Intercard devices. An attacker can take down entire arcade machines by using this vulnerability.

Me and my girlfriend love to spend hours in local arcades. I always wanted to know how their network works and are they secure or not. But I couldn’t find a comprehensive article about it. I decided to test them by myself.

Learning The Fundamentals

In most of the arcades, you need to have their magnetic stripe card. You need to go to the cashier and say how much credit you want. After that, she gets a random card from the stack, swipes it at a machine, presses some buttons on the screen and gives the card.

To play a video game, you need to swipe your card at a machine looks like this:

After a swipe, it tells you how much credit you left and starts the game.

To understand how all these works, I had to look inside those cards and maybe rewrite them. When I was in DEF CON, I bought a magnetic stripe reader/writer and lots of empty magnetic cards from here

When I turned back to Istanbul, I went to the arcade and checked the devices. They were using Intercard machines. I bought 4 different cards.

Card 1: Has 0 credits
Card 2: Has 10 credits
Card 3: Has 20 credits
Card 4: Has 20 credits

Since I have no previous knowledge about these systems, these cards will answer all of the following questions:

1) Is credit information is written inside the cards as plaintext? If the answer is yes, I will see 0,10,20,20 values in cards.

2) Is credit information is written inside the cards as encoded. If the answer is yes, value of 3rd and 4th cards have to be same, the others will be different.

3) If each card has unique ID? If the answer is yes, all cards have to carry a different value.

I checked the data inside the cards and all of them was different. They were carrying a fixed-size alphanumeric ID value. So there is a server-client architecture inside the arcade. Magnetic reader on the machine sends ID value to the server and server responds with a data which states if I can play or not and how much credit left.

We checked the devices but none of them has ethernet cables. So, they are connected via WiFi. It was a promising attack vector in our case. But, I decided to test everything about magnetic cards before jumping to the Wi-Fi.

Testing For Race Condition

I cloned a card with it’s unique ID which has 20 credits in it. My goal was swiping two identical cards on different machines on the same time to catch a race condition vulnerability. If it works, we can play the second game for free. We tried it in two machines which are both require 2 credits. We swipe the cards on the same time.

First trial: Both card worked. One card showed 18 credits left, second card showed 16 credits left. (Probably we couldn’t swipe at the same time)

Second trial: One card worked, the other showed a generic error. The worked card showed 14 credits left.

Third trial: One card worked, the other showed a generic error. The worked card showed 12 credits left.

At this point, I decided that race condition isn’t possible (or practical) since we always get error on the other card when we swipe at the same time.

Bruteforcing Staff Card’s ID

To configure magnetic card readers, there is a staff card (root access). When staff swipes zher card, zhe can start the game without paying any credit. This card looks same with the customer card. Probably, server keeps the ID value of the staff card, and grants access to the machines by checking that value. So, if I can identify staff card’s ID, I can clone this ID to unlimited amount of cards.

I tried lots of different ID’s such as 00000000 11111111 AAAAAAAA but no luck. If I had Samy Kamkar’s magnetic stripe spoofer I could brute force lots of combinations in short amount of time.

Attempts For Infiltrating The Arcade Network

If we could infiltrate inside the arcade network, we could listen client-server traffic via ARP poisoning. After then, we could search vulnerabilities on communication or in server itself. If their communication isn’t encrypted, we could change “Insufficient credit” response with a positive one.

Capturing and -can’t- Cracking WiFi Handshake

My first plan was conducting deauthentication attack to arcade machines and capture a handshake when they try to reconnect. I used Alfa card with wifite2 tool and it worked. I got a handshake. However, I couldn’t crack it. I tried online websites, run my GTX 1070 graphic card for 5 days but no luck. I’m not sure if Intercard provides router and default password to the stores. If this is the case, they provided a strong password indeed.

Evil Twin Attack

I’m not so good at WiFi hacking but I decided to try another attack that I know. It’s the evil twin attack. My plan was creating fake access point with same SSID of their AP and sending deauthentication packets to arcade machines. After then, they should connect to my AP. If it would work, I could analyze their requests to the main server.

Note : After few months later, I learnt something new about WiFi and realized that this attack would never work. Since the target AP is protected with WPA2 and I didn’t know the password, disconnected devices won’t connect to my fake AP since they won’t be able to do a handshake. Evil twin attack is useful for faking open networks or abusing human behaviour, not for automated machines.

I prepared my laptop and a tool that I can’t remember it’s name for this attack. I could not conduct this attack from outside of the store. I had to create a strong signal to make this work. Because of that, I started the tool, packed my backpack and went inside the store. I picked up medium-crowded hour to not get any attention.

The Chaos

When I walked for 20 seconds inside the store, I was surprised. Most of the machines wasn’t working, people were swiping their cards over and over again. I went to the broken machines and saw these:

At this moment, I was terrified. I realized that my evil twin attack broke those machines. I immediately run away from the store, opened up my laptop and stopped the attack. After 5 minutes, I turned back to the store again. Machines were still broken! Somehow, they couldn’t get IP address.

The DoS Vulnerability

To validate this vulnerability, I went to another store and targeted just one arcade machine with deauthentication packets. I stopped the attack, went inside the store and started to look for a broken machine. I didn’t find any broken machine. After a while, I realized that they are not using Intercard brand but using Embed.

I visited another branch of the arcade which uses Intercard. Conducted an deauthentication attack to a single machine and found a broken one. So this is definitely a vulnerability on Intercard’s side.

I decided not to publish this vulnerability since any attacker may take down an arcade amusement with a laptop and an Alfa card for days, maybe weeks. I tweeted about this. But later on, I’m convinced that this is a problem that Intercard must fix to help their customers. It’s a basic attack, any medium-skilled attacker can find this out.

I sent details to Intercard but couldn’t get any response back. That’s why, I posted this publicly.

Share this:

Serving Django App Statically at The Lowest Cost Possible

2019-11-02T10:39:08+03:00

Two months ago, I was planning to publish a mobile app for both Android and iOS devices. However, I didn’t know how to code mobile apps natively. I found that there is an app type called “Webview” in which you just prepare a mobile friendly website and serve it inside the app. That was cool. So I coded the web application with Django framework. I just need to install it to a server, set a domain name and go. But what if I have thousands of active users in the future, how much resources will I need. Also, what if my competitors conduct DDOS attacks, will I have time or budget to deal with it? Answer was no. So I need some alternative methods.

Basically, web application were doing following things:

Gather stats about football games from an API
Do predictions with precomputed machine learning model
Serve results inside the app

The first thing came into my mind was using a serverless architecture. I’m a big fan of that concept. It reduces the cost, attack surface, maintenance struggles. I coded few AWS Lambda functions before, for 10-15 users. But when I calculated the cost of thousands of users, it wasn’t cheap as I thought. Lambda+API Gateway would cost higher than $40 per month.

I’m also big fan of static websites. It reduces the cost and attack surface much higher than the serverless architecture. For example, I’m publishing this blog statically via AWS S3 by using Jekyll framework. Since my Django app has no user interaction, I thought maybe I can serve it as a static website as well.

I researched it a lot, tried couple of open source projects but no luck. I always encountered problems. There was no stable solution for converting a Django app to a static website. So I decided to make my own process. After some trials, my old friend httrack was the most stable solution.

So I created a Python script locally which covers everything. The overall process was like that:

Gather data, do secret calculations and write results to Django’s sqlite database:

with open('games.json') as json_file:
    data = json.load(json_file)
    for i in data.items():
        cursor.execute("INSERT INTO deepapp_bet(home_team,away_team,date,country,pick) VALUES(?,?,?,?,?)",
            (i[1]['home_team'],i[1]['away_team'],i[1]['date'],i[1]['country'],i[1]['pick']))   

Run Django web server locally:

proc = subprocess.Popen(["python3","/opt/deepscore/manage.py","runserver"])

Clone Django website with httrack

d = subprocess.check_output(['/usr/bin/httrack "http://127.0.0.1:8000" -O ' +base_dir+'/out -*.png -*.css -*.svg'],shell=True)

I had to change URLs inside the HTML files with http://127.0.0.1:8000 with my production URL:

def findReplace(directory, find, replace, filePattern):
    for path, dirs, files in os.walk(os.path.abspath(directory)):
        for filename in fnmatch.filter(files, filePattern):
            filepath = os.path.join(path, filename)
            with open(filepath) as f:
                s = f.read()
            s = s.replace(find, replace)
            with open(filepath, "w") as f:
                f.write(s)

findReplace(base_dir+"/out/127.0.0.1_8000", "http://127.0.0.1:8000", "https://deepscoreapp.com", "*.html")
findReplace(base_dir+"/out/127.0.0.1_8000/match", "http://127.0.0.1:8000", "https://deepscoreapp.com", "*.html")                

Send data to S3 bucket:

d = subprocess.check_output(['/usr/local/bin/aws s3 sync . s3://prodwebsite.com'],shell=True,cwd=base_dir+"/out/127.0.0.1_8000")

Bonus: Redirecting Users Based on Their Country With Cloudflare Workers

There is one thing I didn’t mention in the first part. If user is located in Turkey, I need to redirect zhe to website.com/tr. It was possible with the Django app, but I can’t run any code since whole website lies statically on a S3 bucket. Cloudflare workers was the solution for that. By writing some Javascript code, you can achieve the same goals with the original Django application.

This my script which redirects users to specific URIs, according to their countries

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  let url = new URL(request.url)
  let path = url.pathname.split('/')[1]
  let country = request.headers.get('CF-IpCountry')
  if (path == "static" || path == "media"){
    return fetch(url)
  }
  if (country == 'TR') {
    if (path == "match"){
      return fetch('https://deepscoreapp.com/tr/match/'+url.pathname.split('/')[2])
    }
    else{
      return fetch('https://deepscoreapp.com/tr/'+path)
    }
      
    
  }
  else{
    if (path == "match"){
      return fetch('https://deepscoreapp.com/match/'+url.pathname.split('/')[2])
    }
    else{
      return fetch('https://deepscoreapp.com/'+path)
    }
  }
}

Results

I got 346,700 requests yesterday and Cloudflare cached most of them (images, css etc.)

And my monthly S3 cost is too low 😍:

The mobile app’s name is “Deepscore”, you can download it from both Google Play and App Store if you are interested in football predictions :)

Share this:

An Empire Module to Detect PII Data in Office Documents

2019-10-29T10:39:08+03:00

I coded an Empire module which detects PII data in given Office documents. You can access to the pull request of mine which includes the module from here: https://github.com/BC-SECURITY/Empire/pull/4

Or, you can get the powershell script alone in here: https://gist.github.com/utkusen/03c8ff388e76d45c1ec79580772d8a78

Share this:

Generating Personalized Wordlists with NLP For Password Guessing Attacks

2019-08-12T10:39:08+03:00

TL;DR

I coded a tool named Rhodiola which can analyze data about a target (for example target’s tweets) and detects most used themes in there and builds a personalized wordlist for password guessing. It’s an experimental project for creating a new approach for password guessing attacks.

Introduction

Passwords are our main security mechanism for digital accounts since the beginning of the internet. Because of that, passwords are one of the main targets of attackers. There are couple of major ways that an attacker can use to find a target’s password. The attacker can prepare a phishing website to trick a target into entering their passwords to a rogue website. Or, an attacker can conduct a password guessing attack through brute forcing. Password guessing attacks can be described in two main categories: online attacks and offline attacks.

Online password guessing attack is where the attacker sends username/password combinations to a service like HTTP, SSH etc. and tries to identify the correct combination by checking the response from the services. An offline password guessing attack is usually conducted against hashed forms of passwords.The attacker has to calculate a password’s hash with a suitable cryptographic hashing function and should compare it with target hash. For both online and offline attacks, the attacker usually needs to have a password wordlist. Most of the web applications have password complexity rules where users have to use at least one number, upper/lower case letters and a special character. Also there are lot’s of precautions such as IP blocking, account freezing etc. Therefore, reducing the number of trials is very important for attackers.

Mask Attacks

Mask attack is one of the main methods for reducing the brute force pool to an acceptable size. Mask attack refers to specifying a fixed password structure and generating candidate passwords according to that. For example, to crack ”Julia1984” as a password with pure brute force approach, we need to calculate 13.537.086.546.263.552 different combinations. But if we set a mask with its structure, we can reduce the combination pool to 237.627.520.000. But of course, it’s still too much for the online attacks. We usually can’t send two hundred billions request to an application over internet.

Sherlock’s Way

However, pure brute force and mask attacks are not the only way for password guessing. There is also a science fiction method based on smart guessing. For example on Sherlock’s Hound of Baskerville episode, Sherlock Holmes was checking personal stuff of the target and were guessing the correct password in one shot. But how can we do it in real life?

Let’s assume that target is posted that tweet and we are a Sherlock Holmes candidate. We can make following deductions: target’s daughter name is Julia and target loves her so much since he or she tweets about her. And target’s favorite author is George Orwell, who’s most popular book is 1984. So combine them together, the answer is “Julia1984” Is this that simple?

According to experiments conducted by Carnegie Mellon and Carleton universities, most people are choosing words for their passwords based on personal topics such as hobbies, work, religion, sports, video games, etc.[1][2] This means that most of the user passwords are contains meaningful words and they are related with the password’s owner. So in theory, we can become a sherlock holmes on password cracking. Let’s validate this.

Analyzing Myspace and Ashley Madison Wordlists

When we analyze leaked Myspace and Ashley Madison password lists with PACK (Password Analysis and Cracking Kit) and generate the most used masks, we can see that almost 95% percent of the passwords are formed by sequential alphabetic characters. So there is a high probability that these are meaningful words. Some of the most popular masks are:

?l?l?l?l?l?l: 7%
?l?l?l?l?l?l?l?l: 7%
?l?l?l?l?l?l?l: 6%
?l?l?l?l?l?l?d?d: 4%
?l?l?l?l?l?l?l?l?l: 4%

Since both Ashley Madison and Myspace wordlists are mostly consists of sequential alpha characters, there is a high probability that they are meaningful words. If they are somehow meaningful, we can fill the mask with meaningful words instead of brute forcing the characters. The first step is understanding if a letter sequence is a meaningful word in the English language. We can state that a letter sequence is an English word if it’s listed in an English lexicon. I used Wordnet as the lexicon. The analyze is showed that almost fourthy percent of those wordlists are included in Wordnet lexicon, hence they are meaningful English words.

After it’s confirmed that the letter sequence is included in Wordnet, hence it’s an English word, we need to do part-of-speech tagging (POS tagging). There are eight parts of speech in the English language: noun, pronoun, verb, adjective, adverb, preposition, conjunction, and interjection. POS tagging is the process of marking up a word in a text as corresponding to a particular part of speech. NLTK Python library is used for POS tagging.

To understand which part of speech is usually located in human-designed passwords, we’ve analyzed Myspace and Ashley Madison wordlists again.. The code that was used to analyze named ”word classifier.py” is located in here The result showed that most of the words are singular nouns (32%)

If we use all words in the Oxford English Directory, the combination pool will be 171,476. If we use ”?l?l?l?l?l?l” mask to brute force all six-character alphabetic strings, the combination pool will be 308.915.776. So, trying all English words in dictionary would be 1801 times faster than using a mask. But 171,476 is a still big number for online attacks.

Sherlock’s Way (Again)

So let’s recap what kind of facts that we have so far. First, our analyze is showed that people are using meaningful words for their passwords. And the second, from the research conducted by various of universities, we know that passwords are mostly based on personal topics. So Sherlock Holmes method is legit in theory. But can it be done in practise? What Sherlock Holmes did was analyzing personal topics about the target. Then, he combined them in his mind and came up with a candidate password.

But can we do it in real life? To achieve this, we need information about target and an algorithm which extracts good password candidates from that information. We need a data source about the target just like Sherlock Holmes had. We need a source where we can find hobbies and other interest areas of the target. We all know that kind of source. It’s Twitter of course. In Twitter, people are tend to write posts about their hobbies and other interest areas. Since there is a character limitation for the tweets, users should write things more focused. And this make things easier for us. We don’t need to deal with large, gibberish texts. So let’s use the Twitter as a data source and try to build our personalized wordlist generator algorithm.

Building the Algorithm

Downloading and Cleaning Tweet Data

First of all, we need to gather tweets from target via Twitter’s API. Since our goal is to identify a user’s personal topics and generate related words about it, we need to remove unnecessary data (stop words) from downloaded tweets. Both NLTK’s stopwords extension and a custom list are used. Lists contains high-frequency words like ”the,a,an,to,that,i,you,we,they”. These words are removed before processing the data. We also removed verbs since passwords are mostly contains nouns.

Identifying Most Used Nouns and Proper Nouns

As shown in the previous section, almost 32% of the user passwords are consists singular nouns. Therefore, our first goal is to identify the most used nouns and proper nouns. The topics that the user is interested most can be identified with them. The most used nouns and proper nouns are identified with NLTK’s POS tagging function. For the example tweet above, nouns are: author and daughter. Proper nouns are: George Orwell and Julia.

Pairing Similar Words

In some cases, nouns can be used together. To create meaningful word pairs, we need to analyze their semantic similarities. For this purpose, NLTK’s path similarity[16] is used with the first noun meaning (n.01) on Wordnet for all identified nouns. The path similarity returns a score denoting how similar two word senses are, based on the shortest path that connects the senses in the is-a (hypernym/hyponym) taxonomy. The score is in the range 0 to 1. Our algorithm pairs any two nouns if their similarity score is higher than 0.12.

Researchers have found that some of the most used semantic themes in passwords are locations and years. Therefore, related locations and years to a user’s interest areas should’ve been found. Wikipedia is used for both works. Our algorithm visits each proper noun’s Wikipedia page and parses years with regex and identifies city names with its hardcoded city list. In the example tweet above, when we send “George Orwell” to Wikipedia, our algorithm will parse words such as London, 1984 etc.

Combining Everything

The last step is combining all of our data. From the example Tweet we got George Orwell word, we sent it to Wikipedia and it returned us 1984. Beyond that we also had Julia as a proper noun. So when we combine all of our data, we will have the correct password “Julia1984” in somewhere in our wordlist. So instead of millions of combinations, we could crack this password just like Sherlock Holmes.

Rhodiola Tool

Rhodiola is written in Python 2.7 and mostly based on NLTK and textblob libraries. With a given Twitter handle (If you don’t have that one, you can bring your own data. Check the Github page for details), it can automatically can compile a personalized wordlist with the following elements: Most used nouns&proper nouns, paired nouns&proper nouns, cities and years related to detected proper nouns. For example:

For detailed usage check it’s Github page: https://github.com/tearsecurity/rhodiola

Conclusion

Since people tend to use words from their interest areas for their passwords and expose those interest areas on Twitter, it’s possible for an attacker to create a wordlist by analyzing a target’s tweets. Beyond Twitter, any actor that has much more data about a person will have an ability to create more accurate wordlists. Therefore, users should avoid using words from the topics that are exposed in social media. It’s better to use random passwords that are stored in a password manager software.

Share this:

Siber Güvenliğin Gelecek 30 Yılı İçin Kehanetler

2019-07-26T10:39:08+03:00

Bu yazım, Arkakapı dergisinin 5. sayısında yer almaktadır.

Geleceği tahmin etmek, her sektörde olduğu gibi siber güvenlikte de önem teşkil eder. Gelecekte siber güvenlik sektörünün nereye doğru ilerleyeceğini bilmek şirketler için kar, devletler için stratejik üstünlük anlamına gelir. Bu tip tahminlerde bulunan danışmanlık firmaları dünyada mevcut. Ancak bunların yaptığı gelecek tahminleri, 2-5 yıl gibi kısa vadeli oluyor. Biz ise bu yazıda 30-40 yıllık bir süreçte nereye doğru gidebileceğimizi hayal edeceğiz. Her beş senede bambaşka bir hale gelen teknoloji dünyasında, bu denli uzak geleceği tahmin etmek imkansız görünebilir. Ancak siber güvenlik dünyasında, insanlığın tarihsel süreçte yaşadığı olayların konsantre bir izdüşümünü görmek mümkün. Güvenlik kameralarının ve adli tıbbın olmadığı eski çağlarda suçluların tespit edilmesi çok zordu. 1800’lere gelindiğinde ise adli tıp ilerlemiş, dedektiflik yaygın bir meslek haline gelmişti. Günümüzde ise suçluların tespiti çok daha kolay hale geldi. Bu izdüşüme göre 2018 yılındaki siber güvenlik dünyası, 1800’lerin fiziksel dünyasına benziyor. 1800’lerden sonra yaşanan tarihsel süreci incelersek, siber güvenliğin önümüzdeki 30-40 yıl içinde yaşayacağı değişimleri, biraz hayal gücünün de yardımıyla tahmin edebiliriz.

Bu yazıda 2030, 2040 ve 2050 yılları civarında gerçekleşeceğini tahmin ettiğim üç ana olaya değineceğim.

2030 - Güvenlik Sektöründe Yaşanacak İşsizlik Problemi

2000’li yılların başında web ve internet teknolojileri dünyada yeni yeni yaygınlaşıyorken, işin güvenlik tarafı insanların aklını çok kurcalamıyordu. Bu dönemde ortaya çıkan macera filmlerinde hacker temaları işlense de, günlük hayatımıza verebilecekleri zararlar bir bilim kurgu senaryosundan öteye gitmiyordu. Fakat yıllar ilerledikçe teknoloji, günlük hayatın her köşesine işledi. Dolayısıyla işin güvenlik kısmı çok kritik bir durum haline geldi. Fakat gerekli olan güvenlik elemanı sayısında hala büyük bir eksiklik var. Bu yüzden gelecek tahmini yapan kurumlar, dijitalleşme ileride daha da artacağı için, güvenlik elemanı ihtiyacının da artacağını öngörüyor. Bu tespit bana asansör operatörlerinin durumunu anımsatıyor. Asansör ilk icat edildiğinde çalışması, bir insan operatörün yardımıyla mümkün oluyordu. O dönemde asansörlerin tüm dünyada yaygınlaşacağını göz önünde bulunduran bir kişi, insan operatörlere duyulacak ihtiyacın da artacağını söyleyebilirdi. Fakat asansörlere elektronik düğme sistemlerinin gelmesiyle insana olan ihtiyaç bitmiş, bir meslek dalı yok olmuştu.

2000’lerden günümüze güvenlik sektöründe çok büyük değişimler yaşandı. Güvenliğin kazandığı önem sayesinde defansif güvenlik teknolojileri çok ilerledi. Şirketler ve devletler varlıklarının güvenliğine büyük yatırımlar yapmaya başladı. Araştırmacılar açık kaynak kodlu yazılımlarda güvenlik açıklarını tespit edip kapatmaya başladı. Dolayısıyla 2008 ve 2018 yıllarını kıyasladığımızda, global güvenliğin oldukça iyiye gittiğini söyleyebiliriz. Peki bundan sonra nereye gidecek?

Yerli Siber Güvenlik Yazılımı Hamlesinde Gözden Kaçan Detaylar yazımda, güvenlik yazılımlarının geçirdiği evreleri şöyle sıralamıştım:

Başlangıç evresi (… - 2001)
Kullanım kolaylığı evresi (2001-2009)
Olgunluk evresi (2009-…)
Yapay zeka evresi (…-…)

Şu an içinde bulunduğumuz olgunluk evresinden yapay zeka evresine ne zaman geçeceğiz, net olarak bilemiyoruz. Fakat gidişatın kesinlikle o yönde olduğunu, pek çok farklı emare ile gözlemleyebiliyoruz. Örneğin IDS, SIEM gibi defansif güvenlik ürünleri, insana ihtiyaç duymayacak şekilde çalışma noktasına varmak üzere. Ofansif tarafta henüz emekleme döneminde olsalar da, yapay zeka hacker yazılımlarının ortaya çıktığını görebiliyoruz. Şu an bu yazılımlar deneysel ve pahalı olsa da, ileride bunlar hem daha stabil hem de ucuzlamış olacak. Dolayısıyla bu yazılımlar insan bir çalışandan daha düşük maliyetli ve daha verimli olacak.

Gidişatı göz önünde bulundurduğumda, bu döneme 2030 yılına kadar geçileceğini düşünüyorum. Peki bu dönem geldiğinde ne olacak? Hem defansif hem ofansif güvenliğin çok büyük bir kısmı otomatize hale gelecek. İnsana olan ihtiyaç, üstten bakan bir göz ve problem çıktığında düzeltmeyle sınırlı kalabilir. İşin siber savaş kısmında devletlerin insan personel ihtiyacı muhtemelen devam edecek ama özel sektör bu alanda makineleşmeyi tercih edecektir. 2030 yılına geldiğimizde, kendisini programlama, yapay zeka (ve alt dalları) gibi farklı disiplinlerde geliştirememiş orta ve alt seviye güvenlikçiler işsizlik ile karşılaşacaktır.

2040 - Sanal Pasaport ve Sanal Vize

Facebook ve Google gibi firmaların, bireylerin davranışlarını çerezler (cookie) ya da farklı yöntemlerle kayıt altında tuttuğu artık bilinen bir gerçek. Bu kişisel veriler sadece bu şirketler ya da ABD devleti tarafından gayrıresmi olarak kullanılsa da, gelecekte bu durumun farklı olacağını düşünüyorum. Çünkü günümüzde siber suçların durdurulamamasının en önemli sebeplerinden biri, suçluların gerçek kimliğinin tespit edilememesidir. Google gibi şirketlerin sahip olduğu kişi profilleri kimi zaman suçlu tespitine yardımcı olsa da, büyük bir çözüm sağlamıyor. Bunun yanında TOR gibi servisler de kişinin gerçek IP adresini saklamasına yardımcı oluyor.

TOR ve diğer VPN servislerinin hala işe yarıyor olması, internetin herkese açık olmasının bir sonucudur. Örneğin Endonezya’da yaşayan bir insan, turkiye.gov.tr’ye girebilir, bir güvenlik açığı bulursa buraya zarar verebilir. Turkiye.gov.tr sitesinin yöneticileri “Endonezya’da yaşayan birinin bu siteye girmesine gerek yok” diye düşünüp o ülkeyi engelleyebilir, hatta Türkiye hariç tüm dünyayı engelleyebilir. Ama bu durumda yurtdışında yaşayan Türk vatandaşları siteye nasıl girecek? Ülke engelleme bu tip konularda kalıcı bir çözüm olamaz. Kalıcı çözüm ise gelecekte var olacağını düşündüğüm sanal pasaport sistemi.

İnsanların anonim bir şekilde internette dolaşmasını engelleyerek siber suçları durdurmayı hedefleyen “Evilcorp” isminde bir şirket hayal edelim. İnsanlar Evilcorp şirketinin ürünü olan “elektronik pasaportu” gerçek kimlik bilgileriyle alabiliyorlar. Kişi elektronik pasaport aldıktan sonra, internette yolladığı her isteğin içinde bu pasaport bilgileri yer alacak. Evilcorp ile entegre olan websiteleri, ziyaretçilerine sanal pasaport kontrolü yapabilecek. Örneğin bazı ülke vatandaşlarını tamamen engelleyebilir, fakat bu ülkedeki bazı vatandaşlara -öğrenciler, akademisyenler vs.- giriş vizesi verebilir. O dönemin büyük bulut şirketleri Evilcorp ile entegre olacak ve internetin büyük bir bölümünde sanal pasaportsuz dolaşım mümkün olmayacak.

2050 - Bireysel Hacking’in ve Hacker’lar Çağının Bitişi

Tarih boyunca insanlık, farklı suç trendlerine ve gruplarına maruz kalmıştır ve bunlarla mücadele yöntemleri geliştirmiştir. Buna örnek olarak deniz korsanlığını verebiliriz. MÖ 14. Yüzyıldan başlayan korsanlık tarihi 1800’lere kadar sürmüştür. Çeşitli kültürlerde hackerlara korsan benzetmesi yapılır. Örneğin ülkemizde “hacker” kelimesinin TDK karşılığı “bilgisayar korsanı”dır. Bu benzetme mantıksız değildir. İnterneti okyanusa, bilgisayarları gemilere ve hackerları korsanlara benzetebiliriz. Peki asırlarca süren korsanlık geleneği 1800’lerde nasıl bitirildi? Okuduklarıma göre burada etkili olan iki konu var: Birincisi, İngiliz donanmasının denizlerde yaptığı devriyelerin sayıca çok artması ve bu devriyelerin silah gücünün korsanlardan fazla olması. İkincisi, korsanların ticaret yaptığı limanların devletler tarafından kapatılması. Gelir yollarının kesilmesi ve baskıların artmasıyla korsanlar, bu kadim suç geleneğini terk etmek zorunda kalmıştır. Bitmez denen deniz korsanlığı tarihe karışmıştır.

Tabi ki hackerların tek motivasyonu maddi kazanç değil. Bu yüzden korsanlar gibi kazanç yolları kesilse bile hacking faaliyetleri bitmeyecektir. Fakat buna rağmen gelecekte hackingi bitirecek iki temel konu var. Birincisi önceki başlıkta bahsettiğimiz sanal pasaportlar ile her internet kullanıcısının nerede ne yaptığı kayıt altında olacağı için hacking, büyük cesaret isteyen bir suç haline gelecektir. Bugün bir insanı öldürüp yakalanmamak ne kadar zorsa, gelecekte hacking de böyle olacaktır. Bunun yanında 2000’lerden günümüze baktığımızda defansif güvenlik teknolojilerinin çok güç kazandığını görüyoruz. Bu durum muhtemelen böyle devam edecektir ve gelecekte bir sistemin hacklenmesi, sadece çok büyük aktörlerin yapabileceği bir şey haline gelecektir.

Sonuç olarak hacking faaliyetleri askeri ve istihbari bir yöntem olmakla sınırlı kalacak, bireysel hacking tarihe karışacaktır. Hacking kültürü muhtemelen bu kadar kısa sürede bitmeyecektir. Ancak bireylere inmeyen faaliyetlerin, bir kültür olarak uzun süre devam etmesi de mümkün gözükmüyor. Bundan 200 yıl sonra tarihçiler hackerları yazarken 1980-2050 arasında faaliyet gösteren insanlar olarak niteleyecek, dönemin gençleri kostüm partilerine önünde hacker amblemleri olan siyah kapüşonlularla katılacaktır.

Utku Sen - Blog

Hash Olympics - A Hash Cracking Contest Without Good Hardware

Contest Process

Our experience

Conclusion

Türkçe Wordlist Çalışmasında İkinci Faz

Giriş

Siber Güvenlik Sektöründeki Maaş Dağılımı Araştırması

Giriş

Grafik Açıklamaları

Tüm Sektör

Ofansif Güvenlik

Defansif Güvenlik

Güvenlik Analisti

Güvenlik Mimarı

Yazılımcı

Ürün Yöneticisi

Bilgi Güvenliği

Koordinatör

Satış/Destek

Takım Lideri

Yönetici

Security by Obscurity is Underrated

Risk, Defense in Depth and Swiss Cheese

Security by Obscurity

Other Applications

Real Life Applications

Conclusion

Torture-Proof Authentication

An Experiment: Authentication via Body Motions

A Futuristic Approach

More Realistic Approaches

An Introduction to Arcade Security

Learning The Fundamentals

Testing For Race Condition

Bruteforcing Staff Card’s ID

Attempts For Infiltrating The Arcade Network

Capturing and -can’t- Cracking WiFi Handshake

Evil Twin Attack

The Chaos

The DoS Vulnerability

Serving Django App Statically at The Lowest Cost Possible

Bonus: Redirecting Users Based on Their Country With Cloudflare Workers

Results

An Empire Module to Detect PII Data in Office Documents

Generating Personalized Wordlists with NLP For Password Guessing Attacks

TL;DR

Introduction

Mask Attacks

Sherlock’s Way

Analyzing Myspace and Ashley Madison Wordlists

Sherlock’s Way (Again)

Building the Algorithm

Downloading and Cleaning Tweet Data

Identifying Most Used Nouns and Proper Nouns

Pairing Similar Words

Finding Related Helper Words

Combining Everything

Rhodiola Tool

Conclusion

Siber Güvenliğin Gelecek 30 Yılı İçin Kehanetler

2030 - Güvenlik Sektöründe Yaşanacak İşsizlik Problemi

2040 - Sanal Pasaport ve Sanal Vize

2050 - Bireysel Hacking’in ve Hacker’lar Çağının Bitişi