What are /r/netsec's favorite Products & Services?

From 3.5 billion Reddit comments

The 17:

• BolehVPN
• ChillGlobal

- Glype

• Hola!VPN
• Hola!VPN Chrome Extension
• HTTP PROXY navigation in browser that support Web RTC
• IBVPN Browser Addon

- PHP Proxy

• psiphon3
• PureVPN
• SmartHide Proxy
• SOCKS PROXY
• SumRando Web Proxy
• TOR as PROXY on browsers with Web RTC enabled
• Windscribe Addons

> Additionally, if you’ve ever installed the Zoom client and then uninstalled it, you still have a localhost web server on your machine that will happily re-install the Zoom client for you, without requiring any user interaction on your behalf besides visiting a webpage. This re-install ‘feature’ continues to work to this day.

This is just unacceptable, when users decide to manually uninstall software you're not supposed to leave a form of backdoor to allow an easy and silent reinstall procedure. I would never do business with a company that does or even has a track record of having done this.

Reminder that there are decent tools that will cleanup files "left behind" this way like Bulk Crap Uninstaller (free and open-source) which should prevent most of those problems.

When all this went down last year the community created a fork of Stylish called Stylus, basically the same thing without any telemetry/spyware bullshit.

Homepage is: https://add0n.com/stylus.html

Firefox Addons page: https://addons.mozilla.org/en-US/firefox/addon/styl-us/

You can export any Stylish styles into Stylus and they'll work the same, styles on userstyles.org also work.

I like how this is literally all the "security advisory" from OpenSSL says about what the impact of the vulnerability is. Seriously? Maybe want to mention what exactly that 64k of memory might get an attacker, such as the private keys? This is the most pathetic advisory.

I feel like you're greatly exaggerating the complexity of this and the how much your time is worth argument. The conversion script would be really simple from what I can tell. Ducky script isn't even turing complete is it? Looks like it's just procedural line by line changes, probably an hours worth of work and then testing. Maybe I've only seen simple Ducky Script scripts but are we just talking about from:

DELAY 50 STRING notepad.exe ENTER

To:

... TrinketKeyboard.begin(); delay(50); TrinketKeyboard.print("notepad.exe"); pressEnter(); ...

... and just wrap that in a setup() and include definitions for those functions? Hell, it'd be easy to generate the C.

Here, took me all of 20 minutes:

https://repl.it/KLmo/1

Click run and it'll convert the example below. Paste in your own ducky script and it should work, except might need support for left shift and left control and a few other ducky script things, but otherwise that's minutes to add.

Yeah, the ducky is $40 and at a lot of our salaries it's not like anyone's going to avoid one due to cost. But we're also hackers and we do shit like this for fun and if we're going to spend time reading this article, it's not a stretch to think that we might duplicate it just because it's a point of pride to be owning boxes with a tool we personally built.

