Daily Archives: September 11, 2018

CVE-2018-16946 (lnb5110_firmware, lnb5320_firmware, lnb5320r_firmware, lnb7210_firmware, lnd3230r_firmware, lnd5110_firmware, lnd5110r_firmware, lnd5220r_firmware, lnd7210_firmware, lnd7210r_firmware, lnu3230r_firmware, lnu5110r_firmware, lnu5320r_firmware, lnu7210r_firmware, lnv5110r_firmware, lnv5320r_firmware, lnv7210_firmware, lnv7210r_firmware)

LG LNB*, LND*, LNU*, and LNV* smart network camera devices have broken access control. Attackers are able to download /updownload/t.report (aka Log & Report) files and download backup files (via download.php) without authenticating. These backup files contain user credentials and configuration information for the camera device. An attacker is able to discover the backup filename via reading the system logs or report data, or just by brute-forcing the backup filename pattern. It may be possible to authenticate to the admin account with the admin password.

CVE-2018-16947 (debian_linux, openafs)

An issue was discovered in OpenAFS before 1.6.23 and 1.8.x before 1.8.2. The backup tape controller (butc) process accepts incoming RPCs but does not require (or allow for) authentication of those RPCs. Handling those RPCs results in operations being performed with administrator credentials, including dumping/restoring volume contents and manipulating the backup database. For example, an unauthenticated attacker can replace any volume's content with arbitrary data.

CVE-2018-16949 (debian_linux, openafs)

An issue was discovered in OpenAFS before 1.6.23 and 1.8.x before 1.8.2. Several data types used as RPC input variables were implemented as unbounded array types, limited only by the inherent 32-bit length field to 4 GB. An unauthenticated attacker could send, or claim to send, large input values and consume server resources waiting for those inputs, denying service to other valid connections.

CVE-2018-16948 (debian_linux, openafs)

An issue was discovered in OpenAFS before 1.6.23 and 1.8.x before 1.8.2. Several RPC server routines did not fully initialize their output variables before returning, leaking memory contents from both the stack and the heap. Because the OpenAFS cache manager functions as an Rx server for the AFSCB service, clients are also susceptible to information leakage. For example, RXAFSCB_TellMeAboutYourself leaks kernel memory and KAM_ListEntry leaks kaserver memory.

SN 680: Exploits & Updates

This week we discuss Windows 7's additional three years of support life, MicroTik routers back in the news (and not in a good way), Google Chrome 69's new features, the hack of MEGA's cloud storage extension for Chrome, Week 3 of the Windows Task Scheduler 0-day, a new consequence of using '1234' as your password, Tesla makes their white hat hacking policies clear... just in time for a big new hack!, our PCs as the new malware battlefield, a dangerous OpenVPN feature is spotted, and Trend Micro, caught spying, gets kicked out of the MacOS store.

Hosts: Steve Gibson and Jason Howell

Download or subscribe to this show at https://twit.tv/shows/security-now.

You can submit a question to Security Now! at the GRC Feedback Page.

For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6.

Sponsors:

Risky Business #513 — The DPRK indictment, BA gets owned, Webauthn issues and more [CORRECTED]

[**PLEASE SEE BELOW FOR A CORRECTION**]

This edition of the show features Adam Boileau and Patrick Gray discussing the week’s security news:

  • The DPRK indictment and subsequent fall out
  • British Airways gets owned
  • Webauthn hits some roadblocks
  • The latest action from Washington DC
  • Trend Micro has a bad time
  • Tesla pays out for key-fob clone attack
  • Tor browser 0day hits Twitter
  • Much, much more

We’ve got a great sponsor interview for you this week – we’ll be joined by Haroon Meer of Thinkst Canary. They did something unusual over the last couple of weeks – they removed a feature in their Canary product. We’ll be talking about that, and also about the tendency for security software to be too complicated and configurable.

Links to everything that we discussed are below, including the discussions that were edited out. (That’s why there are extras.) You can follow Patrick or Adam on Twitter if that’s your thing.

CORRECTION:

The original release of this podcast included discussion of some rumours that turned out to amount to nothing. We had mentioned three data points:

  • The CISO of American Airlines, Dan Glass, departing a few weeks ago
  • Someone I know had their AA/Citi credit card re-issued, despite saying they only ever used that card to buy AA fares
  • A rumour an FBI computer crime investigator is on site at American Airlines

Well, it turns out Dan Glass is a listener, and he got in touch with us after the podcast ran to clear this up. He says the reason he left is actually because AA was offering some very attractive redundancy packages. Following AA’s merger with US Airways the combined group eventually found itself in the position of having too many executives. As many listeners will know, being a CISO is a pretty hardcore job so Dan jumped at the chance to bounce out and have some time off.

As for the FBI being on-site, Dan says that’s not unusual. They’re one of the largest airlines in the world so they’re frequently liaising with LE. As for my pal’s card getting re-issued… who knows?

The point is it looks like these rumours and data points don’t actually add up to much. This is why I rarely run rumour in the podcast and at least try to do some verification. In this case I just didn’t have time, but still, I just should have just held it over until I’d had a chance to make some basic enquiries. It was sloppy. Sorry.

In particular I’d like to apologise to the fraud teams who may have been asked to follow this up, the PR teams who’ve no doubt been fielding questions about this and also to Dan Glass. Although, it must be said Dan and I had a very nice chat and he didn’t seem upset. Thanks for being a chiller, Dan!

Again, I’m sorry. I’ll do better in the future.

Pat

Show notes

