Crypto-anchors, "Kirpto Çapa" , "Kriptoiz"

En eski bilişim firmalarından IBM son zamanlarda yeni teknolojilerle de kendinden bahsettirmeyi becerebiliyor. Özellikle blokzinciri teknolojisine yaptıkları yatırımlarla dikkat çeken firma, şimdi de buna bağlı yenilikçi bir çözüm geliştirdiğini açıkladı. ‘Crypto Anchor Verifier’ adı verilen çözüm, her yıl dünya çapında ticarete 600 milyar dolardan fazla zarar veren bir dert olan sahte ürünlerle mücadele etmek için geliştirilmiş. Crypto Anchor Verifier bu amaçla yapay zeka, makine görüşü ve blokzincirini biraraya getiriyor.
Bu teknolojinin türkçesi konusunda düşünürken tam çevirisi olarak "Kripto Çapa" kullanılabilir fakat ben bunun yerine anlamsal ve kullanım olarak daha iyi olacağını düşündüğüm "Kriptoiz" kelimesini türettim. Bu kullanımın daha uygun olacağı kanısındayım.

22.11.2018 16:19:00

Crypto-anchors , Kirpto Çapa, Kriptoiz , Crypto-anchors , Kirpto Çapa , Kriptoiz, Crypto-anchors , Kirpto Çapa, Kriptoiz , Crypto-anchors , Kirpto Çapa , Kriptoiz, Crypto-anchors , Kirpto Çapa, Kriptoiz , Crypto-anchors , Kirpto Çapa , Kriptoiz

Petya petrWrap Goldeneye NonPetya NotPetya Ransomware Önlemleri

Çağrı Polat beyin derlediği yazısını paylaşmak isterim. Kendisine ait bloga ulaşmak için burayı tıklayabilirsiniz.

Ukrayna'da başlayan kapsamlı siber saldırıların dünya çapında birçok şirkete yayıldığı bildiriliyor. Fidye yazılım kullanılarak siber saldırılar düzenlendiği bildirilen ülkeler arasında Rusya, ABD, İngiltere, Hollanda, Hindistan ve ve Norveç de var.

Son saldırılardan ekilendiğini açıklayan diğer şirketler arasında ise Rus petrol üreticisi Rosneft ve Danimarkalı taşımacılık şirketi Maersk de bulunuyor. Ayrıca Ukrposhta, Boryspil International Airport in Kiev,Maersk, Kyivenergo, Kiev power company,Radiation monitoring system at Chernobyl,Ukrainian bank Oschadbank,Ukrainian delivery service company Nova Poshta, Spanish global legal firm DLA Piper firmaları da etkinlenen firmalar arasında..

Bilgisayar kullanıcısının yetki vermesinin ardından Petya önce kendini ana önyükleme kaydına yazıyor ardından mavi ekran verip bilgisayarı resetliyor.

Yayılmak için WannaCry tarafından ağa sızmak için kullanılan SMB (EternalBlue) açığını ve ardından ağda yayılmak için PsExec kullanıyor gibi görünüyor. Bu tehlikeli kombinasyon, önceki saldırılar sonucunda çoğu açığın kapatılmış olmasına rağmen salgının hızla küresel olarak yayılmasınına neden oluyor. Ağa sızabilmesi için tek bir yama yüklenmemiş, açıkları mevcut bilgisayar yeterli oluyor. Daha sonra zararlı yazılım, yönetici haklarını alabilir ve diğer bilgisayarlara yayılabilir.

Fig: Execution Process of Petya

Gene saldırı vektörü olarak bildiğimiz  MS17-010 SMBv1 zafiyeti kullanılmış ve oltalama(phishing) ile kurbanlar istismar ediliyor:

Alınacak Önlemler:

1. Ağınızdaki Windows işletim sistemlerinde MS17-010 yamasının geçildiğinden emin olunuz. (https://technet.microsoft.com/en-us/library/security/ms17-010.aspx ) 
2. Cihazlarınızın ve WAN tarafında eğer açıksa UDP port 137 ve 138, TCP port 139 ve 445'i kapatınız.
3. Yedekleme politikanızı yeniden gözden geçirin ve baskın veri çekimlerini planlayınız.
4. Kullanıcıların yerel yönetici hesaplarını alarak normal kullanıcı olarak çalıştırtınız.
5. Local admin şifrenizi basit ise değiştirin ve her cihazda sabit olmadığından emin olunuz.
6. CVE-2017-0199 Ofis RCE yamasını yapınız.(https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-0199)
7. Kaynağından emin olmadığınız ve sizle alakası bile olmayan konulardaki e-postaları açmayınız.
8. Kullanıcılara konu ile alakalı bilgilendirme mailleri atınız.
9. SMBv1 hala yapmadı iseniz disable ediniz.
10. GPO kullanarak SMB ve WMI protokollerini bloklayınız.
11. cmd /k shutdown -a ile cihazı kapatma özelliğini devre dışı bırakınız.
12. appdata ve temp dizinde executable dosya çalıştırtmayı engelleyiniz.
13. Order-20062017.doc, myguy.xls, BCA9D6.exe, myguy.xls.hta dosyaları için uyanık olunuz.
14. 141.115.108, 165.29.78, 200.16.242 ve 90.139.247 ip blokları ile haberleşen cihazları izole ediniz. Ayrıca 185.165.29.78,84.200.16.242,111.90.139.247,95.141.115.108,95.141.115.108,185.165.29.78,84.200.16.242,111.90.139.247 IP adreslerini de bloklamanızı tavsiye ediyoruz.

Uyarı:

Zararlı yazılım geliştiricisi ödemeleri wowsmithxxxx@posteo.net  e-posta hesabı kullanarak bitcoin üzerinden toplamaktadır. Saldırıda kullanılan e-postanın sağlayıcısı Posteo, Petya zararlısını yayan e-posta hesabını kapattığını açıkladı.

Dosyalarınızı geri almak için tüm iletişim yolları kapalı, bu durumdan dolayı fidye ödememenizi tavsiye ediyoruz.

Kaynaklar:

- https://www.cyberbit.com/endpoint-security/petya-ransomware/

- http://www.bbc.com/turkce/amp/haberler-dunya-40416070
- ESET Security Bulletin
- https://twitter.com/TRCert
- https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/
- http://blog.talosintelligence.com/2017/06/worldwide-ransomware-variant.html
- Netsec Ömer Albayrak E-mail

This Phishing Attack is Almost Impossible to Detect On Chrome, Firefox and Opera

A Chinese infosec researcher has reported about an "almost impossible to detect" phishing attack that can be used to trick even the most careful users on the Internet.

He warned, hackers can use a known vulnerability in the Chrome, Firefox and Opera web browsers to display their fake domain names as the websites of legitimate services, like Apple, Google, or Amazon to steal login or financial credentials and other sensitive information from users.

What is the best defence against phishing attack? Generally, checking the address bar after the page has loaded and if it is being served over a valid HTTPS connection. Right?

Okay, then before going to the in-depth details, first have a look at this demo web page (note: you may experience downtime due to high traffic on demo server), set up by Chinese security researcher Xudong Zheng, who discovered the attack.

“It becomes impossible to identify the site as fraudulent without carefully inspecting the site's URL or SSL certificate.” Xudong Zheng said in a blog post.

If your web browser is displaying "apple.com" in the address bar secured with SSL, but the content on the page is coming from another server (as shown in the above picture), then your browser is vulnerable to the homograph attack.

There is another proof-of-concept website created by security experts from Wordfence to demonstrate this browsers' vulnerability. It spoof "epic.com" domain.

Homograph attack has been known since 2001, but browser vendors have struggled to fix the problem. It’s a kind of spoofing attack where a website address looks legitimate but is not because a character or characters have been replaced deceptively with Unicode characters.

Many Unicode characters, which represents alphabets like Greek, Cyrillic, and Armenian in internationalised domain names, look the same as Latin letters to the casual eye but are treated differently by computers with the completely different web address.

For example, Cyrillic "а" (U+0430) and Latin "a" (U+0041) both are treated different by browsers but are displayed "a" in the browser address.

Punycode Phishing Attacks

By default, many web browsers use ‘Punycode’ encoding to represent unicode characters in the URL to defend against Homograph phishing attacks. Punycode is a special encoding used by the web browser to convert unicode characters to the limited character set of ASCII (A-Z, 0-9), supported by International Domain Names (IDNs) system.

For example, the Chinese domain "短.co" is represented in Punycode as "xn--s7y.co".

According to Zheng, the loophole relies on the fact that if someone chooses all characters for a domain name from a single foreign language character set, resembling exactly same as the targeted domain, then browsers will render it in the same language, instead of Punycode format.

This loophole allowed the researcher to register a domain name xn--80ak6aa92e.com and bypass protection, which appears as “apple.com” by all vulnerable web browsers, including Chrome, Firefox, and Opera, though Internet Explorer, Microsoft Edge, Apple Safari, Brave, and Vivaldi are not vulnerable.

Here, xn-- prefix is known as an ‘ASCII compatible encoding’ prefix, which indicates web browser that the domain uses ‘punycode’ encoding to represent Unicode characters, and Because Zheng uses the Cyrillic "а" (U+0430) rather than the ASCII "a" (U+0041), the defence approach implemented by web browser fails.

Zheng has reported this issue to the affected browser vendors, including Google and Mozilla in January.

Fake Page (top) and Original Apple.com (bottom), but exactly same URL

While Mozilla is currently still discussing a fix, Google has already patched the vulnerability in its experimental Chrome Canary 59 and will come up with a permanent fix with the release of Chrome Stable 58, set to be launched later this month.

Meanwhile, millions of Internet users who are at risk of this sophisticated hard-to-detect phishing attack are recommended to disable Punycode support in their web browsers in order to temporarily mitigate this attack and identify such phishing domains.

How to Prevent Against Homograph Phishing Attacks

Firefox users can follow below-mentioned steps to manually apply temporarily mitigation:

1. Type about:config in address bar and press enter.
2. Type Punycode in the search bar.
3. Browser settings will show parameter titled: network.IDN_show_punycode, double-click or right-click and select Toggle to change the value from false to True.

Unfortunately, there is no similar setting available in Chrome or Opera to disable Punycode URL conversions manually, so Chrome users have to wait for next few weeks to get patched Stable 58 release.

Although, there are some third-party Chrome extensions/add-ons available on App Store that users can install to get alerts every time they came across any website with Unicode characters in the domain.

Meanwhile, one of the best ways to protect yourself from homograph attacks is to use a good password manager that comes with browser extensions, which automatically enter in your login credentials for the actual domains to which they are linked.

So, whenever you came across any domain which looks like legitimate "apple.com" or "amazon.com" but actually is not, your password manager software will detect it and will not automatically authenticate you to that phishing site.

Moreover, Internet users are always advised to manually type website URLs in the address bar for important sites like Gmail, Facebook, Twitter, Yahoo or banking websites, instead of clicking any link mentioned on some website or email, to prevent against such attacks.

Update: Opera has also released a security patch to prevent possible phishing attacks with Unicode domains with the release of its stable build, Opera Stable 44.0.2510.1449. Browser installation links for Windows, macOS, and Linux are available on the company's official site.

Source : http://thehackernews.com/2017/04/unicode-Punycode-phishing-attack.html?m=1

Author : Mohit Kumar
Entrepreneur, Hacker, Speaker, Founder and CEO — The Hacker News and The Hackers Conference.

Wi-Fi Security: Should You Use WPA2-AES, WPA2-TKIP, or Both?

AES vs. TKIP

TKIP and AES are two different types of encryption that can be used by a Wi-Fi network. TKIP stands for “Temporal Key Integrity Protocol.” It was a stopgap encryption protocol introduced with WPA to replace the very-insecure WEP encryption at the time. TKIP is actually quite similar to WEP encryption. TKIP is no longer considered secure, and is now deprecated. In other words, you shouldn’t be using it.
AES stands for “Advanced Encryption Standard.” This was a more secure encryption protocol introduced with WPA2, which replaced the interim WPA standard. AES isn’t some creaky standard developed specifically for Wi-Fi networks; it’s a serious worldwide encryption standard that’s even been adopted by the US government. For example, when you encrypt a hard drive with TrueCrypt, it can use AES encryption for that. AES is generally considered quite secure, and the main weaknesses would be brute-force attacks (prevented by using a strong passphrase) and security weaknesses in other aspects of WPA2.
The “PSK” in both names stands for “pre-shared key” — the pre-shared key is generally your encryption passphrase. This distinguishes it from WPA-Enterprise, which uses a RADIUS server to hand out unique keys on larger corporate or government Wi-Fi networks.

WPA Uses TKIP and WPA2 Uses AES, But…

In summary, TKIP is an older encryption standard used by the old WPA standard. AES is a newer Wi-Fi encryption solution used by the new-and-secure WPA2 standard. In theory, that’s the end of it. But, depending on your router, just choosing WPA2 may not be good enough.
While WPA2 is supposed to use AES for optimal security, it also has the option to use TKIP for backward compatibility with legacy devices. In such a state, devices that support WPA2 will connect with WPA2 and devices that support WPA will connect with WPA. So “WPA2″ doesn’t always mean WPA2-AES. However, on devices without a visible “TKIP” or “AES” option, WPA2 is generally synonymous with WPA2-AES.

Wi-Fi Security Modes Explained

Confused yet? We’re not surprised. But all you really need to do is hunt down the one, most secure option in the list. For example, here are the options our Comcast Xfinity router provides:

• Open (risky): Open Wi-Fi networks have no passphrase. You shouldn’t set up an open Wi-Fi network — seriously, you could have your door busted down by police.
• WEP 64 (risky): The old WEP encryption standard is vulnerable and shouldn’t be used. Its name, which stands for “Wired Equivalent Privacy,” now seems like a joke.
• WEP 128 (risky): WEP with a larger encryption key size isn’t really any better.
• WPA-PSK (TKIP): This is basically the standard WPA, or WPA1, encryption. It’s been superseded and isn’t secure.
• WPA-PSK (AES): This chooses the older WPA wireless protocol with the more modern AES encryption. Devices that support AES will almost always support WPA2, while devices that require WPA1 will almost never support AES encryption. This option makes very little sense.
• WPA2-PSK (TKIP): This uses the modern WPA2 standard with older TKIP encryption. This isn’t secure, and is only a good idea if you have older devices that can’t connect to a WPA2-PSK (AES) network.
• WPA2-PSK (AES): This is the most secure option. It uses WPA2, the latest Wi-Fi encryption standard, and the latest AES encryption protocol. You should be using this option. On devices with less confusing interfaces, the option marked “WPA2″ or “WPA2-PSK” will probably just use AES, as that’s a common-sense choice.
• WPAWPA2-PSK (TKIP/AES) (recommended): Our Comcast Xfinity router recommends this free-for-all option. This enables both WPA and WPA2 with both TKIP and AES. This provides maximum compatibility with any ancient devices you might have, but also ensures an attacker can breach your network by cracking the lowest-common-denominator encryption scheme. This TKIP+AES option may also be called WPA2-PSK “mixed” mode.

Devices Manufactured Since 2006 Must Support AES

WPA2 certification became available in 2004, ten years ago. In 2006, WPA2 certification became mandatory. Any device manufactured after 2006 with a “Wi-Fi” logo must support WPA2 enctyption. That’s now eight years ago!
Your Wi-Fi enabled devices are probably newer than 8-10 years old, so you should be fine just choosing WPA2-PSK (AES). Select that option and then you can see if anything doesn’t work. If a device does stop working, you can always change it back — although you may just want to buy a new device manufactured at any time in the last eight years.

WPA and TKIP Will Slow Your Wi-Fi Down

WPA and TKIP compatability options can also slow your Wi-Fi network down. Many modern Wi-Fi routers that support 802.11n and newer, faster standards will slow down to 54mbps if you enable WPA or TKIP in their options. They do this to ensure they’re compatible with these older devices.
In comaprison, even 802.11n supports up to 300mbps — but, generally, only if you’re using WPA2 with AES. Theoretically, 802.11ac offers theoretical maximum speeds of 3.46 Gbps under optimum (read: perfect) conditions.
In other words, WPA and TKIP will slow a modern Wi-Fi network down. It’s not all about security!

---

On most routers we’ve seen, the options are generally WEP, WPA (TKIP), and WPA2 (AES) — with perhaps a WPA (TKIP) + WPA2 (AES) compatibility mode thrown in for good measure.
If you do have an odd sort of router that offers WPA2 in either TKIP or AES flavors, choose AES. Almost all your devices will certainly work with it, and it’s faster and more secure. It’s an easy choice, as long as you can remember AES is the good one.

 

 

 

Does Hashing Make Data “Anonymous”?

One of the most misunderstood topics in privacy is what it means to provide “anonymous” access to data.  One often hears references to “hashing” as a way of rendering data anonymous.   As it turns out, hashing is vastly overrated as an “anonymization” technique.   In this post, I’ll talk about what hashing is, and why it often fails to provide effective anonymity.
What is hashing anyway?  What we’re talking about is technically called a “cryptographic hash function” (or, to super hardcore theory nerds, a randomly chosen member of a pseudorandom function family–but I digress).   I’ll just call it a “hash” for short.   A hash is a mathematical function: you give it an input value and the function thinks for a while and then emits an output value; and the same input always yields the same output.  What makes a hash special is that it is as unpredictable as a mathematical function can be–it is designed so that there is no rhyme or reason to its behavior, except for the iron rule that the same input always yields the same output.    (In this post I’ll use a hash called SHA-1.)
With that out of the way, let’s consider whether hashing a Social Security Number renders it “anonymous”.   If you hash my SSN, the result is b0254c86634ff9d0800561732049ce09a2d003e1.  (Let’s call this the “b02 value” for short.)  That looks nothing like my SSN–but that in itself does not make the value “anonymous”.   The key question is whether a person who gets the b02 value can figure out what my SSN is.
How might an analyst who has the b02 value try to determine my SSN?   One approach that doesn’t work is to try to run the hash function backward–or as a mathematician would say, to find its inverse.   Many functions can be run backward.   Consider the function that adds 17 to its input.    To run that function backward, you just subtract 17.     The hash has an inverse (of a sort) but nobody knows what it is, and as far as anyone knows it is not feasible to find the inverse.   So a smart analyst will give up on the invert-the-hash approach.
But there is another trick available to the analyst–and this trick will work.  The analyst simply guesses my SSN–he enumerates all of the possible nine-digit SSNs and hashes each one.   When he hashes my correct SSN, the result will be equal to the b02 number, so he will know that he guessed right.   You might think it would take a long time to run through all of the possible SSNs, but computers are very fast–there are “only” one billion possible SSNs, so your laptop can hash all of them in less time than it takes you to get a cup of coffee.
A clever analyst would do it even faster.   He would hash all of the possible SSNs in advance, and build an index that allowed him to recover the SSN from its corresponding hash value in the blink of an eye.   Hashing the SSN would offer no protection at all against an analyst who had built such an index.
It should be clear by this point that hashing an SSN does not render it anonymous.  The same is true for any data field, unless it is much, much, much harder to guess than an SSN–and bear in mind that in practice the analyst who is doing the guessing might have access to other information about the person in question, to help guide his guessing.
Does this means that hashing always fails, and is never a good way to scrub data?   Almost, but not quite.   There are more advanced uses of hashing that can offer some protection in some settings.  But the casual assumption that hashing is sufficient to anonymize data is risky at best, and usually wrong.
[In case you’re wondering, the b02 value is not really the hash of my SSN.  It is the hash of the text string “my SSN”.   There is no way I would publish the hash of my actual SSN.]

Source : http://techatftc.wordpress.com/2012/04/22/does-hashing-make-data-anonymous/

Data Anonymization

 
Recently, talk of “anonymizing” or “pseudo-anonymizing” data has been picking up, both publicly online and in private conversations with our clients.
There have been questions on what these terms mean, what they mean for user privacy, and the pitfalls around the practice.
Currently, “anonymizing” is not defined or clearly addressed in TRUSTe’s privacy program requirements.  However, we have developed an understanding of the practice over time that we apply evenly to all of the participants in our privacy programs.  We also provide guidance on privacy best practices to clients on this topic and other practices, which are not covered by our program requirements.
TRUSTe defines anonymizing as taking information that is currently Personally Identifiable Information (PII) and permanently turning it into non-identifying data.  We identify pseudo-anonymizing as taking data that is currently PII and turning it into non-identifying data that can be returned from its anonymized state to PII in the future.
One of the simplest forms of anonymization that takes place every day on nearly every website: analytics.  Services like Google Analytics take PII such as an IP Address combined with other detailed information, then anonymizes and aggregates the data to provide useful graphs such as the percentage of site visitors that use Mozilla Firefox.  In this situation, anonymization increases user privacy, because the site does not need to retain any PII to get the information they require.
Thus, data that can be easily de-anonymized, that is turned back into PII, does not protect privacy in the same way.  For that reason, TRUSTe does not recognize or recommend pseudo-anonymizing data.  In fact, it may do more harm than good.  Consumers may be confused or misled if you were to tell them that you retain no PII, when in fact you could at any moment (presto-changeo!) recover PII that has been pseudo-anonymized.  TRUSTe believes that anonymization must be one-way in order to be effective.
One of the most popular methods of anonymizing data (other than the aggregation described above) is hashing.  It is important to note concerns expressed by researcher Ed Felten (@EdFelten) on his blog which question whether hashing is an effective way to anonymize data at all.  Whether or not hashing is the best technological means to anonymize data, in many cases it does not have the privacy protective effect many online service providers expect.
This is because a pitfall of anonymizing data is that in some circumstances, the anonymized (or pseudo-anonymized) data itself can be PII.  For example, a web service may store a hash of a user’s email address and name, along with some other data associated with the hashed PII.  The service believes the data has been anonymized and that they have retained no PII because an attacker obtaining the hash would not know what the hash means, and the service cannot recover the user’s email address and name.  The associated data will only be recovered when the user next enters their email address and name.  While this may be a good security rationale (although again see Ed Felten’s blog on why that may not be the case), it fails to understand the privacy implications by ignoring the definition of PII.
The definition of PII is not merely a list of important pieces of information such as a phone number, address, social security number, etc. TRUSTe defines Personally Identifiable Information (PII) as “any information or combination of information that can be used to identify, contact, or locate a discrete Individual”.  In this situation, the entire reason for keeping the hashed data is to be able to identify a discrete user the next time they return to the site.  Therefore, in this case, the hash is PII.  So while it may still be a good practice to hash data in this way, online services need to understand that their obligations in how they treat this data (including notice and choice requirements) may not change simply because they believe the data has been anonymized.
Anonymization is a useful tool, but as with everything in the privacy world, context is the key.  Online services need to take the time to fully understand their decision to anonymize data, and what it does and does not mean for user privacy.
- See more at: http://www.truste.com/blog/2013/04/16/data-anonymization/#sthash.KIdcSLD7.dpuf

Source : http://www.truste.com/blog/2013/04/16/data-anonymization/