April 27, 2017

Unpatched mobiles and trojanized systems

Organizations provide their end-users means of connecting to internal network resources, typically laptops with specific operating systems under the control of IT. As technology advances, access may also be allowed also to mobile devices apart from laptops, specifically mobile phones and tablets.
IT most probably tries their best in controlling the allowed devices, but eventually usage of allowed devices can spread in negative way.

Depending on the OS of these devices the attack surface can be high, which unfortunately for Android devices is quite big. This is because of the poor vulnerability management practices provided by the device vendors. For Apple and Microsoft products the patching is currently consistent, but with Android devices many vendors neglect the patching of the core operating system.

If all vendors would follow Google's patches for Android operating system there wouldn't be such a problem. However, millions of handhelds, apart from Nexus and Pixel branded devices, are typically vulnerable for many different kind of exploits.

Devices can be taken under attacker control, even only if the user happens to visit a malicious web page or receives a malicious SMS or email with evil content. Another avenue of infection is via installing applications, the user can install software that brings the malicious capability to the device, typically through a non-approved marketplace (but also the approved Google marketplace).

What I wrote above is old news. What I wanted to bring to your attention is that there is a new malware called MilkyDoor. An earlier version with similar capabilities was called DressCode. In essence, the malware turns the infected device into a gateway into any network the device is connected to. Organizations should take the threat very seriously and provide their workers with devices that get updated promptly. Also access to the market place should be possible to be limited by IT teams.

Here is the Trend Micro article about the MilkyDoor threat: http://blog.trendmicro.com/trendlabs-security-intelligence/dresscode-android-malware-finds-successor-milkydoor/

March 12, 2017

Some thoughts on vulnerability management

In this blog post I will briefly discuss about vulnerability management, what it is from a high-level perspective and what it generally requires from an organization. The processes probably varies a lot between organizations based on the size and the industry the organization operates in, but certain key elements are most probably present.

Vulnerability management is about knowing what vulnerabilities (and exploits) affect your organization and how to effectively fix or mitigate the vulnerabilities, and in some certain cases take note of the vulnerabilities and accept them as residual risk.

This requires knowledge of what is in the organization. How many devices, what operating system these are running and what software makes them tick. Effectively this means there needs to be an inventory of assets to begin with. In addition there should be some level of prioritizing done to the assets based on the role of the asset and the role of the used software. A good start would in my opinion be identifying the so-called key softwares both on desktop and server level, not forgetting about devices like printers and network devices.

With key software I mean the operating system and software tools that are daily used by the organization employees to do their work and the server software which are used to produce services, for example a web application. Any software components could be important in specific situations, but trying to embrace everything can be cumbersome and in certain cases affect the work in a negative way.

After the organization has identified at adequate level what essential components should be under the vulnerability management, they need to decide how to approach identifying vulnerabilities in these components.

In my opinion there are two possible approaches, one is credentialed vulnerability scanning of the assets and the other is monitoring different sources for information. Taking the best of both worlds is probably what I would personally do, as they complement each other.

Vulnerability scanning can identify vulnerabilities at certain point of time and it's usefulness is somewhat dependent on how often the scanning is done against the assets. For example if there is a monthly vulnerability scan, it can in theory be possible that a vulnerability is unknown for the organization for a month, until the next scan executed. This doesn't make scanning obsolete, as it can identify that a already known vulnerability hasn't been fixed or identify configuration issues that make the scanned system vulnerable to attack.

Monitoring different sources for vulnerability information, like vendor advisories, mailing lists and different vulnerability/exploit sites (or using a external service provider) gives the organization a more timely view into vulnerabilities affecting the assets. The problem here however is resourcing. Who should monitor them and is there adequate time to do the monitoring and evaluate the risk of the vulnerabilities to the organization?

It might not be very efficient to escalate a low-level local vulnerability with all alarm bells ringing whereas mis-identifying or not having time to identify a remote denial-of-service vulnerability in a externally-facing asset can have consequences to the organization if this vulnerability is attacked constantly and nobody knows why the provided services do not work.