U.S. charges North Korean hacker over Sony, WannaCry incidents
US indicts North Korean agent for WannaCry, Sony attacks [Updated] | Ars Technica
Analysts expect Lazarus Group to evolve, clean up opsec
Don't Punish A North Korean Hacker Just For Following Orders
The North Korean Hacker Charges: Line-Drawing as a Necessary but not Sufficient Part of Deterrence - Lawfare
British Airways breach caused by the same group that hit Ticketmaster | ZDNet
Card-Skimming Malware Campaign Hits Dozens of Sites Daily
Worries arise about security of new WebAuthn protocol | ZDNet
A call for principle-based international agreements to govern law enforcement access to data - Microsoft on the Issues
Exclusive: Trump to target foreign meddling in U.S. elections with sanctions order - sources | Reuters
House passes deterrence bill that would call out nation-state hackers
First IoT security bill reaches governor's desk in California | ZDNet
DHS supply chain and CDM bills pass the House
Former Facebook security chief Alex Stamos: Being a CSO can be a ‘crappy job’ | TechCrunch
Alex Stamos: Pretty clear GRU's goal was to weaken a future Clinton presidency | ZDNet
'We simply haven't done enough': Facebook and Twitter execs testify on foreign influence campaigns
Trend Micro blames data collection issue on code library re-use
Apple Removes Top Security App For Stealing Data and Sending it to China
Tesla offers 'goodwill' to security researchers hacking its cars
Hackers Can Steal a Tesla Model S in Seconds by Cloning Its Key Fob | WIRED
U.S. extradites Russian accused in hack of JPMorgan Chase
Standard to protect against BGP hijack attacks gets first official draft | ZDNet
Exploit Affecting Tor Browser Burned In A Tweet
Exploit vendor drops Tor Browser zero-day on Twitter | ZDNet
Tor launches official anonymous Android browser
US government releases post-mortem report on Equifax hack | ZDNet
GAO-18-559, DATA PROTECTION: Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach
Thinkst Canary on Twitter: "This week we totally announced an un-feature. We are removing SNMP as an available service on Canaries. (Turns out its signal to noise ratio is terribad, and everyone we’ve ever caught through SNMP also tripped over other services too)… https://t.co/kiNx6GZPtj"

Hack Naked News #188 – September 11, 2018

This week, stealing your Tesla, British Airways hack, Equifax long list of mistakes, Windows 7 support, oops I forgot to encrypt your chats, I can see your browser history, Tor browsers, VPNs and Coldfusion? Jason Wood from Paladin Security joins us for expert commentary, so stay tuned for this episode of Hack Naked News!

 

Full Show Notes: https://wiki.securityweekly.com/HNNEpisode188

 

Visit https://www.securityweekly.com/hnn for all the latest episodes!

Visit https://www.activecountermeasures/hnn to sign up for a demo or buy our AI Hunter!!

 

→Visit our website: https://www.securityweekly.com

→Follow us on Twitter: https://www.twitter.com/securityweekly

→Like us on Facebook: https://www.facebook.com/secweekly

British Airways Hack Update: Caused by Injected Script & PCI DSS Non-Compliance is Suspected

On Friday (7th September 2018), British Airways disclosed between 21st August 2018 and 5th September 2018, 380,000 BA customer's payment card transactions were compromised by a third party through its website and mobile app. This data included the customer's full name, email address, debit\credit card 16 digit number (PAN), expiry date and card security code i.e. CVV, CV2

Details of how the hack was orchestrated have now come to light. In a blog post RiskIQ researchers have claimed to have found evidence that a web-based card skimmer script was injected into the BA website, very similar to the approach used by the Magecard group, who are believed to be behind a similar attack against the Ticketmaster website recently. Web-based card skimmer script attacks have been occurring since 2015.

In this case, once the customer has entered their payment card details and then submits the payment either on a PC or on a touchscreen device, the malicious script executes and captures their payment card data, sending it to a virtual (VPS) server hosted in Romania. The server was hosted on a domain called baways.com and was certified (https) by Comodo to make it appear legit within the website html (code). The server domain was registered 6 days before the breach started, this obviously went undetected by BA's security, perhaps the domain registration could have been picked up by a threat intelligence service.

Other Researchers have also claimed the BA website wasn't PCI DSS compliant. Marcus Greenwood found files loaded from 7 external domains onto the BA website, and crucially said the BA payment page wasn't isolating the card payment entry within an iframe, which would prevent any third-party scripts (and XSS attacks) from being able to read the payment card form fields. The Payment Card Industry Data Security Standard (PCI DSS) is required by all organisations which accept, process, store and/or transmit debit and credit cards.

Here is the advice from CEO of global cybersecurity specialist SonicWall, Bill Conner:

"Organizations and government entities carry a responsibility to consumers and civilians alike to guard their most valuable information at all cost. While the British Airways breach may not have been as detrimental as I’m sure its culprits would have liked it to be, it should serve as a wake-up call to CTOs, CIOs and CISOs. The fact is, it is early days, and the true damage done is yet to be seen. Personal information that does not change as easily as a credit card or bank account number drive a high price on the Dark Web. This kind of Personally Identifiable Information is highly sought after by cybercriminals for monetary gain. Companies should be implementing security best practices such as a layered approach to protection, as well as proactively updating any out of date security devices, as a matter of course."

My view mass credit\debit card data (cardholder data) complete with the security code has always been targeted by cyber crooks as it is very easily sellable on the dark web, as the data only can be used in cardholder-not-present transaction fraud, where credit card holder is not physically present i.e. online, app, phone. The finger can be pointed at lack of PCI DSS compliance by merchants like BA, however, I think it is about time technology was used to improve the security of all cardholder-not-not present transactions, namely Multi-factor authentication (MFA).  While MFA on all cardholder-not-present is not a silver bullet, there is no 100% security, enforced usage across all industries would certainly devalue debit\credit card data considerably.

CVE-2016-0715 (cloud_foundry_elastic_runtime)

Pivotal Cloud Foundry Elastic Runtime version 1.4.0 through 1.4.5, 1.5.0 through 1.5.11 and 1.6.0 through 1.6.11 is vulnerable to a remote information disclosure. It was found that original mitigation configuration instructions provided as part of CVE-2016-0708 were incomplete and could leave PHP Buildpack, Staticfile Buildpack and potentially other custom Buildpack applications vulnerable to remote information disclosure. Affected applications use automated buildpack detection, serve files directly from the root of the application and have a buildpack that matched after the Java Buildpack in the system buildpack priority when Java Buildpack versions 2.0 through 3.4 were present.

Twenty Years of Network Security Monitoring: From the AFCERT to Corelight

I am really fired up to join Corelight. I’ve had to keep my involvement with the team a secret since officially starting on July 20th. Why was I so excited about this company? Let me step backwards to help explain my present situation, and forecast the future.