Until someone confirms otherwise, to me it looks like Silverlight is compromised and should be disabled. At this point it is deprecated in favor of HTML5, so hopefully can be removed soon. (This email below was 5/5/2015, MS deployed patches to Silverlight on 5/12/2015. But unless the author confirms that his 0day is patched (and, we believe him) it's hard to know.

https://wikileaks.org/hackingteam/emails/emailid/44555

PS Too many researchers are digging into Flash nowadays. Flash is the new Java and it's hard to predict how long a Flash 0day will stay a live. So you can suggest to your customers to take a look at Silverlight, which is a safe harbor. I found it in May 2011 and it's still 0day. The quality is the same as for Flash (32/64-bit Win/Mac).

I work for Name.com <http://www.Name.com/>. For the record, we didn't give into the attackers demands. The demands were to give them the domain and pretend it got "stolen". We worked with the customer to get the domain moved off of our network. It was either that or disable the domain so that the rest of our customers and our main site were no longer affected. We would have loved to have kept the domain under our control and defeat the attackers as well but unfortunately in this situation we were unable to.

EDIT: Rather than go line by line, we wrote up a blog post to answer any questions and be transparent about why we handled this the way we did: http://blog.name.com/2012/04/ddos-attack-post-analysis-and-introspection/

Well, let's start at the beginning. For Networking, I recommend https://www.cybrary.it/course/comptia-network-plus. Actually, all of Cybrary is your friend, and it's free.

As for security, the KLCP is a GREAT place to start (http://kali.training) and it's also free. I'd start there. Follow the online book/PDF and do all the exercises. This will give you a foundation. Play, play, play on your own VM's (never on other people's sites) and it will come together for you.

OSCP is the "mic drop cert". In my opinion, it's the only cert in our field that proves you can perform, under stress and get the work done.

Disclaimer: I am an employee of Offensive Security, but opinions are my own and my honest opinion.

it's not the first time filezilla bundled malware. they were one of the voluntary partners of sourceforge's bundled installer before they pushed it on everyone and then got rid of it after they got bought out.

Use WinSCP! It's truly free and open source.

Funny thing: the CEO of Black & Berg Cybersecurity previously thanked LulzSec in the following tweet:

> @LulzSec Black & Berg Cybersecurity Consulting appreciate all the hard work that you're putting in. Your Hacking = Clients for us. Thx ~Joe

Or if you have an Android phone with the appropriate kernel patch, Drivedroid.

Edit: ~~Oh and a chipset capable of USB host mode.~~ Edit2: I'm getting confused with the poor Nexus 4 users.

>Something like 90% of websites that use SSL encryption — [green lock] — use an algorithm called SHA-1 to protect themselves from being impersonated. This guarantees that when you go to [green lock for facebook.com] , you're visiting the real Facebook and not giving your password to an attacker.

Well this isn't really true per se. The signing authorities use these stronger algorithms in an attempt to prevent people from creating fake certificates that appear to be signed on behalf of them .. thus being trusted by your browser. This has been demonstrated through collisions with MD5. SHA-1 or SHA-2 doesn't mean a CA hasn't been hacked, tricked, or otherwise purposefully given out a certificate to an unauthorized party. You're still at the mercy of your trusted root certificates. This can be prevented or severely limited with certificate key pinning.. which is quite different.

Defaulting clients to run as nodes. It would result in a lot more nodes, making it a lot less feasible to crack.

Edit: this isn't without its own set of problems: there's an entry on the Tor FAQ page about why they don't currently do this.

The race condition is interesting but only so far as it wastes disk space. The biggest problem here is that people continue to accept filenames from the client.

In almost all languages, including PHP, you're able able to accept the incoming file(s) being uploaded and turn them into a stream which you can then check (e.g. does the first block contain the expected bytes) and then save as a filename of your choosing (e.g. UID + extension based on opening byte sequence).

Allowing someone to save a file as .htaccess is the exploit here, not the race condition.

https://www.hybrid-analysis.com/sample/a98b171d509ff37a8fc5f3f87d0b3ed04730e2499d7ca3a9100bac38233c50b7?environmentId=120

Communicated with those same two domains from the forum post (gubuh.com and goquc.com) and it turned out to be a RAT/NJRAT :Z

Here's from the horse's mouth:

https://sourceforge.net/p/keepass/discussion/329220/thread/e430cc12/#f398

> It is true that the KeePass website isn't available over HTTPS up to now. Moving the update information file to a HTTPS website is useless, if the KeePass website still uses HTTP. It only makes sense when HTTPS is used for both. Unfortunately, for various reasons using HTTPS currently is not possible, but I'm following this and will of course switch to HTTPS when it becomes possible. > > Much more important is verifying your download (which I'd recommend independent of where you download KeePass from). The binaries are digitally signed (Authenticode); you can check them using Windows Explorer by going 'Properties' -> tab 'Digital Signatures'.

> Best regards,
> Dominik

(My opinion: Minor importance. I always download it from scratch anyway)

Yup, that's one way. We found single word domains actually transfer ownership pretty frequently; do.com for example was owned by squarespace, salesforce, microsoft, and a few others all within the conceivable lifespan of an ssl certificate. Salesforce had a valid cert while squarespace owned the domain. Stripe.com was another example, the previous owner still had a valid cert for a short while.

The second way to exploit this, the easier way, is the DoS way. CA's must revoke certs for domains that the owner didn't renew, within 24 hours of them being made aware. So pick a company, enum all their domains, and find one of their certs still being used, that's shared with a non-registered domain, and then you can potentially pull the rug from under them and revoke their prod cert within 24 hours.

Gets more interesting with CDN's, that often intentionally throw dozens or hundreds of customers on the same certificate. You can basically DoS the CDN, either by intentionally loading domains into their platform about to expire, or just by looking for existing domains about to expire.

I don't know a lot about Zenmate specifically, but...

You know the saying "if the service is free, you're the product"? In the case of free VPNs, this is often taken quite literally. If it's not inserting you into a botnet like Hola does, it's probably installing adware and prompting you with product offers regularly, or at the very least selling information about your usage and browsing history to the highest bidder.

People should always be wary towards these.

Isn't calling these two things 0-days a bit of a misnomer?

I mean you can get the OS with javascript just by inspecting navigator.UserAgent. I don't think I can remember Tor Browser being in state where you could safely run javascript and hide this kind of information, so how would this qualify as a 0day?

Also I believe, the issue of identifying a tor connection has always been a problem, even with pluggable transports*, so how exactly is this a 0day either?

*Whonix has a quite interesting list of such attacks https://www.whonix.org/wiki/Warning

From: Florian Weimer <fw () deneb enyo de>

Date: Thu, 19 Jan 2012 20:18:37 +0100

>I recently found out that it is possible to kill a screensaver/screen locker program on the latest version of Xorg (1.11 shipped with archlinux, debian wheezy..) using the Ctrl+Alt+Multiply key binding.

This used to be, uhm, common knowledge:

| Option "AllowDeactivateGrabs" "boolean"

| This option enables the use of the Ctrl+Alt+Keypad-Divide key

| sequence to deactivate any active keyboard and mouse

| grabs. Default: off.

| This option enables the use of the Ctrl+Alt+Keypad-Multiply key

| sequence to kill clients with an active keyboard or mouse grab as

| well as killing any application that may have locked the server,

| normally using the XGrabServer(3x) Xlib function. Default: off.

| will allow users to remove the grab used by screen saver/locker

| programs. An API was written to such cases. If you enable this

| option, make sure your screen saver/locker is updated.

<http://www.x.org/archive/X11R6.8.1/doc/Xorg.1.html>

The API in question appears to be XF86MiscSetGrabKeysState:

<http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/XF86Config.man?hideattic=0#rev1.6>

While the failed attempt at hashing ID numbers is the headline here, as pointed out over at HackerNews, it's also highly likely that the level of fine-grained detail in this data makes it possible to identify and track individual passengers, regardless of the MD5 fail.

>How do I know my choice of site to download it from hasn't compromised Tails? How do I know if Tails has or hasn't been compromised at all?

This is where OpenPGP signatures come into play. The key given verifies the integrity of the file and ensures that it hasn't been tampered. However, you could be the victim of a MITM attack by a state authority or malicious entity which seeks to undermine your version of tails and provide you a tampered backdoored copy and its corresponding signature. The Tails team provides this guide to 'better' protect you against that. Ultimately, you can try getting the verification key from several locations (countries?) and devices to verify the installation you have is genuine.

From the MSFT Security Bulletin: "The vulnerability could allow remote code execution if a user opens a legitimate rich text format file (.rtf), text file (.txt), or Word document (.doc) that is located in the same network directory as a specially crafted dynamic link library (DLL) file."

Of course this is obviously horrible for the people involved. https://nitter.net/MichalPurzynski/status/1293249273346179072#m

However that said, it could have a chilling effect on Firefox, Rust, and Tor Project regarding security at the bare minimum. Other areas will of course be effected. However, with Firefox we are already seeing them a decade behind on security. They are not in a position to further weaken their security model.

I don't think anyone knows the full extent of what this means outside of security. I imagine this is to make them more profitable

This article is factually incorrect. You can verify this by cutting power to a machine protected by BitLocker. The drive will still be encrypted (and unreadable without the key) on another machine. There is no link to the "documentation" that says BitLocker-protected machines must be shut down gracefully because that documentation doesn't exist.

The clear key is stored on disk in the BitLocker metadata when you suspend a drive and ONLY when you suspend a drive. The "clear key" is not generated just by decrypting a volume (e.g. by unlocking your drive with the TPM protector). When you unlock a volume, the Full Volume Encryption Key is stored in memory and this is what's used to decrypt disk data. Further info:

http://technet.microsoft.com/en-us/library/cc732774(v=ws.10).aspx

There IS a vulnerability with a powered-on BitLocker machine (the same with any drive encryption technology), which is that an attacker can perform a cold boot attack (physically pulling out the RAM and reading the data):

https://citp.princeton.edu/research/memory/

Mitigation: If there's a risk of someone stealing your machine, put it into hibernate so that the keys are not stored in memory.

Likely explanation for this researcher's observed behavior: suspended BitLocker protection at some point and forgot about it, didn't realize the drive was being unlocked with the clear key instead of the TPM.

If you use Linux or OSX, you can use sshuttle to tunnel virtually everything, including DNS and Flash. It's faster than using a plain SSH tunnel, and easier than setting up a VPN.

The bug is in the RDS implementation. To my knowledge, it's not very widely used.

Most distros that provide it only do so as an unloaded kernel module. That's certainly the case with RHEL 6, RHEL 7, and Debian Stretch.

NSA has a department that examines encryption code for vulnerabilities. In 2013 alone, according to documents provided by Edward Snowden, the NSA spent more than $25 million on zero-days. They surely went over openSSL source code line by line and found the bug not long after it was released. I wouldn't be surprised if they contributed the code themselves.

Last year I suspected that press coverage of the NSA and FBI asking for website's SSL keys was nothing but a diversion to fool people into thinking their SSL and TLS sessions were safe, like a dragnet honeypot. Now I have little doubt that it was the case.

Ref: Feds put heat on Web firms for master encryption keys - CNET

edit: added 2013 quote and link.

There's a lot of uninformed comments in this thread.

I argue everyone to read Apples white paper on its security model: https://www.scribd.com/mobile/doc/209476613

I think it's clear that Apple does take security seriously. It beats the competition out of the water in my opinion.

Not Foscam for once :)

root@raspberrypi ~ # nmap -PN 10.100.100.10

Starting Nmap 6.00 ( http://nmap.org ) at 2015-09-28 01:13 UTC Nmap scan report for Foscam-[Redacted] Host is up (0.064s latency). Not shown: 999 closed ports PORT STATE SERVICE 80/tcp open http MAC Address: 48:02:[Redacted] (B-Link Electronic Limited)

Nmap done: 1 IP address (1 host up) scanned in 4.92 seconds root@raspberrypi ~ #

This is a total tangent but because of https, companies like NordVPN littering false info in their sponsorships about "Your banking info being stolen on starbucks wifi by another person in the room."

It's weirdly frustrating to hear this all the time since https is super super common now, even for mundane stuff like, for instance, reddit.

Not just the TLS stack. Pretty much any aspect of MirageOS is fair game (TCP/IP stack, OCaml runtime, etc).

Here were some thoughts from one of the Piñata authors. https://news.ycombinator.com/item?id=9028581

Shouldn't the check on line 1644 have a trailing backslash to avoid any future case where a new filesystem device is implemented whose name starts with "Mup"? It'd have to check for ; after the verification, but it'd save future bugs.

Also, is it possible to pass an NT path (e.g. \\?\GLOBALROOT\Device\Mup\localhost\C$\...) from usermode? If so, could you abuse device symlinks such as \Device\LanManRedirector which are symlinked to \Device\Mup?

EDIT: I searched after writing this, found an interesting article about messing with these paths, then realised James wrote it. Heh.

Probably worth looking at a fork of that add-on, which does not autonomously download a list of websites to be redirected.

https://addons.mozilla.org/da/firefox/addon/fireice/

I haven't tried it but its author certainly makes a good point.

Looks like they just changed over the cert (and I notice the https site is no longer pay.reddit.com, but just www.reddit.com). Looks like they were implementing good changes, but in the process left what is a (hopefully) temporary security hole. Https-everywhere didn't automatically redirect to the https site (because the address is different now), and meanwhile firefox came up with an exception when I manually directed it at https://www.reddit.com. Verified authentic by Perspectives extension for Firefox, so no MITM suspected. I'm going to have to agree though...nice effort, poor form.

Edit: This actually may not be entirely reddit's doing. It looks like https-everywhere somehow disabled forcing https on reddit, though I know it used to redirect automatically (and it looks like pay.reddit.com does still work as https). I'm going to assume that they changed their cert setup, and for the same reason that firefox gave an warning about the cert, https-everywhere dropped it by default. You can manually re-enable it though. Hrmph, these security tools are making me/us lazy...it's almost like they're causing a security hole...

Edit 2.0: All right, I'm not actually sure anything changed now, other than it looks like https-everywhere. But I did just change enough about my personal configuration over the last few days that I can't really confirm any of my speculations, and am realizing this. I'll leave this here for completeness...perhaps it'll be helpful in uncovering the cause, or at least solving the issue on the user's side...

That frontpage banner is trying to convey the essential idea behind Tor as quickly as possible. Before you can actually download and use Tor, you have to browse past an orange warning box that links you to this cautionary list

You are not being accurate when you say: > No asterisks, no disclaimers, just boom, instant securification.

I use Dropbox; on Windows, you have the Dropbox sync app; on Android, I use Keepass2Android which has a Dropbox option for accessing the file.

More details: http://lwn.net/Articles/637613/rss

>> It seems it was about time for another certificate authority horror story; the Google Online Security Blog duly delivers. "CNNIC responded on the 22nd to explain that they had contracted with MCS Holdings on the basis that MCS would only issue certificates for domains that they had registered. However, rather than keep the private key in a suitable HSM, MCS installed it in a man-in-the-middle proxy. These devices intercept secure connections by masquerading as the intended destination and are sometimes used by companies to intercept their employees’ secure traffic for monitoring or legal reasons. The employees’ computers normally have to be configured to trust a proxy for it to be able to do this. However, in this case, the presumed proxy was given the full authority of a public CA, which is a serious breach of the CA system."

>run man in the middle attacks with ease

Yes, this is possible if an attacker obtains the private key.

>decode all the traffic being sent to the devices

Actually, no; ssh uses ephemeral session keys that are exchanged via the Diffie-Hellman protocol, which provides perfect forward secrecy. The private key is only used for authentication, not for key exchange, so a purely passive attacker (or one reading transcripts) with access to the private key will not be able to decrypt the traffic. Some links:

http://lwn.net/Articles/572926/
http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Another plausible version on ycombinator: >Maybe while looking at the code themselves they found a very bad bug which would make previously made encrypted partitions easily crackable, and fixing it would obviously make the world aware to this, and they don't want to endanger or ruin the lives of everybody who has had a truecrypt container with sensitive data taken from them (for example to a malicious government), so the only way to go for them is to tell people their product should not be used any more and is bad.

GPG Reaper

TL;DR: Obtain/Steal/Restore GPG Private Keys from gpg-agent cache/memory

This POC demonstrates method for obtaining GPG private keys from gpg-agent memory under Windows.

Normally this should be possible only within 10 minutes time frame (--default-cache-ttl value).

Unfortunately housekeeping() function (which is responsible for cache cleanup) is executed only if you are using GPG (there is no timer there).

This means that in normal GPG usecase like: you sign some file then close GUI and do other task you password is still in gpg-agent memory (even if ttl expired).

Attacker, who has access to your current session, can use this for stealing private key without knowing your passphrase.

Introduction

GPG-Agent is a daemon to manage private keys independently from any protocol.

GUI interface communicates with agent using Assuan Protocol.

By default agent caches your credentials.

--default-cache-ttl n option set the time a cache entry is valid to n seconds.

The default is 600 seconds. Each time a cache entry is accessed, its timer is reseted.

Under Windows sign process looks like this:

Sign Process

Crucial part here is housekeeping() function which is responsible for removing expired credentials from the memory.

But there is one problem here: this function is executed only in two places (inside agent_put_cache and agent_get_cache).

This means that cached credentials are NOT removed from the memory until some gpg-agent commands which uses agent_put_cache or agent_get_cache or agent_flush_cache are executed.

Proposed patch for CVE-2014-7169 here:

http://www.openwall.com/lists/oss-security/2014/09/25/10

I am building bash updates for Ubuntu containing the proposed fix here and will publish them once the fix has been made official:

https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages

edit: fixed URL

If you don't want to bother with a magazine, add this collection I made to Google Reader. There might be a little cruft in there, but overall it is an excellent resource.

P.S. I'm taking suggestions for other feeds to add if anyone has some good ones.

I swear I've attached to a Windows shared drive by forwarding TCP port 445 before. Maybe I was dreaming.

Anyway, never forget ssh negotiates the connection in clear text, so you'll pop up some red flags on the corp IDS. AFAIK most still can't detect obfuscated-openssh.

Aaaaannnnd now with LAN scanning!

Party like it's Java applet socket!

The best part? Even if you disable WebRTC in chrome:flags, it still works, without asking any permissions!

Did they say to switch to Bitlocker which is thought to be insecure? Maybe that's another hint. "Hey get in that other boat that's filling with water..."

Edit: Indeed someone said this better than I did.

Heyo: as every greybeard who came to this thread already knows this has been a thing for many years. Open Source Tripwire is an open source file integrity monitor.

It's still around, supported on lots of operating systems and available on github: https://github.com/Tripwire/tripwire-open-source

Lightweight integrity monitoring definitely works too and I applaud your efforts :) . I hope you continue to expand on the capabilities and supported platforms!

From hackernews https://news.ycombinator.com/item?id=7826213 >Hi Bruce from Subgraph here. Yesterday we updated our website with information about a new project that we've been working on since December and made a very small announcement on Twitter about the website change and this generated more attention than we were expecting. So I should clarify the status of the project which is that we haven't released anything yet, but we've been working on what is described on our website for the last 6 months. We predict but can't promise that we'll have something available for brave enthusiastic people to test by the end of summer. That's the point at which we normally would have announced our project here.

Hey guys, this is Saikat from Stripe. Ross Boucher and I wrote the Javascript referred to here. I'd be happy to address any questions/concerns.

To address the OP, there is not a whole lot going on client-side in the Javascript bindings. The way it works is:

• You build your form and include stripe.js and set your publishable API key (this key can't do anything except the one call that stripe.js makes).
• User enters his credit card details (this, of course, has to happen on the client).
• You use Stripe.js to send the card details to us. This is a normal HTTP call - the only difference between using Stripe.js and a normal form is that the POST goes to our server instead of yours.
• We reply with a one-time use token representing the card.
• This token gets POSTed to your server.

Basically, the only difference here between using stripe.js and not stripe.js is that, when using stripe.js, the form POSTs to us first instead of you (we aren't doing any sort of client-side encryption or anything like that). This has the benefit of both removing most of the PCI burden from you (you don't need to do anything more than fill out the account application we give you) as well as keeping you from having to think through the security implications of having credit cards hit your server (e.g. making sure your logs are scrubbed of card numbers, making sure you aren't ever storing CVCs on disk, making sure you don't accidentally email out all your card numbers onto your mailing list, etc. =). You still need to serve your form over SSL though (as is the case with any checkout page that is accepting credit cards in order to both avoid man-in-the-middle attacks and to give your customers a warm fuzzy feeling).

Hope that answers some of the questions. I'll be lurking here, so comment away.

(Edit: also feel free to come talk to us in our campfire (https://stripe.com/campfire). At least one of us is around pretty much all the time)

This is already possible, via the excellent https-everywhere extension. Also works on reddit, google (a bit annoying since https://encrypted.google.com does not have a direct link to image search results), wikipedia, and others.

It's named that way on purpose.

> In general, setting HTML from code is risky because it’s easy to inadvertently expose your users to a cross-site scripting (XSS) attack. So, you can set HTML directly from React, but you have to type out dangerouslySetInnerHTML and pass an object with a __html key, to remind yourself that it’s dangerous.

I almost forgot, there is a new version of OpenVPN 2.3.9. It has several Windows-related fixes, and a long awaited option “block-outside-dns” which fixes DNS leaks on Windows 8.1 and 10.

That’s how I got my $5000 from Private Internet Access and additional $1000 from Perfect Privacy for such a bullshit issue. I feel kinda uneasy about this. Part of that money will go to OpenVPN and strongSwan developers.

If you haven't heard "X VPN released information leading to DMCA notice" or "X VPN released information leading to a raid" in the news, like HideMyAss, then it's safe to assume that they are not going to give up your activity at this time, even if they are logging it. As I said, it is based off their track record. If you can't trust anyone on the web to handle your data, even if it's encrypted out the ass, then you shouldn't really be on the Internet. So, yeah, my trust is leaning on the VPN provider because their entire business is on the line if they start outing people.

EDIT: If you're ultra paranoid then find a VPN that lets you sign up and pay anonymously. Even if they keep logs, if you're taking the right measures, it won't point back to anyone with concrete proof. Just some gift card that was paid for with cash. It wouldn't hold up.

EDIT2: If you're ultra ultra paranoid then wear a hood and dark sunglasses when you buy the gift card with cash.

EDIT3: If you're super mega ultra ultra paranoid then don't take your own car to the store that you buy the gift card from. Have a cab come pick you up from an empty house. Just be sure to already have the hood up with sunglasses on, because cabs have cameras.

From the looks of things, the CA key is exposed, which normally means that someone would be able to impersonate any VPN server on their network. There's no good reason for that key to actually be on the VPN server in the first place.

Also exposed appears to be a certificate and key for *.nordvpn.com which is also pretty bad.

https://web.archive.org/web/20190603203749/https://ghostbin.com/paste/azk4r

Footnote says:

> ^ Although we observe these scripts query the Facebook API and save the user’s Facebook ID, we could not verify that it is sent to their server due to obfuscation of their code and some limitations of our measurement methods.

If you are sending the comms through Burp, you can find out fairly easily without having to wrestle with de-obfuscating code.

HSTS has been (at least partially) supported in both Chrome and Firefox since version 4. Opera since version 12, Safari since version 7, and IE is retarded.

source

It looks like somebody wanted to impersonate secure login pages with a lot of detail, let's say they have the ability to control your DNS and can re-direct you to a site that claims to be https://twitter.com/login but actually isn't. Your browser will not only tell you that this site has an SSL Certificate but is an SSL Certificate that is for twitter.com and is perfectly safe. So, the site looks like twitter, it's on the twitter domain name and your browser doesn't warn you that it's unsafe, I'd probably give that site my details.

The issue here is that browsers have to trust the people that provide certificates because if it fails on a legit site people get pissed off.

We trust the CA (Certificate Authority) to not do dumb shit like let any one generate a certificate for google, twitter or even my completely unknown site that only I use. They have checks in place for that but someone has got around them.

“NordVPN hit back at the complaints, claiming that while data accessed via HTTPS-protected sites were encrypted, there still were security concerns about the use of public networks which could leave users' data vulnerable to theft if the connection wasn't secure.”

Their explanation is pretty airtight.

Tunneling DNS over a VPN is safer than the alternative. DNS attacks are trivially easy on open wifi. Sure, HTTPS will warn them the cert isn’t right, but they would never get hijacked in the first place if tunneled over a VPN.

And thats just the DNS protocol we’re talking about. Haven’t even made it to HTTP...

I’m not saying I support their advertising, because it’s definitely a hyperbole, but they’re absolutely right about the possibility of threats and the benefits of using a VPN.

Nope, Here is the Android app, and there is a chrome plugin for desktop currently in beta

It's distro-specific. For example, here's the page Canonical is maintaining that specifies which kernels they have (or will) backport the fix to.

For everyone else, you can expect it in a long term*, stable, and mainline kernel very soon I would suspect given it's priority rating... It's already in mainline.

*depends on who is maintaining it, and their reaction time.

Hi just wiresharked myself on https://www.youtube.com, here are my conclusions:

The entire traffic is encrypted except for the following:

• search suggestions: when you start typing in the search bar of youtube, every new character entered results in a request to: http://suggestqueries.google.com/complete/search?&lt;WHAT_YOU_ARE_TYPING&gt;&amp;blablabla. Theses requests are sent in the clear. You should try disabling suggestions (if possible).

• the FLV itself: the content of the video you are watching is downloaded in the clear, this means that it is indeed possible to see what you are currently watching.

So, in theory, they can see what you searched for and what you looked at, but they cannot see anything related to your youtube profile (username/friends/etc) and they cannot see if you upvote/downvote a video, or if you comment on something.

And a Google search backs up my observations.

And do you have a better solution–as a professional–to finding out whether an anti-virus program has detected a virus than checking it's logs?

I struggle to think of one, but I may not be as capable as you are... Lol

https://1password.com/pricing/

Looks like there is a one time version as well, and the $5 version actually is a family plan for up too 5 users. That seems reasonable for something that needs to be actively patched and product support (apps/os version etc), but you know developers don't need food.

If you want to be cheap just use keepass and sync it via btsync or something, and stop complaining about someone charging for a product of convenience.

password_hash creates password hashes, currently using crypt. It and password_verify are not suitable for creating or checking cryptographic hashes.

For general purpose hash comparison, there's now <code>hash_equals</code>, which does string comparison in a timing-safe way.

If anyone wants a quick and dirty find + fix script. Did the job on about 600 installs for me today.

#!/bin/bash curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch > /tmp/drupal.patch for x in $(egrep -l "define.*VERSION.*7." $(locate includes/bootstrap.inc)); do db=$(echo $x | sed "s,bootstrap.inc,database/database.inc,"); patch -p0 --dry-run $db < /tmp/drupal.patch if [[ $? -eq 0 ]]; then patch -p0 $db < /tmp/drupal.patch fi; done;

I know that Private Internet Access will leak your IPv6 address even with "leak protection" turned on. Which is interesting because they're listed as "not vulnerable" in whatever test was performed here.

>This is not the default behavior for a UIWebView. It relies on a practice that is very common among developers of iOS apps with web content.

>Specifically: every click/interaction that loads content in your custom web view sends the webView:shouldStartLoadWithRequest:navigationType: message to your web view delegate. Without implementing that method, clicking a tel: link will prompt first. However, many apps throw some logic in there to detect any URI schemes that don't match the standard HTTP/HTTPS schemes used in normal websites, and trying to do something "nice" for the user, they handle requests for those URIs by calling:

>[[UIApplication sharedApplication] openURL:request.URL]; This is a reasonable thing to do (outside the context of tel: links) because it allows the app to spawn an external app for custom URIs.

>Therein lies the problem: not that UIWebView opens tel: links without prompting (it doesn't), but that many app developers are just trying to improve the inter-app experience, and unknowingly open tel: links directly with that openURL: method.

From https://news.ycombinator.com/item?id=8208244

Yes. In Linux the process asks for memory with the mmap and brk/sbrk syscalls, and those come zeroed. malloc calls those syscalls when it needs more memory, but if it reuses some memory block that was previously allocated by your program it won't zero it again.

Charles Schwab bank's password requirements are nearly as bad:

>Our password requirements, which facilitate online account security, are as follows:

>Your password must be 6-8 characters long. It also must:

>* Include both letters AND numbers. >* Include at least one number BETWEEN the first and last character. >* Contain no symbols (!, %, #, etc.)

Not case sensitive is pretty much the dumbest thing ever, though...

There is a preconfig package based on this wonderful repo that takes care of a lot of those things: https://github.com/Disassembler0/Win10-Initial-Setup-Script

Also, not sure why you were downvoted, that preconfig is one of my favorite parts about the install because Windows does have a lot of “features” that I like to disable

http://sourceforge.net/projects/drvback/ Open source. Every time I set up a new PC for someone, I download the iso from Microsoft and activate it with the key that came with the laptop.

Install DriverBackup!, run it to backup all drivers and fresh install of Windows.

You forgot to link armitage:

http://www.fastandeasyhacking.com

Also "mudge" is typically reserved for this guy :

http://en.wikipedia.org/wiki/Peiter_Zatko

Funny enough, he runs the Cyber FastTrack program that pays for development of armitage (as well as nmap, hackrf, etc).

It's not that it is incomplete, it is outdated advice from 5 years ago.

Today you will get compromised just by trying to read your local newspaper that had malicious javascript embedded into ads (happened here. Twice.) If it's not your local newspaper it's the WSJ, or pandora, or any of the number of sites that let anyone embed whatever code they want in their pages as part of advertisements.

I've seen people get compromised by drive by java exploits after clicking on the top result from a google search. The idea that people are safe if they just don't download things is completely false.

Oh, and even reddit has had this problem

Here is the virus total link from that event. 5 out of 41 anti-virus programs detected it.

https://www.torproject.org/docs/faq-abuse.html.en#TypicalAbuses

https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment

> 1. Inform your potential ISP(s) 2. Get a separate IP for the node. Do not route your own traffic via this IP 3. Get recognizable Reverse DNS for this IP 4. Set up a Tor Exit Notice 5. Get ARIN registration (if possible) 6. Consider a Reduced Exit Policy 7. Rate limit and optionally QoS your node 8. Consider creating an LLC to run your node

Cyberduck is really good but lacks a linux version. The ability to connect to cloud storages stands out in particular.

But WinSCP is really the most consistent multiplatform FTP software for oldschool webmasters.

Agreed, there is some good stuff in there.

He does make some minor mistakes but seems experienced/comfortable.

Plus, his write up on hacking Hacking Team showed some level of skill. Writing backdoored firmware for an embedded system and not bricking it, etc., is pretty good.

An anonymous poster on Hacker News claiming to be an Amazon engineer says they're planning to switch to full HTTPS by September. Hopefully that's true.

>The hack was originally thought to be limited to the official Steam forums, but further investigation has revealed that the hackers had access to a database containing “user names, hashed and salted passwords, game purchases, email addresses, billing addresses and encrypted credit card information.”

More information: http://techcrunch.com/2011/11/10/psa-steam-hacked-user-info-stolen-but-personal-data-safe/

As far as I know you are supposed to get a small amount of entropy from your operating system regularily and use that with a secure random number generator in userspace.

OpenBSD provides a random number generator called arc4random(3) for that purpose. I generally trust them to know what they are doing.

But you know that there are at most 7 letters and at most 7 numbers.

<code>sum from i=1 to 7 of C(8,i)*10^i*26^(8-i)</code> = <code>36^8 - 26^8 - 10^8</code> = 2,612,182,842,880

Not a significant reduction, but what's 200 billion between friends.

Closest you gonna get, without consulting the dark Web would be to put your email address into https://haveibeenpwned.com (which is run my Troy Hunt, and mentioned in his article) to see whether your email address is included in the leak.

This is complete and total bullshit. IRC channels are loaded with federal agents, and HideMyAss isn't even remotely secure.

Look at what happened last month with - year long FBI sting targeting script kiddies. This is likely no different.

The cracking programs* don't use the CPU, they use the all the parallel processors (GPU) in the video cards. So for a lot of these tasks they're greatly outperforming a multi-CPU setup with just 4 commodity video cards.

*most/some, not sure, john the ripper doesn't

Article here on GPU cracking:

http://www.tomshardware.com/reviews/wireless-security-hack,2981.html

This page on basic GPU over CPU:

http://www.tomshardware.com/reviews/wireless-security-hack,2981-8.html

For those wondering how to protect against this sort of breach, AWS Config Rules can help out tremendously. It allows you to specify rules matching certain conditions (EBS volumes with "public" bit set, for instance) and then run an action (alert, mitigation,etc.) in response to events that match the rules.

Facebook can track people based on the pages they visit, if those pages have Like buttons on them, just like Google Analytics, and then create "shadow profiles" of everyone.

http://www.zdnet.com/firm-facebooks-shadow-profiles-are-frightening-dossiers-on-everyone-7000017199/

Trolling means fishing for something, or searching an area for something. http://www.thefreedictionary.com/trolling

The usage you are familiar with is fishing for reactions on the internet. Their usage is talking about searching college networks for specific data.

It's not a very good word to describe what they are describing, but it's not a monumental misunderstanding of The Internet, either.

For easier reading: Navigating PCIDSS

Also, if this does fall under PCIDSS, you're making more work for yourself than its probably worth. Consider outsourcing any payment handling to a third party service like stripe

Have you tried it recently? Antivirus testing companies give it an almost perfect score. After having bad experiences with avg, kaspersky, and bitdefender I tried Norton and have been generally happy with it for a little over a year now. It has a pretty shitty reputation as well but besides the toolbar plugins it bugs you about its pretty slim, fast, and effective.

Source https://www.av-test.org/en/antivirus/home-windows/windows-8/

Edit For the record Im only wondering. I haven't used mcafee in over a decade, so I have no bias either way.

Take a look at airdrop-ng. Although there are malicious uses, from an enterprise level you can also:

• prevent your users from connecting to open APs near your business (force them onto the encrypted wifi you provide)

• turn the tables and deauth an attacker from your own network (drop any MACs that aren't already in your own inventory system)

There are other practical applications, like most "hacking" tools it's a double-edged sword.

> it is a way around the protections noscript offers so it is TECHNICALLY a bypass.

It is a bypass, but NoScript doesn't pretend to provide any type of active protections against this kind of bypass. The way that the Anti-XSS feature works is clearly explained. It is clearly stated there that NoScript does not block XSS content from sites not marked untrusted to a trusted site - it is FIrefox that ends up doing that, based on the same-origin policies provided by those websites. NoScript doesn't even check those policies at all, let alone trying to detect if a trusted site is vulnerable to XSS and blocking it. The only way around this would be for NoScript to treat every non-whitelisted site as untrusted, but that would only cause more problems than simply letting Firefox handle this case.

The IFRAME thing (allowing IFRAMEs to run Javascript while the parent document had Javascript blocked), I think, was also a vulnerability in Firefox, which was fixed a long time ago. If not, then NoScript does have an option to block IFRAMEs on non-whitelisted sites.

The sweet spot of this seems to be debugging the SSL configuration of your server. For everything else, I feel there are more convenient ways.

If you're just interested in the communication contents, just open chrome://net-internals/#events (or the devtools for a high level view). Works without any installation whatsoever, also on the stable versions. For actual debugging on the protocol level, I'd go for mitmproxy, which offers client/server replay etc. (I'm affiliated with the project - Burp, Fiddler, Charles, ZAP, ... would be great alternatives, so it's not about that).

A poisoned DNS is bad, but not THAT bad. If I type https://mail.google.com, but get a poisoned DNS redirect to Russia, you'll still get the big OMG WARNING!!! GET ME OUT OF HERE!!! screen if they don't have a trusted SSL cert. If they've gotten control of a trusted CA, though, they can make a cert that looks like Google, passes any inspection you care to give it, and you would have no way of knowing that you're really talking to Russia (without doing a trace route or something else wacky).

Don't reveal your VPN provider, don't reveal you're using a VPN, don't do anything that'll tie that VPN IP range with other things you do, and don't reveal you're doing illegal things to random people you talk to on IRC. If he had simply spoken with no one, it is highly unlikely he could've been charged for accessing someone's Gmail with a VPN. But if you say "lol I'm in this guy's Gmail and yeah I use the Perfect Privacy VPN" to informants, then it no longer means shit that you're using a VPN.

Is there a Debian based distribution that's hardened for use as the server OS for a Tor Hidden service?

I'm familiar with Whonix/Qubes, Kali, ParrotOS, but they all seem to be intended for use primarily as a client/desktop OS, rather than a server OS.

I want to be able to run Wordpress, with everything turned off except for the services required by Wordpress. I also want to be able to run (as a separate site) a Simple Machines Forum.

The Tor project itself seems to make use of debian. Are the automatic hardening scripts referenced here still recommended?

https://www.debian.org/doc/manuals/securing-debian-howto/ch-automatic-harden.en.html

If not, any pointers to the current best practices for securing a Tor Hidden Service server would be welcome.

Thank you!

Oh, FFS, just write at the end if there is a patch or not - and if there is one link to it. I see the value of a blogpost like this for vulnerability researchers, but 95% of the people reading that post scroll to the end for a solution.

I guess 7-zip fixed this with 16.02. as this was released at the same day as the above blogpost. Unfortunately the discussion here (https://sourceforge.net/p/sevenzip/discussion/45797/thread/3097bf8b/) also doesn't mention if this is fixed in 16.02, and the changelog as well (http://www.7-zip.org/history.txt).

TL;DR: Turns out that 95 percent of spam credit card transactions are handled by three financial companies — one in Azerbaijan, one in Denmark, and another in Nevis, West Indies. One of the scientists point out that if those three financial companies would refuse to authorize the spam transactions then they would effectively be cutting off the money that supports the entire spam enterprise.

The NYTimes wrote an informative article about this study.

This spam analysis, contrary to most other spam analysis, doesn't focus on the methods used to deliver the spam, but on the other side that most people tend to skip over — the business side. To monetize the spam email many things have to be done; Setting up domain names, proxies, hosting, and most importantly, the actual payment process and delivery. These things require several dependencies, such as the financial companies listed above. These type of dependencies are the ones the study focuses on.

> I think Mozilla should use a configuration option to enable/disable this , as leaking ssl keys based on env variable is defeating the entire purpose of SSL/TLS in a browser.

I don't (fully) disagree, but FWIW if I have the ability to set your path it's generally game over (with a few exceptions). Unless you are doing some serious privilege separation, hiding it in a browser's config somewhere is no more secure.

Maybe an unobtrusive eye icon that appears next to the SSL lock that isn't overly alarming to end-users or annoying to the point of needing a paddling?

I've heard that from other consultants too; but it is genuinely my experience. I deal mostly with the domestic side, so perhaps it's a difference of environments; maybe Microsoft focuses on business-grade threats.

In any case, I've certainly found it to be a thing. I often expose a clean virtual machine image to novel viruses I find in the wild, to test anti-virus capabilities; more often than not Defender misses them.

Edit: Nope, even in business environments it sucks. I suppose arguments that it doesn't are either anecdotal or bias.

Hi /u/fjarlq

This is the response I'll be posting to our discussion forums after responding here.

We are aware of the reported data breach at Cloudflare.

1Password data was NOT exposed as a result of this breach. This means that users of 1Password do not need to change their Master Passwords.

1Password does not rely on HTTPS to ensure that customer's 1Password data is not at risk. Our security recipe starts with AES-256 bit encryption and uses multiple layers to protect your data both at rest and in transit.

To read further about our approach to security and how we protect your 1Password data you can read our security whitepaper here: https://1password.com/files/1Password%20for%20Teams%20White%20Paper.pdf

Kyle

AgileBits

Edit: A typo of "your" to "our" :)

The README on github clearly states:

>Beta software - code review highly appreciated.

I don't know about you, but I feel this is a rather relevant piece of information that the OP has, for some bizarre reason, chosen to ignore.