In addition to knowing the vulnerabilities, there has to be a defined process on how the vulnerabilities should be fixed or mitigated in the organization, for example does a vulnerability require immediate reaction or can it be dealt with during normal patch cycle. Without having the proper resources to fix the discovered vulnerabilities in a prioritized manner, the organization may stay vulnerable and exploitable for unnecessarily long periods of time. This can, of course, be to some extent mitigated with IPS technologies, but it is no silver bullet.

For having a working vulnerability management requires that an organization can identify the key assets and key software, it needs to have adequate resources, expertise and means to monitor and fix their assets, and there is an established process on how vulnerabilities in the organization are generally dealt with.

It is also important to realize that even if there is a mature vulnerability management in place, attackers can still compromize an organization if they manage to gain foothold to an asset. That is where detection and response capabilities come into play.

November 16, 2016

Interesting Internet packet routes

A while ago I read a paper called "Characterizing and Avoiding Routing Detours Through Surveillance States" and thought what tools there are which help one look what countries a packet goes through before reaching the destination. 

I didn't find any but thought it must not be too difficult to create. So for this purpose I created a simple bash wrapper around Traceroute, which first performs the traceroute, then does a ASN query to Cymru's whois-server and finally looks up the country from Maxmind's GeoIP data, mashing the results together. It works and has support also for TCP Traceroute. Below is an image (with the three first hops fabricated):

I decided that I should do some testing with the tool and Google'd around for governmental or random sites for different countries (with the country's TLD if possible). Below are the results of the testing from Finland, I have bolded some of the hops that feel interesting (e.g. Five Eyes country or just strange). 

It would be nice to actually know the shortest paths available, as some do not make that much sense, and most of these are somehow related to US/GB. DDoS protection services might for example affect the paths.