Twenty years ago this month I joined the Air Force Computer Emergency Response Team (AFCERT) at then-Kelly Air Force Base, located in hot but lovely San Antonio, Texas. I was a brand new captain who thought he knew about computers and hacking based on experiences from my teenage years and more recent information operations and traditional intelligence work within the Air Intelligence Agency. I was desperate to join any part of the then-five-year-old Information Warfare Center (AFIWC) because I sensed it was the most exciting unit on “Security Hill.”

I had misjudged my presumed level of “hacking” knowledge, but I was not mistaken about the exciting life of an AFCERT intrusion detector! I quickly learned the tenets of network security monitoring, enabled by the custom software watching and logging network traffic at every Air Force base. I soon heard there were three organizations that intruders knew to be wary of in the late 1990s: the Fort, i.e. the National Security Agency; the Air Force, thanks to our Automated Security Incident Measurement (ASIM) operation; and the University of California, Berkeley, because of a professor named Vern Paxson and his Bro network security monitoring software.

When I wrote my first book in 2003-2004, The Tao of Network Security Monitoring, I enlisted the help of Christopher Jay Manders to write about Bro 0.8. Bro had the reputation of being very powerful but difficult to stand up. In 2007 I decided to try installing Bro myself, thanks to the introduction of the “brolite” scripts shipped with Bro 1.2.1. That made Bro easier to use, but I didn’t do much analysis with it until I attended the 2009 Bro hands-on workshop. There I met Vern, Robin Sommer, Seth Hall, Christian Kreibich, and other Bro users and developers. I was lost most of the class, saved only by my knowledge of standard Unix command line tools like sed, awk, and grep! I was able to integrate Bro traffic analysis and logs into my TCP/IP Weapons School 2.0 class, and subsequent versions, which I taught mainly to Black Hat students. By the time I wrote my last book, The Practice of Network Security Monitoring, in 2013, I was heavily relying on Bro logs to demonstrate many sorts of network activity, thanks to the high-fidelity nature of Bro data.

In July of this year, Seth Hall emailed to ask if I might be interested in keynoting the upcoming Bro users conference in Washington, D.C., on October 10-12. I was in a bad mood due to being unhappy with the job I had at that time, and I told him I was useless as a keynote speaker. I followed up with another message shortly after, explained my depressed mindset, and asked how he liked working at Corelight. That led to interviews with the Corelight team and a job offer. The opportunity to work with people who really understood the need for network security monitoring, and were writing the world’s most powerful software to generate NSM data, was so appealing! Now that I’m on the team, I can share how I view Corelight’s contribution to the security challenges we face.

For me, Corelight solves the problems I encountered all those years ago when I first looked at Bro. The Corelight embodiment of Bro is ready to go when you deploy it. It’s developed and maintained by the people who write the code. Furthermore, Bro is front and center, not buried behind someone else’s logo. Why buy this amazing capability from another company when you can work with those who actually conceptualize, develop, and publish the code?

It’s also not just Bro, but it’s Bro at ridiculous speeds, ingesting and making sense of complex network traffic. We regularly encounter open source Bro users who spend weeks or months struggling to get their open source deployments to run at the speeds they need, typically in the tens or hundreds of Gbps. Corelight’s offering is optimized at the hardware level to deliver the highest performance, and our team works with customers who want to push Bro to the even greater levels. 

Finally, working at Corelight gives me the chance to take NSM in many exciting new directions. For years we NSM practitioners have worried about challenges to network-centric approaches, such as encryption, cloud environments, and alert fatigue. At Corelight we are working on answers for all of these, beyond the usual approaches — SSL termination, cloud gateways, and SIEM/SOAR solutions. We will have more to say about this in the future, I’m happy to say!

What challenges do you hope Corelight can solve? Leave a comment or let me know via Twitter to @corelight_inc or @taosecurity.

IDG Contributor Network: Start preparing today for the future of quantum computing

As an IT security professional, you have a number of issues that demand your attention today. Protecting against data breaches, securing IT infrastructures that are growing more complex and distributed, the steady stream of new devices attaching to your networks thanks to the rise of the Internet of Things, artificial intelligence, etc. So, the as-yet-unknown arrival of quantum computing is probably not on your radar. But it should be.

There are two main factors that will influence how you proceed. First, ask yourself what your lead time will be for changing and updating your systems. The more compliance and regulatory obligations you have, the harder that gets and the longer it takes. For example, if you’re with an international bank with complex PKI and cryptography on a large scale, well, get started now.

To read this article in full, please click here

CVE-2018-2463 (hybris)

The Omni Commerce Connect API (OCC) of SAP Hybris Commerce, versions 6.*, is vulnerable to server-side request forgery (SSRF) attacks. This is due to a misconfiguration of XML parser that is used in the server-side implementation of OCC.

CVE-2018-1127 (gluster_storage)

Tendrl API in Red Hat Gluster Storage before 3.4.0 does not immediately remove session tokens after a user logs out. Session tokens remain active for a few minutes allowing attackers to replay tokens acquired via sniffing/MITM attacks and authenticate as the target user.

What is a botnet? And why they aren’t going away anytime soon

Botnets act as a force multiplier for individual attackers, cyber-criminal groups and nation-states looking to disrupt or break into their targets’ systems. By definition, they are a collection of any type of internet-connected device that an attacker has compromised. Commonly used in distributed denial of service (DDoS) attacks, botnets can also take advantage of their collective computing power to send large volumes of spam, steal credentials at scale, or spy on people and organizations.

CVE-2016-7073 (authoritative, debian_linux, recursor)

An issue has been found in PowerDNS before 3.4.11 and 4.0.2, and PowerDNS recursor before 4.0.4, allowing an attacker in position of man-in-the-middle to alter the content of an AXFR because of insufficient validation of TSIG signatures. A missing check of the TSIG time and fudge values was found in AXFRRetriever, leading to a possible replay attack.

CVE-2016-7074 (authoritative, debian_linux, recursor)

An issue has been found in PowerDNS before 3.4.11 and 4.0.2, and PowerDNS recursor before 4.0.4, allowing an attacker in position of man-in-the-middle to alter the content of an AXFR because of insufficient validation of TSIG signatures. A missing check that the TSIG record is the last one, leading to the possibility of parsing records that are not covered by the TSIG signature.

