ITACS 5211: Introduction to Ethical Hacking

Wade Mackey

Steve Pote

Vulnerability trends from Tenable

by Leave a Comment

At some point the concept of ~Microsoft as a large target even if there were relatively few serious vulnerabilities due to market share~ has been topic of discussion in all of the ITACS classes.

Tenable uses current scan data and looks more as analyst than simply ~scanner~ to highlight the volume of risk associated with visibly vulnerable systems.

There is a great graphic demonstrating the effect of unaddressed vulnerabilities stacking over time and what appear as relatively small individual threat surfaces compound as legacy software remains in place, even when unused and no longer needed.

The presenter leads by explaining the need to update the CVE system of classification (most notably a *critical* level and measuring risk beyond the compromised system)

http://static.tenable.com/translations/en/Vulnerability_Intelligence_Report-ENG.pdf

Kali for Vagrant

by Leave a Comment

A little late for ~this semester~ but this is a great walk thru and discussion for ~any~ vagrant image you want to set up (like metasploitable3…)

https://www.kali.org/news/announcing-kali-for-vagrant/

Steam Video Game curation API

by Leave a Comment

Hacking an API endpoint is the web request sibling of SQL injection. It is a place where SQL Injection best practices  – parameterization and sanitization of input can be bypassed by directly interacting with a server in JSON or XML (or whatever vernacular your endpoint may spit out)

This would have interested me also…partner.steamgames.com/partnercdkeys/assignkeys/

This (and another more ~classic~ SQL injection attack) were discovered by a HackerOne guy who received bounties for his efforts and the full disclosure to the Steam company.

https://www.zdnet.com/article/steam-bug-could-have-given-you-access-to-all-the-cd-keys-of-any-game/

https://hackerone.com/reports/383127

https://partner.steamgames.com/

https://partner.steampowered.com/login/?goto=%2F

Banking Trojans on Android from Google Play (cross posting to all my classes)

by Leave a Comment

With a heightened awareness of news and a more pragmatic search for ~homework~ source material, this set off ~”that sounds like what we’re studying…” ~ alarms all over.

A bit of social engineering (free speed boost? sounds good to me!), pretense of trustworthiness from the distribution platform, a little something for everyone. All a terrifyingly direct mapping to the  cyber-kill chain/steps in a cyber attack (https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html)

There is even a javascript snip to fingerprint android emulations…and how to better spoof a real device from your emulation…er, if you wanted to do that sort of thing.

https://www.welivesecurity.com/2018/10/24/banking-trojans-continue-surface-google-play/

Exploiting the Ruby programming language

by Leave a Comment

 

Serialization – breaking down what you see into movable storable chunks – happens to everything we send or serve up. Always of concern is whether it has been *tampered with* (I heard something about data at rest an in transit somewhere). The vulnerability to ~de-serialization~ ranks eighth in the OWASP 2017 Top Ten 

Ruby is behind many web services…and some fun “administrative tools”…and we are studying it.

The deep end of the article gets fairly technical (not as much as encryption theory but ~code centered~).

The short short version is that ~auto load~ behaviors of frameworks (like those in Ruby) can allow a payload to be slipped into the serialized output of or exfiltrated from the service it supports.

Don’t copy/paste anything you couldn’t have written yourself.

https://www.elttam.com.au/blog/ruby-deserialization/

All the right elements for All Hallows Eve…

by Leave a Comment

Admittedly the word choices for Samhain were perfect…”body hacking movement”…implanted chips…

But really is this a nice addition to biometrics and an enhancement to our own security and communications possibilities?

I would line up if it came with internet…

How does one secure an implanted chip?

https://www.chicagotribune.com/news/columnists/kass/ct-met-swedish-body-hacking-kass-20181025-story.html

SSH Authentication Bypass

by Leave a Comment

This is a scary place to have things broken.

The number of systems actually effected is relatively small with fairly specific conditions needed but it is still just passing a server something it doesn’t expect…

…like the Jedi mind trick…this user IS SUCCESSFULLY authorized…

https://www.tenable.com/blog/libssh-vulnerable-to-authentication-bypass-cve-2018-10933

More on the lib itself…

libssh 0.8.4 and 0.7.6 security and bugfix release

 

Set your Clocks to 2038 (no, don’t…read this 1st)

by 1 Comment

I will admit to new ~reuse~ on this from another class…

…but this is a different audience.

This may look like dry sysadmin stuff, and a very small paragraph mentioning the _kernel_timespec…but this is roughly the Unix version of Y2K where 32-bit systems have been counting seconds since January 1970…and time is running out.

Realistically (and for those of us who may be retired in 2038), setting a timeout into the future on a machine that is vulnerable in this way would cause a buffer overflow. I heard they are bad. And cause interesting, sometimes exploitable side effects…

…since I first read this any time a system of update has innocently offered me a date range ~20 years or so into the future~ I have weighed breaking something I like or need Vs. Rodger Rabbit suggesting it might be funny. Not a hard experiment for a VM…

https://www.linux.com/news/2018/8/linux-kernel-418-keeps-things-solid-and-secure

https://en.wikipedia.org/wiki/Year_2038_problem

T-Mobile, unauthorized data capture and updates to the official word

by 1 Comment

I get to hang out with some very clever cryptographers at a bar about once a month. They make math-y jokes over my head, but demonstrate that best case is a stalemate where data is no longer significant before it’s encryption theme has become significantly penetrable.

T-Mobile announced an unauthorized capture of data. The updates paint a picture almost as disturbing as the loss itself in that they show either a misunderstanding or a ~careful wording to diminish verbal impact~, followed by better disclosure.

Here are a few that stood out for ~beer spit-take~ potential with the cryptography nerds;

“Because they weren’t [compromised]. They were encrypted.”

“may have included one or more of the following: name, billing zip code, phone number, email address, account number and account type (prepaid or postpaid).”

“about” or “slightly less than” 3% of its 77 million customers.” …so about …2 million…

https://motherboard.vice.com/en_us/article/a3qpk5/t-mobile-hack-data-breach-api-customer-data

https://www.t-mobile.com/customers/6305378821