Country Domain Route
Russia www.yandex.ru FI - US - GB - RU
Russia government.ru FI - SE - RU
Russia www.mid.ru FI - SE - RU
USA www.usa.gov FI - SE - NL (akamai)
USA www.state.gov FI - SE - NL (akamai)
USA www.ci.denver.co.us FI - GB - US
Brazil www.brasil.gov.br FI - ES - US - BR
Canada www.canada.ca FI - SE - NL (akamai)
Columbia www.presidencia.gov.co FI - US
Mexico en.presidencia.gob.mx FI - DE - US (dosarrest?)
Mexico www.mundara.mx FI - ES - US
Cuba www.cubagob.cu FI - ES - US
United Kingdom www.gov.uk FI - GB - US
Ireland www.gov.ie FI - ES - DE - IE
Norway www.regjeringen.no FI - SE - NO
Belgium www.belgium.be FI - ES - US - BE
Belgium regionbruxelloise.be FI - ES - US - BE
Luxembourg www.gouvernement.lu FI - ES - DE - RU (amazon)
Luxembourg www.luxembourg.public.lu FI - GB - US - LU
Denmark um.dk FI - SE - DK
Netherlands www.government.nl FI - SE - NL
France www.gouvernement.fr FI - ES - US - UA
France www.tour-eiffel.fr FI - ES - US - FR
Italy www.governo.it FI - ES - US - MD - IT - NO - IT - SA
Italy www.aidaf-ey.unibocconi.it FI - ES - US - GB - IT
Romania gov.ro FI - ES - DE - RO
Germany www.bundesregierung.de FI - GB - US
Greece www.primeminister.gov.gr FI - ES - GB - GR
Greece www.mfa.gr FI - ES - GB - GR
Poland www.msz.gov.pl FI - ES - US - DE - PL
Poland www.bu.uni.wroc.pl FI - SE - PL
Spain www.exteriores.gob.es FI - SE - GB - ES - DE - ES
Spain www.juntadeandalucia.es FI - ES - US - ES
Sweden www.government.se FI(?)
Sweden www.regeringen.se FI(?)
Sweden www.statsvet.uu.se FI - SE
Estonia valitsus.ee FI - SE - UA - EE
Turkey www.mfa.gov.tr FI - GB - US - TR
Ukraine www.kmu.gov.ua FI - SE - GB - UA
Iran president.ir FI - ES - US - SE - IR
Syria www.egov.sy FI - GB - US (IP in Syria)
Syria www.mofa.gov.sy FI - DE - US - GR - US - SY
Israel www.mfa.gov.il FI - GB - US - IL
Egypt www.egypt.gov.eg FI - ES - US - FR - US(?) - EG
Iraq www.mofa.gov.iq FI - US (cloudflare)
Iraq www.cbi.iq FI - SE - DE - NO
Iraq www.ia.com.iq FI - ES - US - GB - AE
Pakistan www.pakistan.gov.pk FI - ES - US - SE(?) - US
Saudi Arabia www.saudi.gov.sa FI - GB - US (IP in SA)
Marocco www.maroc.ma FI - GB - US - MA
Marocco www.diplomatie.ma FI - GB - US - MA
Kenya www.president.go.ke FI - GB - US - ZA - KE
Libya www.pm.gov.ly FI - GB - US - LY
Nigeria www.statehouse.gov.ng FI - ES - US(?) - NG
South Africa www.gov.za FI - ES - US(?) - ZA
India india.gov.in FI - ES - US - GB - IN
Thailand www.thaigov.go.th FI - IE - TH
China www.baidu.com FI - ES - US - SG - HK
China english.gov.cn FI - GB - US
China www.ebeijing.gov.cn FI - IE - FR - US - CN
Australia www.australia.gov.au FI(?)
Australia www.gov.au FI - GB - US
Australia my.gov.au FI - ES .. (IP in AU)
Japan www.japan.go.jp FI - ES - JP
South Korea english.seoul.go.kr FI - GB - US - KR
North Korea naenara.com.kp FI - ES - US - CN .. (IP in KP)
Iceland www.government.is FI - US

October 9, 2016

Threat Landscape - opportunistic vs targeted?

I have recently been thinking about the threat landscape, what it consists of and who are the so-called "players" in the field, what kind of attack surface they provide, what are the typical attacks and what to do about it. This is a broadly generalized blog post about the topic.

These days anything that is put online or operates online can get hacked. If you have a network, IP or simply an email address, you can be a target. If you use the Internet, you can be a target. Heck, even if you don't use the Internet at all, you can be a target to close proximity attacks or through your service provider you interact physically with. Do you use a smartphone, drive a Internet-connected car or use some kind of IP-enabled device? The attack surface is getting very broad.

Most consumers and consumer devices are considered opportunistic targets, organizations and their infrastructure on the other hand are considered more being actual targets as these tend to have something valuable to steal. Opportunistic can be for example sending a lot of emails and hoping someone takes the bait, creating a malicious advert which is shown on many popular sites, and random scanning of the Internet and hoping to find assets with default credentials. whereas potential targets are more closely studied and a attack strategy created. Of course an organization, the infrastructure and it's employees are a target for opportunistic attackers also.

One might ask after reading the above: what if you're an opportunistic target and work for an organization, doesn't that make you also an actual target? In a sense yes. If you have an user account in to the organization network and use a computer/mobile, you can also be a target if you happen to fall under the attack strategy umbrella.

When looking back in time for a couple of years, it seems to me that the most common problems these days are "ransom" related attacks, either DDoS or ransomware type of activities targeting either mobile or computers, as people tend to pay up when they lose access to something which is very valuable to them, either having business or personal impact.

Also a lot of service providers are attacked and as a collateral damage also the service provider's customers are affected, typically in form of leaked personally identifiable information. It doesn't seem to matter if it is related to health, work or leisure, leaks happen and get publicized steadily which are the results of from example a popped web-application and underlying database or a lost/stolen device.