CVE-2016-7068 (authoritative, debian_linux, recursor)

An issue has been found in PowerDNS before 3.4.11 and 4.0.2, and PowerDNS recursor before 3.7.4 and 4.0.4, allowing a remote, unauthenticated attacker to cause an abnormal CPU usage load on the PowerDNS server by sending crafted DNS queries, which might result in a partial denial of service if the system becomes overloaded. This issue is based on the fact that the PowerDNS server parses all records present in a query regardless of whether they are needed or even legitimate. A specially crafted query containing a large number of records can be used to take advantage of that behaviour.

CVE-2016-0750 (infinispan)

The hotrod java client in infinispan before 9.1.0.Final automatically deserializes bytearray message contents in certain events. A malicious user could exploit this flaw by injecting a specially-crafted serialized object to attain remote code execution or conduct other attacks.

IRS Call Scammers Sentenced in Texas

Back in 2016 we blogged about a major set of arrests in India and the United States related to a call center scam imitating the IRS.  (See "Major Call Center Scam Revealed - 56 Indicted")

This post is to just share an update on that case.  There have been so many arrests made and yet the fraud continues every day!  I received two IRS calls myself in the past week!

To begin, the IRS is NEVER going to call you and threaten arrest.  If you receive such a call, the investigative agency for IRS scams is TIGTA, the Treasury Inspector General for Tax Administration. You can call their scam hotline to report at 1.800.366.4484, or share details online at the IRS Impersonation Scam Reporting form.  All of the arrests below started because someone reported their scammers.  Although the form seems to be focused on people who actually lost money, even non-loss reports can be helpful.

The biggest round of arrests came in October 27, 2016, which was the focus of that "Major Call Center Scam" blog post.  The DOJ press release was titled "Dozens of Individuals Indicted in Multimillion-Dollar Indian Call Center Scam Targeting U.S. Victims
Over the next several months, many of the criminals pled guilty.  All but two were from India, although several were now American citizens.  Each has now been sentenced for their crimes in a mass sentencing before Judge Hittner in Houston, Texas.  Below, we show their guilty plea date, where they were living and/or conducting their crime, and what the DOJ/TIGTA press release said about their guilty plea.  We feel that the sentences were fair, ranging from just over four years to 188 months (15 1/2 years).  

Just wanted to share that EVENTUALLY, Justice is served.

However, PLEASE KEEP REPORTING!  There certainly are more IRS-imitating criminals who need to go to prison!

Bharatkumar Patel (April 13, 2017) - a resident of Midlothian, Illinois - sentenced to 50 months in prison and removal to India. 


According to his plea, beginning in or about July 2013, Patel worked as a member of a crew of runners operating in the Chicago area and elsewhere throughout the country. Patel admitted to purchasing reloadable cards or retrieving wire transfers and using the misappropriated personal identifying information of U.S. citizens. Patel also admitted to opening personal bank accounts in order to receive scam proceeds and payments from defrauded victims as well as creating limited liability companies in his name to further the conspiracy. According to his plea, Patel opened one bank account that received more than $1.5 million in deposits over a one-year period and another bank account that received more than $450,000 in deposits over a five-month period.

Ashvinbhai Chaudhari (April 26, 2017) - a resident of Austin, Texas. - sentenced to 87 months in prison.


According to his plea, since in or about April 2014, Chaudhari worked as a member of a crew of runners operating in Illinois, Georgia, Nevada, Texas and elsewhere throughout the country. At the direction of both U.S. and India-based co-conspirators, often via electronic WhatsApp text communications, Chaudhari admitted to driving around the country with other runners to purchase reloadable cards registered with misappropriated personal identifying information of U.S. citizens. Once victim scam proceeds were loaded onto those cards, Chaudhari admitted that he liquidated the proceeds on the cards and transferred the funds into money orders for deposit into various bank accounts while keeping a percentage of the victim funds for himself. Chaudhari also admitted to shipping money orders purchased with victim funds to other U.S. based co-conspirators, receiving fake identification documents from an India-based co-conspirator and using those documents to receive victim scam payments via wire transfers.


Harsh Patel (May 11, 2017) - a resident of Piscataway, New Jersey. - sentenced to 82 months in prison and deportation after his sentence.


According to his plea, since around January 2015, Patel worked as a runner operating primarily in New Jersey, California and Illinois. At the direction of India-based co-conspirators, often via electronic WhatsApp text communications, Patel admitted to purchasing reloadable cards registered with misappropriated personal identifying information of U.S. citizens. Once victim scam proceeds were loaded onto those cards, Patel admitted that he liquidated the proceeds on the cards and transferred the funds into money orders for deposit into various bank accounts while keeping a percentage of the victim funds for himself. Patel also admitted to receiving fake identification documents from an India-based co-conspirator and other sources and using those documents to receive victim scam payments via wire transfers.


Nilam Parikh (May 18, 2017) - a resident of Pelham, Alabama - sentenced to 48 months in prison 


Since around December 2013, Parikh worked as a runner operating in Alabama.  In connection with her plea, Parikh admitted that, at the direction of an India-based co-conspirator, often via electronic WhatsApp text communications, Parikh purchased reloadable cards registered with misappropriated personal identifying information of U.S. citizens.  Once victim scam proceeds were loaded onto those cards, Parikh admitted that she liquidated the proceeds on the cards and transferred the funds into money orders for deposit into various bank accounts, while keeping part of the victim funds for herself as payment.  Parikh also admitted to sending and receiving scam proceeds to and from her co-conspirators via Federal Express.


Information on the next five all came from the same DOJ Press Release: "Five More Defendants Please Guilty for their Roles in Multimillion Dollar India-Based Call Center Scam Targeting U.S. Victims


Dilipkumar A. Patel (May 26, 2017) - a resident of Corona, California - sentenced to 108 months in prison and removal to India. 


Based on the admissions made in his May 26 guilty plea, since late 2013, Dilipkumar A. Patel operated as a runner in and around Southern California, along with other co-defendants based in the region. At the direction of India-based co-conspirators, often via electronic WhatsApp communications, Patel admitted to participating in the purchase of reloadable cards registered with the PII of U.S. citizens, and the subsequent liquidation of victim scam funds loaded to those cards by co-conspirators, while keeping a percentage of the victim funds on the cards for himself. 


Fahad Ali (May 26, 2017) - a resident of Dyer, Indiana (from Pakistan) - sentenced to 108 months in prison 


According to his guilty plea, also on May 26, beginning in or around 2013, Fahad Ali worked as a member of a crew of runners operating in the Chicago, Illinois area, the Southern District of Texas and elsewhere throughout the country. Ali admitted that he first served as a driver for an Illinois-based co-defendant engaging in activities in furtherance of the conspiracy. Ali later operated at the direction of that co-defendant and others, via various means of communication, including text messages, to purchase reloadable cards, and then liquidate victim scam proceeds placed on those cards by India-based co-conspirators, in exchange for recurring payments. Ali also admitted to using false identification documents to receive wire transfers from victims of the fraud.


Hardik Patel (June 2, 2017) - a resident of Arlington Heights, Illinois - sentenced to 188 months in prison and removal to India upon completion of the sentence.

Based on the statements in his June 2 guilty plea, beginning in August 2012, Hardik Patel owned and managed the day-to-day operations of an India-based scam call center before later leaving for the U.S. While in India, in his capacity as a manager, Hardik Patel communicated extensively via email, text, and other means with various India-based co-defendants to operate the scheme and exchange scripts used in the scheme, coordinate the processing of payments from scammed victims, obtain and exchange lead lists used by callers to target U.S. victims, and exchange spreadsheets containing the personal identifying information (PII) of U.S. persons misappropriated by the scammers to register reloadable cards used in the scheme. Hardik Patel also managed worker payroll and kept detailed records of profits and expenses for various associated scam call centers. Hardik Patel continued to communicate with India-based co-defendants about the scheme and assist with the conspiracy after he moved to the U.S. 



Rajubhai Patel (June 2, 2017) - a resident of Willowbrook, Illinois - sentenced to 151 months in prison 


According to his June 6 guilty plea, Rajubhai Patel operated as a runner and assisted a co-defendant in managing the activities of a crew of other runners, based primarily out of Illinois, who liquidated victim funds in various locales in the U.S. for conspirators from India-based call centers. Rajubhai Patel communicated about the liquidation of scam funds via electronic WhatsApp communications with domestic and India-based co-defendants, purchased reloadable cards registered using the misappropriated PII of U.S. citizens that were later used to receive victims’ funds, and used those cards to purchase money orders and deposit them into various bank accounts of co-defendants and others as directed. Rajubhai Patel also admitted to creating and maintaining spreadsheets that detailed deposits, payments to co-conspirators, expenses and profits from the scheme.


Viraj Patel (June 2, 2017) - a resident of Anaheim, California - sentenced to 165 months in prison and removal to India.


According to admissions made in his June 2 guilty plea, Viraj Patel first became involved in the conspiracy between April and September 2013, prior to entering the U.S., when he worked at and assisted with overseeing the operations of a call center in India engaging in scam activity at the behest of a co-defendant. After entering the U.S., beginning in December 2014 Viraj Patel engaged in additional activities in support of the scheme in exchange for a cut of the profits, including serving as a processor of scam victim payments and as a runner engaging in the purchase and liquidation of cards loaded with victim scam funds. Viraj Patel communicated with various India-and U.S.-based co-defendants in furtherance of the conspiracy, and also obtained and circulated lead lists to his co-conspirators containing the PII of U.S. citizens for use by the call centers in targeting victims of the various fraud schemes and to register reloadable cards used to launder the proceeds of the schemes.  


Bhavesh Patel (July 7, 2017) - a resident of Gilbert, Arizona and Alabama - sentenced to 121 months in prison.


According to Bhavesh Patel’s guilty plea, beginning in or around January 2014, Bhavesh Patel managed the activities of a crew of runners, directing them to liquidate victim scam funds in areas in and around south and central Arizona per the instructions of conspirators from India-based call centers. Patel communicated via telephone about the liquidation of scam funds with both domestic and India-based co-defendants, and he and his crew used reloadable cards containing funds derived from victims by scam callers to purchase money orders and deposit them into various bank accounts as directed, in return for percentage-based commissions from his India-based co-defendants. Patel also admitted to receiving and using fake identification documents, including phony driver’s licenses, to retrieve victim scam payments in the form of wire transfers, and providing those fake documents to persons he managed for the same purpose.


Asmitaben Patel (July 7, 2017) - a resident of Willowbrook, Illinois - (previously sentenced to 24 months) 


Based on admissions in Asmitaben Patel’s guilty plea, beginning in or around July 2013, Asmitaben Patel served as a runner liquidating victim scam funds as part of a group of conspirators operating in and around the Chicago area. At the direction of a co-defendant, Patel used stored value cards that had been loaded with victim funds to buy money orders and deposit them into various bank accounts, including the account of a lead generating business in order to pay the company for leads it provided to co-conspirators that were ultimately used to facilitate the scam.


The next seven criminals guilty pleas were announced by the Department of Justice on November 13, 2017 in their press release:  "Last Defendant in the United States Pleads Guilty in Multimillion Dollar India-Based Call Center Scam Targeting U.S. Victims"


Miteshkumar Patel (November 13, 2017) - a resident of Willowbrook, Illinois - sentenced to 240 months.


Based on admissions in Miteshkumar Patel’s plea, beginning in or around 2013, Miteshkumar Patel managed a crew of a half dozen domestic runners involved in the criminal scheme, liquidating as much as approximately $25 million in victim funds for conspirators from India-based call center and organizational co-defendant HGLOBAL.  Patel communicated about the fraudulent scheme with various domestic and India-based co-defendants via email, text messaging and WhatsApp messaging.  Miteshkumar Patel and his runners purchased reloadable GPR cards that were registered using the misappropriated personal identifying information (PII) of unsuspecting victims that were later used to receive victims’ funds, and used those reloadable cards containing victims’ funds to purchase money orders and then deposit those money orders into bank accounts, as directed, while keeping a portion of the scam proceeds as profit.  Miteshkumar Patel also trained the runners he managed on how to conduct the liquidation scheme, provided them with vehicles to conduct their activities in Illinois and throughout the country, and directed a co-defendant to open bank accounts and limited liability companies for use in the conspiracy.  Miteshkumar Patel further admitted to using a gas station he owned in Racine, Wisconsin to liquidate victim funds, and possessing and using equipment at his Illinois apartment to make fraudulent identification documents used by co-defendant runners in his crew to receive wire transfers directly from scam victims and make bank deposits in furtherance of the conspiracy.