Of course there is a lot of other things going on, banking and point-of-sale device malware, enrolling assets into a botnet and so on. In addition many Internet-connected devices are built without much security consideration, putting equally organizations and consumers at risk. Some examples of these Internet-connected devices are for example surveillance cameras with default passwords or mobile phones which do not get security updates.

Some of the attacks appear more opportunistic in nature, whereas targeted attacks try to stay below the radar and focus more on IPR or collecting valuable information that can be used for monetary or other purposes. The opportunistic attackers tend to be more of the cybercrime type and targeted attackers are hacktivists and groups with own agendas.

The cybercrime is flourishing with it's own commercialized services, malware-related services, DDoS services, carding and for example selling remote access to hacked assets amongst many of the things provided. There are marketplaces and forums where stolen data and services are sold to anyone who is interested and has enough virtual currency to spend. It has been made simple to be a cybercriminal as you can buy the services you want, lowering the bar to get own operations started. But most of the operations are opportunistic in nature, like for example spam campaigns laced with ransomware.

Those cybercrime operations that are not opportunistic, involve more time and planning to get to know the organization and the 3rd parties it operates with, and can result in huge monetary damages with for example redirecting payments to attacker provided bank accounts.

The hacktivists on the other hand pick organizations that somehow are considered behaving badly, and try to find a way to shame them publicly for example via leaking information, but also potentially affect their income by disrupting operations. The groups with own agendas can be hackers-for-rent type of groups or nation-state actors, typically targeting organizations they believe have something valuable. These groups can be present in an organization network for months or even years, slowly siphoning off IPR-related or sensitive material to whoever benefits most of the data.

Many security firms study these groups, reversing their tools and try to discover their TTPs (Techniques, Tactics and Procedures). When they investigate a break-in, they can at some level identify if it is the same group or a group operating in similar fashion. It is a bit difficult to follow this area, as each security firm tend to create their own naming for a group - even if they've been studying the same group.

In essence, the attacker manages to get a foothold into the environment, create a persistence mechanism, then find ways to access valuable assets and transfer the information through specifically set up infrastructure. The initial foothold is gained by carefully studying the organization and it's employees and finding the entry point from there. The cybercrime market can even have a compromized host available into the organization's network, or leaks contain re-used access credentials into organization's remotely available assets. Based on the study, the attacker can for example compromize a website regularly visited by the employees to serve a malicious payload, but typically the attack is more simple. The attacker targets a specific employee and sends a personalized email which contains an infected document or a link to a website hosting the malicious payload. After the payload gets executed, the attacker gains access into the environment.

Nation-state actors on the other hand can have a totally different arsenal in use as has been shown in the recent years, including remote zero-day exploits in devices and software. Also potential control of networks give the capability of "silently" exploiting end users. How often does it happen and against whom is unclear, but most likely there are operations executed from time to time and most probably aimed at governmental adversaries.

When looking back at this, it seems to me that the most efficient way is to target a user directly via email and try to get the user into executing something malicious, or target them with malicious advertisements. It has also turned up in different analyzes that the malicious payload doesn't have to exploit a publicly unknown (and more expensive) vulnerability, a so-called zero-day, but even a few years old vulnerabilities do work.

In the light of this, simply put I think the most efficient way to decrease the potential of getting owned is to keep software up-to-date, not open attachments and links you do not expect and not re-using passwords on different services.

April 21, 2016

Password brute-forcing exercise

(Blog post corrected as the WPA/WPA2 times were not correct for CPU)

I had some time to experiment with password cracking related stuff, looking mainly at brute-force performance. Password cracking can be a very interesting area where using dictionaries, rainbow tables, permutations, and different optimizations can yield good results, but this time I aimed at the good old brute-forcing.