Raman Patel (age 82) (November 13, 2017) - a resident of Gilbert, Arizona - (previously sentenced in Phoenix, Arizona to probation, in consideration of his age and his cooperation.)

According to admissions in Raman Patel’s guilty plea, from in or around 2014, Patel served as a domestic runner in and around south-central Arizona, liquidating victim scam funds per the instructions of a co-defendant.  Patel also served as a driver for two co-defendants in furtherance of their GPR liquidation and related activities and sent bank deposit receipts related to the processing of victim payments and fraud proceeds to an India-based co-defendant via email and document scan services offered at various retail stores.

Sunny Joshi of Sugar Land, Texas - sentenced to 151 months in prison for money laundering conspiracy, and 120 months in prison for naturalization fraud.

Rajesh Bhatt of Sugar Land, Texas - sentenced to 145 months in prison and removal to India.


Based on admissions in Joshi and Bhatt’s guilty pleas, beginning in or around 2012, Joshi and Bhatt worked together as runners in the Houston, Texas area along with a co-defendant.  They admitted to extensively communicating via email and text with, and operating at the direction of, India-based conspirators from organizational co-defendant CALL MANTRA call center to liquidate up to approximately $9.5 million in victim funds, including by purchasing GPR cards and using those cards, funded by co-conspirators with scam victim funds, to purchase money orders and deposit them in third party bank accounts, while keeping a percentage of the scam proceeds for themselves as profit.  Joshi has also agreed to plead guilty to one count of naturalization fraud pursuant to a federal indictment obtained against him in the Eastern District of Louisiana, based on fraudulently obtaining his U.S. citizenship.


Jagdishkumar Chaudhari of Montgomery, Alabama - sentenced to 108 months in prison and removal to India.


Jagdishkumar Chaudhari admitted in his plea that between April 2014 and June 2015, he worked as a member of a crew of runners operating in the Chicago area and elsewhere throughout the country, at the direction of Miteshkumar Patel and others.  In exchange for monthly cash payments, Jagdishkumar Chaudhari admitted to driving to hundreds of retail stores to purchase GPR cards to be loaded with victim funds by co-conspirators in India, purchasing money orders with GPR cards that had been funded with victim proceeds, depositing money orders purchased using victim scam proceeds at various banks, and retrieving wire transfers sent by victims of the scheme.  Jagdishkumar Chaudhari is an Indian national with no legal status in the United States, and has agreed to deportation after he serves his sentence as a condition of his guilty plea.


Praful Patel of Fort Myers, Florida - sentenced to 60 months in prison 


In his plea, Praful Patel admitted that between in or around June 2013 and December 2015, he was a domestic runner who liquidated funds in and around Fort Myers, Florida for conspirators from India-based call center and organizational co-defendant HGLOBAL.  Praful Patel communicated extensively via WhatsApp texts with his conspirators.  For a percentage commission on transactions he conducted, Praful Patel admitted to purchasing reloadable GPR cards that were registered using the misappropriated PII of unsuspecting victims that were later used to receive victims’ funds, using those reloadable GPR cards containing victims’ funds to purchase money orders and depositing those money orders into bank accounts as directed, and using fake identity documents to receive wire transfers from victims.


Jerry Norris of Oakland, California - sentenced to 60 months in prison 


According to Norris’ guilty plea, beginning in or around January 2013 continuing through December 2014, he was a runner who worked with conspirators associated with India-based call center and organizational co-defendant HGLOBAL, and was responsible for the liquidation of victim scam funds in and around California.  Norris admitted he communicated extensively via WhatsApp and email with India-based co-defendants including Sagar “Shaggy” Thakar, purchased GPR cards used in the scheme, sent lead lists to conspirators in India that were then used by callers located in the call centers to target potential victims in the telefraud scheme, received scam proceeds via wire transfers using fictitious names, and laundered scam proceeds from GPR cards via ATM withdrawals.


Others sentenced whose guilty pleas were not mentioned above include: 


Montu Barot - 60 months in prison and removal to India after sentence

Rajesh Kumar - 60 months in prison 


Nilesh Pandya - sentenced to three years probation 


Dilipkumar R. Patel of Florida - sentenced to 52 months in prison 


Nisarg Patel of New Jersey - sentenced to 48 months in prison and removal to India.


Dipakkumar Patel, of Illinois, was sentenced to 51 months by Judge Eleanor Ross in Atlanta, Georgia.



The 3 Most Powerful Types of Threat Information Sharing – and How to Stay Compliant

By: Paul Kraus, CEO, Eastwind Networks

When it comes to IT security, the unknowns impose the greatest threat. Luckily, many types of threats are very much on the cybersecurity radar. Institutions and organizations who pay attention and take advantage of available threat information sharing are more likely to succeed in keeping their networks secure from hackers and attacks. Unfortunately, threat sharing isn’t a prevalent common practice and much available information isn’t the most complete or accurate. To discover potential threats, IT security teams need to dig deeper.

Threat information sharing – the sharing of threat intelligence – is an increasingly important method to thwarting hacker’s attack plans. But for many, compliance issues can seem like roadblocks to effective collaboration both pre- and post-intrusion. Openly communicating with others in information-sensitive industries presents legal obstacles, but navigating this landscape is increasingly worth the effort as the complex threat environment escalates.

The Power of Shared Information

Getting hacked can feel like failure and sharing that information is a vulnerability not high on anyone’s to-do list. But as the black hats are increasingly out there sharing information about hacks, vulnerabilities and zero-day threats, it only makes sense that the people on the other side of the equation need to share as well. Unfortunately, mountains of paperwork and notifying customers of a breach turns most financial institutions off from being open about any information security events. Then there are the PR troubles and lawyer fees for the potential lawsuits on top.

While the negatives of sharing information regarding a breach seems overwhelming, many industries do itself no favors by holding to the old habit of silence. After network security and breach detection is in place, the best way to counter hackers is learn from each other’s experience. In the world of IT security, shared beats scared every time. Here are three ways to engage with threat information sharing that will pay off for security and compliance.

Closed Communities

Many chatrooms and other discussion boards can provide advice and feedback for security issues, but for those who have been breached a deeper layer of support is now available. A number of closed communities have developed for mutual support in dealing with the fallout of being hacked. Tightly controlled and monitored because of the legal repercussions of sharing such delicate information, these could be likened to 12-step support groups for hacking victims. Examples include the Financial Services Information Sharing and Analysis Center (FS-ISAC) and the National Cyber-Forensics and Training Alliance (NCFTA). Corporate counsel has the final say in what is disclosed, but these groups can offer helpful advice and strategies for moving through the disclosure and compliance process.

The Threat Information Market

Every intrusion leaves a trace. Indicators of compromise (IoC) like IP addresses linked to viruses, domain names associated with botnets and other out of the ordinary network activity are precursors to an attack. While every network should have active breach detection in place, buying threat intel helps identify network traffic that falls outside the normal range.

A lot of free information can be gleaned from the Internet, but the companies that monitor threats and compile salable intel are often a step ahead of any unpaid source. File and IP reputation services are great resources as well as an updated list of threats maintained by the FBI.

The Power of Shared Experience

Many companies are finding that sharing experiences is a powerful tool against hackers. Whether a company has been breached or not, it can be helpful engaging with others doing the same job. Reading about threats is important, but hearing someone’s first hand account of how they first noticed symptoms and then investigated only to find someone lurking in their system brings home the risks and solutions more powerfully than anything else.

Like the closed communities above, these resources can present challenges from a legal aspect, but the benefits often outweigh the risks. Many companies find it worthwhile to navigate the hassle, liability and compliance issues to successfully build community and, in the end, create smarter defenses. If hindsight is 20/20, victims of hacks need only ask themselves how much they would have given to have been warned ahead of time about the risk that turned into their reality.

The Information Age

People generally think of the information age being all about data. For those who manage public and private networks, it also needs to be about breaking down silos and sharing information through effective relationships and community. Whether through closed, subscription-based groups or a wider threat intel sharing channel, IT security personnel need more contact than a yearly conference can provide. The integrity of their network may depend on it. After the initial damage of a breach is addressed, the power to mobilize stronger cybersecurity defenses lies in the ability to share threat information.

The post The 3 Most Powerful Types of Threat Information Sharing – and How to Stay Compliant appeared first on IT SECURITY GURU.

City of Stockholm Selects MobileIron Threat Defense to Detect and Mitigate Mobile Threats

MobileIron, the secure foundation for modern work, today announced that City of Stockholm has selected MobileIron Threat Defense to detect and mitigate mobile threats. MobileIron Threat Defense will be deployed on 30,000 mobile devices used by the employees of the City of Stockholm.

MobileIron Threat Defense provides unparalleled mobile threat protection, securing mobile devices from device, network, and app threats. Organizations can protect sensitive data by detecting and remediating known and zero-day threats on mobile devices with no need for the users to take any action to activate or deploy the app.

“City of Stockholm employees rely on their mobile devices to increase their work efficiency,” said Constantinos Amiridis, solution architect, City of Stockholm. “With MobileIron Threat Defense, we can give our employees the peace of mind to safely use their devices without any data being compromised.”

“City of Stockholm has always been at the forefront of technology, deploying innovative solutions that help its many departments perform with agility and efficiency,” said Simon Biddiscombe, CEO, MobileIron. “Today, through its selection of MobileIron Threat Defense, City of Stockholm has yet again shown its commitment to working with best-in-class technology to keep its workforce secure and productive.”

The post City of Stockholm Selects MobileIron Threat Defense to Detect and Mitigate Mobile Threats appeared first on IT SECURITY GURU.

Making an Impact with Security Awareness Training: Continuous Contextual Content

Posted under: Research and Analysis

As we discussed in the first post of our Making an Impact with Security Awareness Training series, organizations need to architect training programs around a clear definition of success, both to determine the most appropriate content to deliver, and also to manage management expectations. The definition of success for any security initiative is measurable risk reduction, and that applies just as much to security awareness training.

We also covered the limitations of existing training approaches – including weak generic content, and a lack of instrumentation & integration, to determine the extent of risk reduction. To overcome these limitations we introduced the concept of Continuous, Contextual Content (3C) as the cornerstone of the kind of training program which can achieve security initiatives.

We described 3C as:

“It’s giving employees the necessary training, understanding they won’t retain everything. Not the first time anyway. Learning requires repetition, but why repeat training to someone that already gets it? That’s a waste of time. Thus to follow up and focus on retention, you want to deliver appropriate content to the employee when they need it. That means refreshing the employee about phishing, not at a random time, but after they’ve clicked on a phishing message.”

Now we can dig in to understand how to move your training program toward 3C.

Start with Users

Any focus on risk reduction requires first identifying employees who present the most risk to the organization. Don’t overcomplicate your categorization process, or you won’t be able to keep it current. We suggest 4-6 groups categorized by their access to critical information.

  1. Senior Management: These individuals have the proverbial keys to the kingdom, so they tend to be targeted by whaling and other adversary campaigns. They also tend to resist extensive training given their other responsibilities. That said, if you cannot get senior management to lead by example and receive extensive training, you have a low likelihood of success with the program overall.
  2. Finance: This team has almost the same risk profile as senior management. They access financial reporting systems and the flow of money. Stealing money is the objective of many campaigns, so these folks need a bit more love to prepare for the inevitable attacks.
  3. HR and Customer Service: Attackers target Human Resources and Customer Service frequently as well, mostly because they provide the easiest path into the organization; attackers then continue toward their ultimate goal. Interacting with the outside world makes up a significant part these groups’ job functions, so they need to be well-versed in email attacks and safe web browsing.
  4. Everyone else: We could define another dozen categories, but that would quickly pass the point of diminishing returns. The key for this group is to ensure that everyone has a baseline understanding of security, which they can apply when they see attacks.