I tested two different CPUs with Hashcat and one GPU with oclHashcat tools, using a 8-character password with different character sets, and few algorithms. Other tools may provide better performance, but I haven't looked much into the area of cracking. The estimate provided by the tools was used. I have also noticed that a "typical" Finnish ISP ADSL-box has a 10-character hexadecimal WPA/WPA2 password pre-set for wireless, so I wanted to get an estimate how hard cracking that kind of password would be.

Based on the test a simple lower alpha password (MD5/SHA1) is quickly cracked in a few hours even with a slower CPU. Adding capital letters and numbers in the MD5 password increases the cracking time considerably, taking over 2 months with the slower and a bit under a month with the faster CPU.

When adding special characters into the 8-character password (hashed with MD5) increases the cracking time into years with CPU-based cracking. However, it is a different story with GPU. I was very impressed with the consumer-grade GPU performance, as it would have taken only 5-6 hours to crack the 8-character alphanumeric password. The password requiring special characters would have been done in around seven days.

Of course keeping systems running at full utilization for a prolonged period would require some serious cooling for the rig. I'm also not sure about the stability of GPU cracking, as trying to run the benchmark some video glitches was encountered and I was basically forced to boot the system.

The WPA cracking part was interesting. According to the tools itself, it would take almost 20 years to crack the password with the slower CPU and about 7 years with the faster CPU. With the GPU the time was a little over two months. This is because the computation is expensive.

Mitigating factors for online services and such is using computationally expensive algorithms and/or adding a reasonable salt to the password. This way it is possible to increase the time required for cracking the password, which makes it infeasible for under-resourced attackers. Use long and complex passphrases (over 40- chars) for your network access points and preferably also passphrases instead passwords if possible. Do not re-use them across different services.

If we think about a well-resourced attacker that has tried all the easy methods first and failing, what would it try to do? Direct network exploitation of services has failed, as has attempts to spear-phish and use watering hole attacks etc. It could attack the company with physical means, tailgating etc, but also through an employee. If the employee is cautious enough to not fall for external network-based and social-engineering attacks, how about close proximity attacks?

What I mean is that employees could be monitored and attacked: do the house they live in provide specific ISP connection, what kind of settings are the devices shipped with to the customers, which access point(s) is the strongest at the employee's apartment? Perform a quick disassociation attack and force client to re-associate with the AP and get the WPA/WPA2 handshake. Maybe they haven't bothered to change the provided password as the systems needs to be reset once in a while?

Get the cracking running based on acquired data on a 4xGPU rig, which would decrease the required time down to 16.5 days. Or maybe it is feasible to build a software-based solution that allows distributing the brute-force cracking effort between 4 different rigs each having four GPUs? That would decrease the brute-force cracking time to four days. The cost would be peanuts for a serious adversary, who probably has even better computing capacity available. Then use the key to access the employee private network, inject malicious code to gain foothold and eventually gain access to employer systems.

Who knows what kind of systems some serious nation-state adversaries in reality have? But anyways, enough with the tinfoil hat. Below are some times provided by the tools (GTX was run with the oclHashcat):

MD5, alpha (a-z) 8 characters
i3-550   @ 3.2GHz  : 31.80M words/s,  1 hours 48 min
i7-4790K @ 4.0GHz  : 97.32M words/s, 35 min
GTX980,  @ 1278Mhz : 10989M words/s, 20 sec

SHA1, alpha (a-z) 8 characters
i3-550   @ 3.2GHz  : 19.93M words/s,  2 hours 54 min
i7-4790K @ 4.0GHz  : 59.53M words/s, 58 min
GTX980,  @ 1278Mhz :  3305M words/s, 51 sec

MD5, alphanum (a-z,A-Z,0-9) 8 characters (typical app requirement)
i3-550   @ 3.2GHz  :  33.37M words/s, 77 days
i7-4790K @ 4.0GHz  : 102.74M words/s, 25 days
GTX980,  @ 1278Mhz :  10801M words/s,  5 hours, 39min

MD5, alphanum + special (a-z,A-Z,0-9, !"#¤...) 8 characters
i3-550   @ 3.2GHz  :  32.80M words/s, 6 years 4 months
i7-4790K @ 4.0GHz  : 103.32M words/s, 2 years
GTX980,  @ 1278Mhz :  10801M words/s, 7 days

WPA/WPA2, 10 character hex-password
i3-550   @  3.2GHz :  1.77k/s, 20 years
i7-4790K @  4.0GHz :  4.72k/s,  7 years
GTX980,  @ 1278MHz : 193.4k/s, 66 days

April 25, 2015

Share the Threat Intelligence?

I've read through some reports and one was Verizon's DBIR 2015. There was stated something I've seen earlier in a Defcon talk, that threat intelligence feeds have minimal overlap. The problem this poses for an organization is that it would need to ingest a lot of feeds for proper coverage and managing these would be a difficult task. It was also mentioned that the IP/domain/URL/etc indicators are short-lived, which was also kind of expected.

Here we get to the point that without proper mechanism of sharing the threat intelligence feeds we do not get anywhere. There are great research done out there by many that publish regularly very interesting stuff with detailed information ranging from IP-addresses to specific files and so on. But the problem is that this is dispersed over the Internet and typically found scattered inside a lengthy blog post. In addition there are many parties that offer paid or free feed subscriptions but as stated in the beginning, there are so many of them that should be in scope for being useful.

There are multiple of these "silos" where some parties have teamed up and share intel between each other, but that typically requires using one of their products and yet again has the problem of coverage not being that good. I yet again drum for global threat intelligence sharing and try to outline a system that might work for the benefit for all. I'd be happy if this stirs some conversation.

I believe that one centralized system which is planned and built by the security industry would be the solution. It would have specific interfaces for authenticated parties to insert different type of threat intel data into the system: files, registry keys, domains, IP-addresses, URLs, categorized properly e.g. C2, scanning hosts, affected industry and so on. The system would automatically export this data into different usable formats, e.g. iptables/web-proxy/dns/ids and so on.

This data would then be retrievable for organizations based on their preferences, organizations first make sanity checks to the data before applying it to different technologies. Sanity check like "am I in the feed data" would serve a detective purpose. Thus there would be a way to provide threat intelligence feeds with proper coverage and proper co-operation.

For all "fairness" there could be a lead time for a security company's customers where they can benefit from the data earlier by direct update, say 6-8 hours. Then it might also be fair that the centralized site offers statistics on what type of intel a security company has provided, which allow a customer some judgment on how much they do for the security industry. I don't know, this is a bit difficult area. Perhaps this kind of solution can't be free but at least it would have good coverage!

Any thoughts? Am I being insane again?

March 10, 2015

Security news, globally?

It has been a very long time since I have posted anything. I have totally forgotten about those mindmaps, but have to see if I some day manage to get my brain around them again. This time I will not promise anything! This post, on the other hand, is a brief peek into what I'm thinking currently.

Many things I read about are related to same events from a little different angle if not exactly the same post or tweet. It is kind of boring. I've also noticed that many things seem to be related to US. It is like everything happens there. It must partially be a language thing, I hope.

For example in Finland there rarely seems to happen anything, you read in Finnish mainly about the same things you've already read about in english. If something happens, it is like the world and dog hits the fan.

This situation kind of sucks. Of course a lot of different online services are US-based, these get targeted and people write about them, but something must happen also outside US. Is it that other countries do not tend to write about security and if they do there is nobody writing it in english?

I have been thinking about collecting a wordlist of different security-related keywords for different languages and using these to gather news from different regions using Google or local search engines, Twitter posts and so on.

The problem is that these would have to be translated. I think currently the best job is done by Google and only way I see this being possible is to ID-tag collected items/topics to be translated and throw one language "pack" a time at Google for translation.

Does anyone else have opinions on how to stay current with security news globally? I'm not going into the other needed functions for such news reading, like removing duplicates, but mainly aim to get more visibility.