Once you have defined your categories you design a curriculum for each group. There will be a base level of knowledge, for the everyone else group. Then you extend the more advanced curricula to address the most significant risks to each specific group, by building a quick threat model and focusing training to address it. For example senior management needs a deep understanding of whaling tactics they are likely to face.

Keep in mind that the frequency of formal training varies by group. If the program calls for intensive training during on-boarding and semi-annual refreshers, you’ll want more frequent training for HR and Customer Service. Given how quickly attack tactics change, updating training for those groups every quarter seems reasonable to keep them current.

Continuous

Just as we finish saying you need to define the frequency for your different user groups, the first “C” is continuous. What gives? A security training program encompasses both formal training and ad-hoc lessons as needed. Attackers don’t seem to take days off, and the threat landscape changes almost daily. Your program needs to reflect the dynamic nature of security and implement triggers to initiate additional training.

You stay current by analyzing threat intelligence looking for significant new attacks that warrant additional training. Ransomware provides a timely example of this need. A few years ago when the first ransomware attack hit, most employees were not prepared to defend against the attack and they certainly didn’t know what to do once the ransomware locked their devices. For these new attack vectors, you may need to put together a quick video explaining the attack and what to do in the event the employee sees it. To be clear, speed matters here so don’t worry about your training video being perfect, just get something out there to prepare your employees for an imminent attack. Soon enough your security training vendor will update existing training and will introduce new material based on emerging attacks, so make sure you pay attention to available updates within the training platform.

Continuous training also involves evaluating not just potential attacks identified via threat intel but also changes in the risk profile of an employee. Keep on top of the employee’s risk profile, integrate with other security tools, including email security gateways, web security proxies and services, web/DNS security tools, DLP, and other content inspection technologies, security analytics including user behavior analytics (UBA), etc. These integrations set the stage for contextual training.

Contextual

If any of the integrated security monitors or controls detects an attack on a specific user, or determines a user did something which violates policy, it provides an opportunity to deliver ad hoc training on that particular attack. The best time to train an employee and have the knowledge stick remains when they are conscious of its relevance. People have different learning styles, and their receptivity varies, but they should be much more receptive right after making a mistake. Then their fresh experience which puts the training in context.

Similar to teaching a child not to touch a hot stove after they’ve burnt their hand, showing an employee how to detect a phishing message is more impactful right after they clicked on a phishing message. We’ll dig in with a detailed example in our next post.

To wrap up our earlier frequency discussion, you have a few different options for training delivery:

  • Scheduled: As described above, you provide materials during onboarding and as part of the ongoing training program. Periodic refreshers and updated training on new attacks are likely the bare minimum to meet your compliance requirements.
  • Preemptive: In this model you deliver training when triggered by threat intel or a change in risk profile, as determined by security analytics/UBA. The emergence of a new ransomware variant is an example of a likely trigger for preemptive training.
  • Reactive: This model triggers delivery of training when an employee makes a mistake. For example, train on how to protect customer data after the DLP system blocks an outgoing email with a customer’s social security number in the body.

Metrics

Assuming risk reduction is the overall objective of your security awareness training program, you need a way to assess its effectiveness. How can you measure your security training program? It starts by defining a baseline of security effectiveness. We all understand that assessing security goes well beyond training, but you need to understand your current security posture before starting a new training program.

That means tracking attacks against the organization, particularly the types of attacks most impacted by security training – including phishing, drive-by downloads, customer data leakage, etc. Obtain this information via integration with your email and web security tools and your SIEM or UBA system. If you cannot establish a baseline before the program starts, we recommend you initiate data collection immediately. It’s decidedly suboptimal, but you can trend improvement over time from the start of your program.

As far as metrics to track, you can use these buckets to get started:

  • Micro: Here you monitor employee-specific risk, such as how many times an employee clicks on a phishing simulation and how many times you’ve had to clean up the employee’s device after malware outbreaks.
  • Macro: These indicators include benchmark data from organizations of similar size and sector. You’ll want to know how many successful attacks hit your peers. Your training vendor likely has benchmark data you can use, and we increasingly see this kind of information in training dashboards and reports to provide insight into effectiveness.
  • Organizational: Based on micro and the macro data, how does your organization stack up? Here you’ll want to make an overall assessment of the organization, based on results from tests and other risk metrics/analytics.
  • Qualitative: You’ll also want to understand what employees think of your training program. We recommend organizations perform 360° evaluations via employee surveys to gauge the effectiveness of training content, and for a sense of their general understanding of security.

For each of these metrics/assessments, you should be able to access the data quickly and easily via both a dashboard and results. The dashboard should clear reflect both the micro and macro effectiveness of your efforts. Which employees need additional training because they make the same mistake over and over again? Which employees can’t seem to find the time to complete scheduled training? Are the number of bad clicks during phishing simulations trending in the right direction?

The documentation from the program will substantiate (or not) your training efforts, which will make the difference between expanding the program or sending it to the dustbin. We’ll wrap up this series in our next post, working through a detailed example of setting up the program – and, more importantly, adapting it as you learn what works and doesn’t.

- Mike Rothman (0) Comments Subscribe to our daily email digest

The Internal Network – Business Security Weekly #98

This week, we share a Pre-Recorded interview with Gabriel Gumbs, VP of Product Strategy at STEALTHbits! We talk about moving from detection to prevention, and protecting your data! In Tracking Security Innovation, Imperva acquires app security firm Prevoty, Allstate accelerates expansion into Identity Protection, 100+ startups globally accepted into StackPaths Propel startup program, Kaseya acquires RapidFire Tools, Very Good security makes data unhackable with Andreessen, and some excellent funding rounds from various companies!

Full Show Notes: https://wiki.securityweekly.com/BSWEpisode98

 

Visit https://www.securityweekly.com/bsw for all the latest episodes!

 

Visit https://www.activecountermeasures/bsw to sign up for a demo or buy our AI Hunter!!

 

→Visit our website: https://www.securityweekly.com

→Follow us on Twitter: https://www.twitter.com/securityweekly

→Like us on Facebook: https://www.facebook.com/secweekly