How do Software Development Processes, OWASP CLASP & MS SDL, and Security Standards fit together?

As for the ISO 27000 family, it has a list of controls which are part of the management system that you have to specify if they are relevant to your scope of implementation or not. Theses controls specifies the requirements of what you should do but gives you the freedom in how do you do it. Meaning, you have the freedom to inject the requirements of the ISO 27000 into your development processes.

An example of a control is "system acceptance testing" which requires those who are conforming to the standard to have acceptance testing for changes within the current assets. I let it to you to figure where this may fit in your organization processes.

HTH


this is Brian from CertiVox.

I'll answer your questions line by line:

  The MITM scenario is not possible like it is with SQRL because the
  MITM will not have the token in their browser.

You are correct, the MITM scenario is not possible as M-Pin is a zero knowledge proof challenge response protocol. A MITM attacker would only see big numbers flying by. The worst an attacker could do is to modify the challenge or the response, in which case the authentication would fail.

  As the token is stored in the browser, this becomes the prime target for any attacker.

That's true. However, recommend to our customers to use CONTENT-SECURITY-POLICY HTTP Header since the M-Pin PinPad works without a problem with this setting turned on. This protects against almost all the possible XSS attacks known.
Offline attacks to the LocalStorage are possible only if the browser (computer) is infected with a malware. There is no existing single-device authentication solution that can solve that problem, as far as I know.
Also, we have an M-Pin Mobile app (HTML5, iOS and Android) that keeps your token in your mobile instead of your browser, as you mentioned. This enables the "Global Authenticator" mode so you can use it to remote login to desktop sessions. Adding the TEE support, the token is not just in your mobile but in secured hardware inside your mobile.

However, I think you might be missing the point of M-Pin; As you say, the target of the attacker (the individual) is now the only way of compromising their authentication credentials.

The big problem in the news cycle right now is attackers are stealing everyone's passwords out of the credential's file or password database inside large enterprise systems - out of the server, not at the client.

THAT'S THE REAL PROBLEM M-PIN SOLVES.

An M-Pin Server stores no authentication credentials, ever.
It doesn't matter if you salt and hash them 30 rounds. If you are in a regulated industry, you are obliged to tell the world you have been hacked and advise users to change their passwords. This can lead to a loss of confidence among customers. See Yahoo, eBay, Evernote, LinkedIn, etc. etc..

So if you are an enterprise or are running a mobile app or web app, implementing M-Pin as your authentication platform eliminates that threat vector and that risk of reputation damage.

  The PIN entry in the browser is susceptible to shoulder surfing, although useless without the browser token.

Exactly. Compared to password only, it's obviously eliminates that risk.

So you are right, shoulder surfing is useless without the token as a means of attack.

Also, in the new 3.4 version (that is in testing stage), we have implemented keyboard input support that will help you to type the PIN number without worrying that someone will see it on your monitor.

  A phishing attack could retrieve the PIN, again useless without the browser token.

That's actually one of M-Pin's powerful strengths. Any spoof website can prompt a user to enter some private information. In M-Pin's case that information can only be the PIN. That PIN is completely useless without the token and without the M-Pin ID (which is different for each registered browser). Also, the spoof site cannot know the user identity - it is shown in the PinPad when asking for PIN number.

In comparison to LastPass, they are trying to help manage passwords. CertiVox M-Pin is meant to eliminate them entirely. Our 'M-Pin Core' value proposition isn't aimed at the individual (like LastPass), ours is aimed at developers and / or CISOs / security professionals who are implementing large, Internet scale applications and want to eliminate the risks that come from using password based authentication.

Our 'M-Pin SSO' server is aimed at Enterprises who want to federate M-Pin Strong Authentication to SAML / RADIUS enabled applications internally or externally.

Hope that helps.

Cheers,
Brian


So typically is is exactly the sort of problem that OAuth was designed to avoid, not create.

You, as a resource provider, have created a system that you have decided to protect with OAuth, and a WordPress plugin that acts as a client to your system.

Bob, who has a WordPress site and who would like to use your system, installs the plugin into his WordPress site.  Then, Bob visits your system, informs it that he would like to use it and requests access.   The system then gives him a new, unique client secret.   He adds the client secret to the plugin configuration on his site, and he can now connect to your service using credentials that are unique to him.

This way, every site that has installed the plugin is uniquely identifiable, and the client secret need never be known to anyone other than the single WordPress site that owns it.


What are the disadvantages of Google Safe Browsing?

While Google Safebrowsing is today mostly an offline check against some local database they still require that the browser queries google directly before presenting the phishing warning to the user. This is done to reduce the chance of false positives because the online check has the most up-to-date information. But it still might be considered a privacy problem in some environments.

Apart from that relying only on Google Safebrowsing might not be sufficient. From reading the paper it looks like that they get their input mainly from links to gmail users and a few information reported by the users. This means that the input is biased in a way that an attacker has a good chance of late detection if not targeting gmail users. Thus it might be useful to additionally get other sources which don't have this but another bias.

Also according to their paper they target a recall of 90% to keep the false positive rate at a low 0.1%. This means that one in 10 phishing pages will not be classified as such. Increasing the recall would increase the false positive rate so that they classify too much safe pages as malicious. But there are environments where one rather has a higher recall even if the false positive rate gets larger, i.e. better safe than sorry. Note that these are not arguments against using Google Safebrowsing at all but only arguments against relying too much only on Google Safebrowsing.


Impact of Quantum Computers, other than new algorithms

The thing with quantum computing is that we don't know yet.

A few thoughts:

If we do ever achieve a true quantum computer, it is likely to be significantly faster than classical computers, when speed is measured in a similar way.
If it is going to be faster, we don't know how much faster until we build one. Current prototypes are far from complete, and even "landmark" demonstrations of the technology are questionable.
Quantum computing offers a potential short-cut for certain operations, in that it can use various forms of quantum mechanics trickery to produce previously "unknowable" results out of input values.
However, quantum results are probabilistic; it's not actually as concrete as saying "it's fast", because you have to make it fast and right. Not easy to do.
If you can find a quantum short-cut to a problem, and build a quantum computer, and implement that short-cut within the computer, and find a way to get it the result with p>0.5, you're on track.
The big "potential" is for Shor's algorithm, which might reduce the computational complexity of semiprime factoring to a low enough class for us to feasibly factor very large numbers in a shorter time than with classical algorithms.
It's a big "if". We don't know if it'll actually reduce computational complexity, nor do we know if an efficient implementation is possible. Even if we can achieve both of those, we don't know how much of a reduction in complexity we will get. The hope is that we'll get  O((log N)3), but we don't actually know if we can ever reach that in a real implementation. And even if that is the case, it still requires massive amount of computation, which brings us back to the second point I made: we don't know how fast quantum computers can really be.
Even we break semiprime factoring problems like RSA, quantum crypto brings new problems that can't be solved easily, which means we'll still have a new way to keep things secure.


With a very large number of GUIDs, can one predict the previous and subsequent GUIDs that will be generated?

It would depend on the implementation of the GUID/UUID library. Determining the internal state of a pseudo-random number generator varies widely based on which one you're talking about.

Many GUID/UUID libraries utilize a proper cryptographically strong pseudo-random number generator (CSPRNG) when generating v4 UUIDs. In those specific cases, when implemented correctly, I would argue that you would not be able to infer anything about the internal state.


What else can be used instead of an API Key to protect resources in a REST API as is implied by OWASP?

What are the alternatives to protect resources via a REST API that
they are indicating towards?

They are indicating to implement further measures in addition to API keys, not to look for alternatives.
The other measures are in the Table of the content on right of the same page.


About windows services and service control Manager

TL;TR

This privilege can be used to create and run processes under another user (including SYSTEM) given proper access tokens for that user.

SeTcbPrivilege

Windows Services are programs that run in the background to perform necessary operations for the operating system to function.  When you say, "when an account other than Local System is used to run service, the SCM automatically grants the account certain security privileges", it should be noted that services can only be started by the following three Service User Accounts:

System
Network Service
Local Service

This means that to run a Windows Service you must already have the privileges of one of those three "users".  System is essentially an Administrator, and the other two are fairly high level user groups.

From the MSDN:

  C++ constant: SE_TCB_NAME string: SeTcbPrivilege

  Scripting short name: Tcb

  Required to act as part of the operating system. The holder is part of the trusted computer base.

Services are extensions of the operating system, so it is not really surprising that the SCM gives this privilege by default to services.  The Trusted Computer Base Privilege allows access to hardware device drivers and/or software components that are considered to be the "base" of the computer's (i.e. operating system) security.

Another exerpt from Microsoft:

  Allows a process to authenticate like a user and thus gain access to
  the same resources as a user. Only low-level authentication services
  should require this privilege.

In other words this allows a process to impersonate a user.  This does mean that you can run things as SYSTEM.  I know impersonate sounds terrible, but there is a mechanism built-in to Windows to "impersonate users".  This is how Run as Administrator performs its duties.  However, to grant this privilege you must provide Administrator credentials in some way.  If malware is already to the point of being able to assign itself this permission/privilege, then you're already in a lot of trouble.

Access Tokens

Access Tokens are Windows way of allowing threads/processes/users to access certain portions of the operating system.  Security Tokens are passed to almost every lower level function used in Windows.  Because services are generally running at higher privileges, they are granted privileges for creating access tokens.  When interacting with the desktop, they're probably interacting with user level objects.  They will need to access, modify, and create tokens for this.

All of this behavior isn't out of the ordinary.  Services are low level programs with high system privileges.  The privileges that you mention are all standard privileges for services to have.  A lot of malware will try to impersonate, or use services to gain access to the system because of this.  See my answer here for a bit more information on that topic.


A typcial example of non-trivial buffer handling is the parsing of binary files (or network packets) that can contain arbitrary-length strings.
(Is there any ASN.1 parser that didn't have buffer overflows bugs at some time?)

For example, consider the format of textual data chunks in PNG files:

  The keyword and text string are separated by a zero byte (null character). Neither the keyword nor the text string may contain a null character. The text string is not null-terminated (the length of the chunk defines the ending).

So the homework could be a tool that outputs all textual data in a PNG file.

Even plain text can be not quite trivial if you need to handle arbitrarily long lines, and thus need to resize a buffer dynamically.
For example:

  Implement tail without parameters.
  (Lines can be longer than any static buffer. The entire file can be larger than available memory.)


What is the name of this type of attack using transparent encryption?

Well, that sounds like an Advanced Persistent Threat (APT), but specifically, this would count as Ransomware if you try to sell the key back to the victim, Data Destruction if you don't. WannaCry was an example of both, where the malefactors didn't really keep the keys and anyone who paid was doubly screwed.


Can password strength be enforced with PAKE protocols?

No, you can't enforce a client-side policy via technical means.  As you mention, any limits you bake into an implementation could be bypassed by someone using a modified client.  But that presumes you have at least some users intent on using specially weakened clients, which seems unusual.  What reasons would your users have for avoiding your official client?

While you can't stop someone from doing an end-run around your system, you could use the policy stick to require people to use only approved clients.  You could audit their systems to make sure they have the official client installed.  You could use technical means such as code signing, application white listing, virus scanning, and/or file integrity monitoring to help ensure they don't install rogue clients.  If you find they're using an external website to do things like generate and exchange keys, add the website to your firewall's blacklist.  Make doing the wrong thing harder.

Perhaps you could require them to manage those specific passwords only from a bastion host running behind a firewall. The bastion hosts would be locked down and used only for those particular security operations, then any exchanged passwords would be copied back out to the client.  I'm not saying it's the most secure choice, only that it's potentially another way of controlling the users' behavior.  Similarly, you could provide a wrapper service in front of the PAKE system and use the wrapper to test for password conformity.  Of course, these approaches leave you with a bastion host or wrapper service that you have to secure, manage, and inspect, which could be a bigger and more expensive headache.

Sometimes all you can do is state your policy (and the scary penalties for non-compliance) and expect people to follow it.  Consider a policy-only approach until it's alleged (or proven) that users are circumventing it.


Is it OK to use Metasploit against sites like hackthissite.org?

It all depends on the Terms of Service for the hackable sites. They will tell you what they allow.

For Metasploit, they produce Metasploitable, which is a VM to use as target practice.


How credible are the rumors that the NSA has compromised IPSec?

There was definitely a backdoor into the IPSec implementation of Juniper appliances. This backdoor was caused by a weak random generator designed for such backdoors.  It is known that this random generator was designed by the NSA. But it is not publicly known who deliberately put this backdoored random generator into the IPSec implementation of Juniper. For more information see for example Researchers Solve Juniper Backdoor Mystery; Signs Point to NSA.
That does not mean that IPSec itself is compromised though, but only this specific implementation. IPSec itself is an open protocol with many implementations. While a cryptographically secure random generator is required for IPSec it is not part of the protocol itself, which also means that the specific backdoored random generator was not part of the IPSec specification. Nothing shows inherent security issues of the IPSec protocol itself.


Is PHP loadXML vulnerable to XXE attack (and to other attacks)? Is there a list of vulnerable functions?

Is the loadXML function vulnerable to XXE attack? Namely, if the XML contains external entities, will they be interpreted?

By default, no.

External Entities are not parsed without LIBXML_NOENT being set. If libxml_disable_entity_loader is set to true, not even LIBXML_NOENT will allow XXE.

  Is this function vulnerable to other XML based attacks? e.g., the Billion Laughs DoS attack?

No, billion laughts will be caught with default settings:

DOMDocument::loadXML(): Detected an entity reference loop in Entity

What will not be caught is quadratic blowup. Note that the entities need to actually be substituted, which is either done via the rather poorly named LIBXML_NOENT or by simply accessing the node (eg via  textContent).


The most famous has got to be the Samy worm:

  Samy (also known as JS.Spacehero) is a XSS worm that was designed to
  propagate across the MySpace social-networking site written by Samy
  Kamkar. Within just 20 hours of its October 4, 2005 release, over
  one million users had run the payload making Samy the fastest
  spreading virus of all time.

  The worm itself was relatively harmless, it carried a payload that
  would display the string "but most of all, samy is my hero" on a
  victim's MySpace profile page. When a user viewed that profile page,
  the payload would then be replicated and planted on their own profile
  page continuing the distribution of the worm. MySpace has since
  secured its site against the vulnerability, however certain MySpace
  profiles still display evidence of the worm to this day.

There was also xssed which keeps a record of real exploits, however it appears to no longer be maintained.


A script can simulate keystrokes/mouse clicks on Windows.  I believe the UAC prompt is protected by the OS making automating clicking it a more difficult task.  (I'm not a windows user; but its straightforward to simulate mouse clicks/movement in windows).  Apparently the UAC screen is run as the System user (a user with more permissions than an administrator, but not quite the kernel) so unless you were able to write and execute a script as the System user you would not be able to bypass the UAC clicks.

But in general, having a GUI login with a button doesn't make your login screen any more difficult to break.  Any reasonable attacker will examine how your program is checking the password, extract out the saved hash from memory and write some massively parallel GPU code to brute force it.  (Unless its done over the network and then they'd stop using your GUI and do the requests directly).  But even if somehow constrained to simulating keystrokes and mouse movements/clicks its still trivial to do.


Avoiding Replay Attacks on Lightweight Channel

Only suggestion I can give is to always check for acks, and make them include the counter, otherwise an attacker could selectively drop (or delay, but not reorder) packets.

Also, you need to think of a way to keep track of every device counter's value.


Clarification on the -h Flag for Makecert.exe

I did some further investigation and realized that this constraint is taken into account at the time of resolving the certificate chain of trust, not at the time of creating a new link. From  RFC 5280:

  The pathLenConstraint field [...]. In this case, it gives the
  maximum number of non-self-issued intermediate certificates that may
  follow this certificate in a valid certification path. [...] A pathLenConstraint
  of zero indicates that no non-self-issued intermediate CA certificates may
  follow in a valid certification path. [...] Where pathLenConstraint does
  not appear, no limit is imposed.

See also TechNet - Understanding Constraints.


openVPN extremely slow, PPTP/IPsec/etc. as fast as expected

Are you using TCP or UDP?  Usually with OpenVPN you get much better bandwidth performance over the existing physical connections because there is lower overhead and OpenVPN can correct most issues anyway.  Unless you were experiencing major connectivity issues then use UDP to speed things up.
It should look like: proto udp as a line in your server and client configs.


Is there a technical survey report related to BitLocker and TPM?

I don't know of independent security audits, but your questions 1-4 are relatively easily answered from official sources. I would have no reason to distrust the official sources on those matters. The quick answers are:

Yes, the TPM is tamper-proof hardware which stores and protects your key.
This is manufacturer dependent but most use an exponential backoff, e.g. 1st bad attempt locks for 1 min, then 2 mins, 4 mins, 8 mins, etc. more here
Yes, the recovery key is your key, so you can recover in case the TPM fails. more here
TPM 2.0 supports new algorithms and other improvements. I don't think the changes are fundamental. more here

Your question number 5 is much more interesting! TrueCrypt and BitLocker have very different safety profiles, and this is where we do have to question how much we can trust the TPM manufacturers.

TrueCrypt is as secure as your passphrase. If you use a weak passphrase, your encryption can be broken by brute force. If you use a strong passphrase then as far as anyone can tell (at least anyone who will speak in public) then your data is safe. There are a few caveats on this (cold boot, evil maid) but in the case that your computer is stolen while turned off, the data is very well secured.
BitLocker is as secure as your TPM. If you use a weak password, your data is still safe because the TPM enforces a lockout. However, if your TPM can be compromised then your data is at risk. It may be possible to compromise the TPM by techniques like shaving it open layer by layer and using a scanning-tunnelling electron microscope. However, a much more practical concern is law enforcement back doors. The TPM manufacturers probably have a back door they can use to get in, and they would likely reveal this to law enforcement in certain circumstances.

I can see why law enforcement would hate TrueCrypt! BitLocker gives adequate protection for commercial uses. And TrueCrypt is ideal for criminals.

Even if someone did an independent security audit, it wouldn't normally be possible to determine whether there was a manufacturer back door.


Sharing RSA Public Key for decrypting JWT amongst Load Balanced servers

If you don't want to share keys AND you use asymmetric keys then you can key each server separately and have each server set a different iss (issuer) claim. Then the recipient of the JWT can "look up" the appropriate public key based on the iss claim. Our lookup was basically a config file that mapped the iss value to a file system location of the public key.

If you need to share secret keys then I'd look at key distribution techniques. A lot will depend on how much effort you want to put in.


Because encrypted files are not compressible, the most useful place to put encryption is in a compression program; that way you can compress the content and then encrypt it.

Modern tools generally use well-vetted algorithms such as AES. Avoid classic ZIP encryption because it uses a bad algorithm. 7-zip is a great tool because it's FOSS, cross-platform, and very widely recognized. It uses 256-bit AES, which is currently "unbreakable" enough that a brute-force attack is the most efficient attack algorithm.

7-zip, including encryption, can be integrated into GNOME's built-in archive manager (and may be installed already!), making the whole process largely transparent. The p7zip command handles command-line access. The file extension is .7z


SSL on domain will affect un-secured sub-domain

SSL and certificates don't actually know what a "domain" is.

When a client (e.g. Web browser, or an application which calls a Web service) connects to a SSL server, it will look at the server's certificate (as sent by the server itself) and will accept it only if the certificate contains the intended server name. If the client wants to talk to https://www.example.com/foo.html, then the client will require that the certificate contains www.example.com.

A "domain certificate" is a fancy name for a certificate which contains the name *.example.com, also known as wildcard certificate. The client will consider it as good enough if the intended server name is anything.example.com for any value of anything.

No part the whole thing has any awareness of the "domain" as a whole. Server foo.example.com will not mind that bar.example.com uses or does not use SSL, regardless of any certificate contents; and any client connecting to foo.example.com will be interested only in what it finds in the certificate sent back by that server; and it will be interested only in whether foo.example.com appears as a name in the certificate, as such or under the guise of a wildcard name.


Is it necessary to enable SSL for client and server that run in same machine?

No. Its not neccessary at all. First, because packet capturing/modifying requires administrator rights. But second, with administrator rights, you are aswell able to modify other processes that you don't own, thus can modify/read the RAM for the client or server before the data is encrypted by the SSL layer, or after its decrypted by the SSL layer.

Thus SSL will neither contribute or compromise anything security-wise, it will have zero effect. It may have effect on performance.

Also, since the private key for the certificate needs to be stored on the very same machine, the attacker could steal that key and use it to read/modify the local traffic.

So SSL will just only make debugging harder and add nothing.


How to protect a website from DDoS without a CDN?

While this won't protect from particularly heavy DoS attacks, you can use a VPS service that provides protection against such attacks as part of the regular package. OVH is one such company that provides attack mitigation to all their VPSes. You can either host your site on their servers directly, or run a GRE tunnel through it, giving you the DoS-resistance of the VPS while still allowing you to have the flexibility of running your site on whatever hardware you choose. There are also services that are resellers of OVH, such as one service I used to use which has served me well.

Note that OVH is based in France, so French law applies to any traffic going through it. One other note is that OVH tends to disable TLS handshakes under particularly severe DoS conditions, which can be problematic for sites that exclusively use TLS (e.g. sites that have HSTS). And of course, it is not the only managed VPS host which provides low-cost DoS protection. There are many like it.

I am not affiliated with either Internetz.me or OVH.


Why did Google sign every auxiliary app inside "Google Chrome.app" (OS X version) except for one?

We can't sign the app_mode_loader bundle because it's altered at runtime
  as new app mode loader stubs are created. We can sign just the
  executable. The resulting executable won't validate in its bundle
  normally, and spctl won't like it, but it can be verified with
  --ignore-resources, or in isolation from its bundle.

https://codereview.chromium.org/1486863003


What stops an SSH server from MITMing logins?

As noted in the accepted answer the signature is determined using the private key over various pieces of data:

  The value of 'signature' is a signature by the corresponding private key over the following data, in the following order:

 string    session identifier
 byte      SSH_MSG_USERAUTH_REQUEST
 string    user name
 string    service name
 string    "publickey"
 boolean   TRUE
 string    public key algorithm name
 string    public key to be used for authentication

The signature is over a "session identifier" which is unique to that connection.

As per RFC 4253:

  The exchange hash H from the first key exchange is    additionally used
  as the session identifier, which is a unique    identifier for this
  connection.  It is used by authentication methods    as a part of the
  data that is signed as a proof of possession of a    private key.

This session identifier will be unique to the client --> server connection so the same signature would not be able to be used on the server --> server connection, mitigating any replay attack against a second SSH server.


Is it possible that the same VISA debit card numbers could be issued to different people by different banks?

[edited]

whilst a card issuer may choose to reuse PAN (long number) to identity a card, a  PAN cannot normally be reissued by a different card issuer. The reason for this is because the BIN (first 6 digits) is issued uniquely to a card issuer.

There is one exception:  If card issuer is bought by another card issuer (e.g. bank 1 buys bank 2) then card number may be reissued under the new name of the card issuing organisation - but really this is an edge condition and in the spirit of the question the answer is largely no

Note:  In the UK, Clydesdale reissued mastercard PANs, but eventually stopped after obvious problems occurred.  see: http://www.theguardian.com/money/2003/may/10/creditcards.debt1


Does changing an image src attribute to call a PHP function on my server to retrieve an image from another server eliminate CORS policy issues?

Using your PHP server to proxy the request to the S3 server will indeed help you to solve that CORS issue, since your webpage and the image will be on the same origin.


No not really.

You either get a static or dynamic IP.  Obviously static isn't want you want.  However, dynamic IP assign by dhcp are not random.  Each IP in has purchase 1 or more ranges of IP addresses.  Typically handed out by region.

There is a dhcp leases, and when the lease expires it tries to get a new IP, however 99% of the time it just gives you the same one back.

When you disconnect, and later reconnect you get an IP from the pool.  The range of IP is limited, and way to limited to be called random.  Plus some ISP may log these devices.

Disposes, as in never to be re-used by anyone, nope never there are just to few IPv4 left to ever allow an IP to go unused.

Disposed of, as in you never use it again, again IPv4 is too small to allow this.  Chances are in you will eventually get the same IP back again.

Now, IPv6 has 2^128 address vs 2^32.  You might be able to buy blocks of IPv6 and after you used them once resell them and get a different block.  This however, is a lot of work, and records are kept so it wouldn't get you any anonymity.

Also 90% of the internet is IPv4 so if you have an IPv6 nobody on IPv4 can easily communicate with you.  They could get a VPN, but your typically user isn't going to do that just to visit your site.


Snort report - 1000+ alerts in 1 minute from port 5060

This is probably a bad configured scanning(attempting) of the communications compagny in Portugal. Since the ip-range might be the same as yours. Or they misconfigured some other connection ip's.

Nevertheless i don't think this commucation compagny is trying to hack you. Unless you have valuable information ;).

Greets

Samuel

More info:

inetnum:        87.196.128.0 - 87.196.255.255
netname:        NOS
descr:          NOS COMUNICACOES S.A.
country:        PT
admin-c:        NVSA1-RIPE
tech-c:         NVST1-RIPE
status:         ASSIGNED PA
mnt-by:         IP-MNT
source:         RIPE # Filtered

Wikipedia Source Nos communications:

  http://en.wikipedia.org/wiki/NOS_Comunica%C3%A7%C3%B5es


How to cycle OAuth2 client secrets without downtime

This is something I've been wondering about as well. I don't think a solution exists right now, but I believe new systems can be designed to do this without downtime by leveraging Trust Assertions for Certificate Keys (TACK) to do so.

When the client decides to cycle to a new secret we need a mechanism to ensure the server can trust the new secret. In other words, the new secret needs to be signed (i.e. a TACK) by the client. That's what the TACK specification covers, and details a lifecycle for creating a new TACK, revoking, etc. - most importantly it covers the handling of overlapping TACKs so you don't have downtime.


Is it possible to hack your WiFi and then use your computer?

Possible, yes. Likely, no. To be able to 'use' your computer remotely, they would need to have some kind of shell access, use that to open a browser and check their email. Not something you would expect a hacker to do.

  Is it possible to see if someone had access to your WiFi?

Yes, depending on your router, there should be some kind of log, showing which mac addresses have been connected. They would have to be in range of your WiFi to do this.

  Is this easy to do?

Hacking WiFi is pretty easy and straight forward, if you use a WEP password, it's very easy, using a WPA makes it a bit harder: It will take longer, but it's not impossible.

Gaining access to your computer is a bit harder; they would have to make you click a link to gain access, or use another method, requiring more knowledge.

I really don't think that this is the case here, though. Sounds like someone had physical access to your computer and forgot to log out.


Is it dangerous to have unused Windows 10 Defender Firewall rules active?

If the rules are specific to applications, no not really. Where exploitation can happen is when something listens on that port and the rule allows it. Ergo if nothing is listening, nothing can happen. So those games being uninstalled doesn't affect your security in a negative way if the rules are tied to the specific application(s) because nothing is listening on that port with that process identification pattern to allow action through the Windows Firewall.

For that rule to be exploited you'd already have to be so completely taken over that nothing could stop the virus/attacker at that point.

If the rule is NOT tied to a specific application, yes, it could be exploited if you download a virus. However for something to exploit the rule, the program would find that open port, listen on the port, and report home. Usually that behavior triggers antivirus. However at that point you've already gotten a virus that is attempting to find open unsecured ports it can listen with. Which means you already have a virus. Which is bad for other reasons.

It is however perfectly safe to delete those rules if that software is no longer around. It just means if you ever reinstall it it will ask for the permission again.


What things can the other person see about my phone when I pair it using bluetooth?

All information that is available through your phones supported profiles. For modern smart phones this will most likely include:

SIM and device contacts
SMS messages
Your phone uinique bluetooth MAC

If your phone supports advanced bluetooth profiles such as OBEX (all Android phones that I owned so far did not support this out of the box)

Read/Write/Delete files inside of a defined root directory

Many more bluetooth profiles may be implemented on your device, a defintive answer will be totally specific to your model.


Does a fake SSH server have any purpose security-wise?

The reasons to have such fake SSH servers are multiple. They include such as:

determining whether you’re under attack
knowing the users and passwords guessed (which can display the intel the attacker has)
to see attacker’s actions of interest
to see attempts of exploitation of the server (might disclose 0days or backdoors)
to study how the attacker tries to approach the system
and so on.
test client software, including audit / testing / attack tools during development (thanks to Mołot)

You should consider NOT putting up a fake SSH server on your system if you have anything of value in the server, since the fake server might be prone to vulnerabilities as well - one closed port is better than one open service.


How does full memory encryption in newer processes protect against DMA attacks?

How does memory encryption impact DMA attacks?
Full-memory encryption is not designed to protect against DMA attacks. That is what an IOMMU is for. The IOMMU is configured using a type of ACPI table for DMA Remapping, or DMAR. This table contains a list of regions used by each DMA-capable device connected to the PCH. The IOMMU will then restrict memory access to those regions and those regions only:

How do devices like GPUs, which rely on DMA, even work in the presence of full-memory encryption?

There are two techniques to support DMA. The first is to exploit the fact that memory accesses over PCIe still go over the PCH, meaning that the chipset has the opportunity to transparently encrypt and decrypt the DMA buffers. The other technique is simply to mark the pages used for DMA as unencrypted. The latter technique prevents DMA attacks, but it is likely that the former is implemented instead. The latter technique is more common for experimental software-based memory encryption such as vCage and HyperCrypt. This is not an issue at all, as I explain later.
According to the TME link you provided, a single exclusion range is supported where encryption is not supplied. This range is designed for things such as the BIOS (which has components loaded very low in the address range). Since it specifies that only a single range is supported, this means it cannot be used for DMA buffers as they are spread out among multiple ranges.
Also, you should be comparing TME with TSME, not SME. Regular SME only encrypts individual pages. TSME, on the other hand, behaves more like TME by transparently encrypting almost all system memory, making it unnecessary for software to explicitly support the feature.

Does using such a device spoil the benefits of full-memory encryption and thus safety without physical security?

Not at all! When memory encryption is in place, the data will be transparently decrypted and sent over the PCIe bus when the device requests it. This is actually not that different from memory scrambling, a technique to reduce di/dt on DRAM chips by encrypting memory with an algorithm called an LFSR. This algorithm is very weak, so it is not used for confidentiality, only to improve the reliability of hardware. TME and SME just takes this to another level, using hardware-accelerated encryption with a real, strong cipher instead of the weak LFSR algorithm.
As a bus gets faster and faster, successive bursts of 1s or 0s become very stressful on the device. This can cause severe, rowhammer-like interference (a single 0 in the burst of a million 1s will not be very happy). It can also cause power surges, as every capacitor that is charged needs to be recharged every 64ms. Memory scrambling prevents this from being an issue by ensuring that, on average, each bit being stored in physical DRAM capacitors will have an equal chance of being a 1 or 0, regardless of the logical data that is actually being stored. This is not unique to DRAM in any way and is employed by a wide range of high-speed buses.

Note conventional on-mainboard TPMs were susceptible to physical TPM reset attacks [...]

Once you have unrestricted physical access to a machine, maintaining integrity becomes very, very hard. An attacker can simply attach a JTAG probe and control the processor like a puppet.
How do DMA attacks and DMA work?
So, what happens if you plug in a rogue PCIe device? First, the computer will configure the device. If a driver requests it (which is usually the case if the PCIe device pretends it is, say, a WiFi card), it will be given bus master, which allows it to mount a DMA attack (which is also often called evil busmastering for this reason). Each PCI or PCIe device is part of what's called an IOMMU group. Without ACS at least (see section 4.3 in the Intel document), each IOMMU group has its own dedicated memory range and any device in that group will have the same restrictions applied to it.
Taken from a question I asked, you may look at your kernel log and see something like this:
DMAR: Setting identity map for device 0000:00:1d.0 [0xa95dc000 - 0xa95e8fff]
...
iommu: Adding device 0000:00:1d.0 to group 11

This means that any device in group 11, including 0000:00:1d.0, will only be able to read physical memory from address 0xa95dc000 to 0xa95e8fff. The kernel is configured to look at that region of memory for any DMA buffers that needs to be shared between it and the device.
I describe how DMA works and why it is needed on another answer. The relevant part:

It might be useful to understand why DMA exists and how it works. When DMA is supported, a dedicated region of memory is set up and the controller (whether the ICH or PCMCIA) directly writes the data read over IDE to that memory region (using the DMA-based UDMA or MDMA protocols). From the CPU's perspective, it issues a command to read data and then can go do its own thing, knowing it will be asynchronously alerted with an interrupt as soon as the process has been finished, with the requested data waiting right there in memory for it. Likewise if it wants to write over IDE, it can simply populate that memory region with the desired data and tell the controller to take it. Just like when reading data, the CPU is free to go off and do its own thing without needing to micromanage the transfers. It will be alerted with an interrupt as soon as the task is completed. This is why transferring data to and from devices (GPUs, NICs, storage devices using IDE or SATA, etc) can be made so fast and require so little CPU to perform.

How secure is an IOMMU?
There are some ways to bypass an IOMMU or reduce its effectiveness. For example, older IOMMUs on Intel using VT-d1 which lack x2apic and interrupt remapping are vulnerable, and Address Translation Services, or ATS, can bypass restrictions. A properly implemented IOMMU will, however, completely prevent a DMA attack from reading arbitrary system memory. This is what you will be relying on for protection from DMA attacks, not memory encryption. Memory encryption is designed to protect from passive bus sniffing and from cold boot attacks.
Memory management on x86 is incredibly complex, with their specifications including thousands of pages of dense technical information. All this complexity can have strange security implications, such as allowing a GPU to reconfigure an IOMMU to reduce security. While in theory, an IOMMU will prevent a device from accessing illegal memory ranges, there is no end to the complexity that underlies this technology and the potential vulnerabilities that come with this.
If this wasn't bad enough, DMAR tables, which an IOMMU relies on to restrict devices, are managed by a computer's OEM. It's not uncommon that a computer ships with a broken DMAR table, forcing the computer to completely disable DMA attack protection. For this reason, some operating systems (such as Debian GNU/Linux) actually have the IOMMU disabled by default!


How do I clearly distinguish between groups of formal and informal models?

Information flow, state machines and non-interference are more like 'theoretical concepts'.

You can say that the Bell LaPadula model is an implementation of an information flow concept and BIBA is a model build on a state machine concept.

I don't know if this helps.


Which verification method should I choose: SMS or call?

Call is safer, for reading your sms you only need a simple program whereas for monitoring your calls, you need an actual person, thereby increasing the effort needed by a lot.

Reading sms is something you can do on as many phones as you want whereas listening to that many calls at the same time is impossible (unless you're the NSA I guess). Even if you found a way to just record the call and then send it, the programming effort here is much greater and you also need a lot more processing power and bandwidth, once more lowering the chance that you're gonna be caught by it.

edit: I just want to add, of course the other guys talking about your threat model are right. If you leave your phone lying around and people can just take it and listen to the code, of course sms would be better. But then again, if you don't even have a lock on it, it wouldn't matter.

As you can see, yeah, it depends, but if you do have a passcode and you're not leaving your phone lying around, calls are better.


How to hide Windows Media Services server version header

The Windows Media Server is high-bandwidth, low CPU media server. So it can stream 20GBps with 10% CPU usage on 2008 produced server.

Because of that it's quite inefficient to put anything in front of it like proxy, and then, it's not really HTTP server, it has only HTTP headers.

There are no web browsers actually using it (except for playlists), it is used by specialized players on various devices, including Windows Media Player.

I haven't heard about method of disabling that string, and I think Nessus doesn't complain either if I remember correctly.


Bypassing Windows 10 password with Utilman.exe trick - fixed?

So I'm wondering if this Windows vulnerabilities were fixed?

It's good to know that this is not a vulnerability, even though it ostensibly is. Microsoft TechNet publishes the "Ten Immutable Laws of Security" and in this case, laws two and three apply, which state respectively:

Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore.
Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.

Law #3 applies to gaining access to the command prompt, and Law #2 applies after you've done #3 (replacing sethc.exe with cmd.exe).

As for whether sethc.exe, utilman.exe, osk.exe, ..., and the Image File Execution Options trick can be used in Windows 10, I can access all four of these options in both builds 17063.1000 (Insider Preview) and 16299.125 (Creator's Update). While I am not 100% sure of the other versions, I believe there is no difference in the first version of Windows 10.
It is possible that you accessed the wrong drive. Often times when booting into the installation environment, the hard disks are assigned a different letter (I've normally gotten D:).


Pass the hash to identify as domain user instead of being stuck as NT Authority\System

The reason this is happening to you is because of the way psexec works. Psexec uses your credentials to create a service on the remote machine using dcerpc's service control manager. Services by default will use the system principal as their process token.
Now to the matter at hand - how do I get back my administrator rights, assuming you don't have a hash, tgt or password - you can't.
Why?

Credentials are by design not passed on the wire, only a challenge response hash (ntlm) of a tgs is passed between hosts, meaning that even if the host accepts your credentials you won't be able to use them from that host to other hosts.
If you only require local access with the admin user you can use wmi as your remote execution method.(but even that is a network logon which doesn't allow forwarding credentials to other hosts)


Need to trace the owner of a MAC-address connecting to my router

A simple solution if the MAC address is not being spoofed, add the MAC address to the Router's blacklist.

If it is being spoofed, then you should change the network name (SSID) on the router, change the password etc. and make the network hidden (e.g. turn off broadcast SSID).

Once it is hidden you would need to be able to connect to it by entering it manually in your wifi setup.


Forcing EAP-TLS 1.2 authentication with FreeRadius and OpenSSL

At most a partial answer but too much for reasonable comments.

ECDHE does NOT require TLS1.2, only 1.0 as I said in the comment. I used it often in openssl 1.0.0 which doesn't even implement 1.2, and still test fine by specifying 1.0 in current openssl or using non-bleeding java (j7 can do 1.1 and 1.2 but defaults to 1.0). In fact openssl actually supports ECDHE (and other ECC features) on SSL3, which the RFC does not call for so it works for openssl-to-openssl but not necessarily with other implementations; but there is no good reason to use that when more robust TLS1.0 is available. The only cipher features that require TLS1.2 are AEAD (in openssl GCM) and SHA2. If your app(s) is requiring say ECDHE-ECDSA-AES128-SHA256 but not ECDHE-ECDSA-AES128-SHA, that would fail on 1.0. What ciphers are offered in your ClientHello? Some googling finds http://w1.fi/wpa_supplicant/devel/tls__openssl_8c.html which suggests at least the possibility to specify the list of ciphers as of 2012, but I didn't see any doc on if and how a user controls this.

Which reminds me: are you looking at the correct version in ClientHello? There are two versions: record layer and handshake. OpenSSL uses "Record Layer" version 0301 (TLS1.0) for ClientHello to offer a range of protocols, to ensure a peer that implements only an older version will "negotiate down" correctly; it is the version under "Handshake Protocol: Client Hello" that specifies the offered version. And you still didn't say what the response is in Wireshark: is there an alert and with what code, or something else, or what?

That said, you may want TLS1.2 for its other benefits or just futureproofing. Among the protocols that openssl implements, the ones it offers for a client or accepts for a server are controlled by calls the respective client or server application code makes. The starting point for an SSL_CTX are "methods" for a specific protocol like SSLv3_*method or TLSv1_2_*method, or the "generic" SSLv23_*method (a legacy name that is now misleading and may be changed in a future openssl version) followed by SSL_[CTX_]set_options with (among others) SSL_OP_NO_(protocol) bits.

Assuming per above your ClientHello is record version 0301 AND handshake version 0301, meaning TLS1.0 only, it might well be that wpa_supplicant was coded to do specifically TLSv1_*method. This could have made sense ten years ago when TLS1(.0) was the best available, and there were issues with SSLv2 being attackable and SSLv3 being unacceptable for USgovt use (though then actually safe) so someone might reasonably have felt "we'll protect those @#? users from making a mistake and doing something insecure by forcing TLS1". If so, the passage of time has made this thinking wrong.


OpenVPN: Storage location and creation of keys/certificates?

Like this:

CA machine: ca.crt, ca.key
Server: ca.crt, server.crt, server.key
Clients: client.crt, client.key, ca.crt

Notably, ca.key does NOT go on the server. If the server is compromised, then the attacker won't get ca.key.

With easy-rsa you generate the key and certicate on the CA machine, and send them to the client. Technically you don't need to keep them, although it's a good idea to keep the certificates in case you later need to revoke them. In that case, keep them on the CA machine.


No, there are two reasons while coupling SSL with "ElGamal encryption" won't make your data "more secure".

The first reason is that among the two known attacks that you link to, one has been fixed for long (it is a variant of Bleichenbacher's attack from 1998, using a padding oracle; it is fixed by making the SSL server not reporting padding errors at the RSA stage), and the other is generic upon the use of compression on a data stream which contains secret data and attacker-chosen data at the same time (as long as encryption leaks information on the encrypted data length, compression will be an aggravating issue, regardless of the encryption algorithm, even if several are piled on each other). Putting some other algorithm in the mix would not offer any significant advantage for either.

The second reason is that your suggestion does not make sense. ElGamal is an asymmetric encryption algorithm (named after its inventor) which, by nature, encrypts only a single short element (no more than a few hundred bytes). If you were cascade SSL with some other encryption system, that other encryption system would be a symmetric encryption algorithm (e.g. the AES), any asymmetric algorithm like ElGamal being used only for an initial key exchange... just like SSL does with RSA or Diffie-Hellman.

Indeed, when you write this:

  I know "HTTPS" has the same function as "Elgamal"

well, you are wrong. The two things are not comparable and don't have the same function.


Does custom header for CSRF protection invalidate CSRF protection

Using custom headers to mitigate CSRF does work, however, this isn't considered best practice. Best practice is to include a CSRF token as a parameter in all state changing requests to ensure the request is from within the domain. The main concern for using custom headers to mitigate CSRF is that it's unknown if in the future an attacker will be able to send custom headers in cross-site requests.

This post does a really good job explaining why this isn't the best idea.


Preventing Basic Directory Traversal Attack in Linux application

This simply means that dwcore application which is listening on port 8080 and 8443 are vulnerable to path traversal. Without the knowledge of what that application is, an accurate answer cannot be provided for this.

Having said that, if the application running on those two ports are not used, you can kill those services or add an iptable rule to restrict access to those ports to prevent this.

If that application is needed to run, you will have to fix directory traversal at code level [if that is written by you and have the source available.]

Also to answer your following questions:

  Is this easily fixed by adjusting permissions to files or do I need to
  do something else?

/etc/passwd is supposed to be read by all users on the machine. The issue here is not that it can be read, rather it can be retrieved by someone outside the raspberry pi by connecting to the web application running on port 8080 and 8443. In other words, this is not a permission issue, but an application security issue.

PS: From the question I read that you have created a web application in PHP to run on the raspberry pi, but it it is unclear at this point which port your application is listening on if you have disabled port 80.


MITM setup using airmon-ng, iptables, and isc-dhcp server

With multithr3at3d's help I finally figured out how to do this. Here are two mistakes I made above:

The DNAT rule in the NAT configuration changed the receiver to my laptop. This rule was misleading and should be removed. That's what the configuration should look like:

     sudo iptables -A FORWARD --in-interface at0 -j ACCEPT
     sudo iptables -P FORWARD -j ACCEPT
     sudo iptables -t nat -A POSTROUTING --out-interface enp4s0 -j MASQUERADE

There was no DNS server available for the clients. By adding option domain-name-servers 93.104.209.27 to the dhcpd.conf file clients can access websites:

    subnet 192.133.1.0 netmask 255.255.255.0 {
        default-lease-time 600;
        max-lease-time 7200;
        option routers 192.133.1.1;
        option broadcast-address 192.133.1.255;
        option domain-name-servers 93.104.209.27;
        range 192.133.1.10 192.133.1.50;
    }

The IP address here is a random DNS server in Europe.

Although this is not the most elegant solution it works for me!
Thanks!


USB OTG DMA Attack vector, any information about that?

In contrast to all the other buses mentioned, USB does not allow remote DMA; nowhere in the USB on-the-wire protocol are there memory addresses.
Only the driver and/or the OS can control from/to which memory addresses USB data is read/written.

OTG allows to change the roles of host and device, but does not change the USB protocol.

Jodeit/Johns talks only about bugs in USB device drivers.

Maynor talks about driver bugs, and then mentions something called "DMA attack", but gives no details whatsoever.
The most likely explanation is that he found some driver bug that allows the device to influence how the driver handles its memory buffers.
This would still be a bug in one specific driver, and has nothing to do with the remote DMA feature of other buses.

In other words: there is nothing dangerous about USB OTG itself, only with the quality of its drivers.


Does Gmail 2-factor auth increase security on smartphones?

You've hit on a bit of a sore point; using smart devices as something-you-have type credentials has some drawbacks.

As you point out, the smart device often plays an active part in the authentication process in addition to being the second factor credential. This is not so much a problem as it might first seem. The purpose of using your smart device as a something-you-have is so that the attacker must both steal the device and simultaneously have access to your password in order to gain access to your account. This is still true, even when the device is doing both parts of the authentication, but you're right to question it - particularly if you store the password on the device. In this case your dual-factor authentication becomes a single factor - the device.

The other reason smart devices make poor credentials is that they have a software stack, and they typically run third-party applications. In other words, they have malware. A smart device infected with malware is equivalent to a stolen smart device in terms of using it as a credential.

The malware can instigate the login, wait for and capture the incoming SMS/notification, and read out the second-factor code to complete the login. In the most extreme cases, this will happen without the user's knowledge.

So in summary, don't worry too much - the fact that you are aware of this issue is great, just make sure that the phone does not store the password or provide autologin - locking the app is not enough, as an attacker can still read off the stored password from the phone's hdd directly.

And when any real security is required, use hardware tokens that cannot be subverted, such as TOTP/HOTP tokens. That said, using the smart-device is much much better than having no second-factor at all.


DDoS prevention (LOIC doesn't do the job anymore)

You can try tools like Seige, BoNSI from Backtrack, these are easy to use and "program name -help" should guide you.
If you are looking something commercial then http://blitz.io is another option.


C&C domains used by Flame/Skywiper trojan

As far as I'm aware, Kaspersky were the first company to discover it and they've written some great blogs on it, with excellent detail on the registry keys, files etc that are affected but there isn't much information on the IP addresses of CC servers. Here's their most recent blog detailed the registry keys etc -

http://www.securelist.com/en/blog/208193538/Flame_Bunny_Frog_Munch_and_BeetleJuice

and in a previous blog, they talked about the communications to the C&C servers -

http://www.securelist.com/en/blog/208193522/The_Flame_Questions_and_Answers

saying that

"Recorded data is sent to the C&C through a covert SSL channel, on a regular schedule. We are still analyzing this; more information will be available on our website soon.

......"

so I think it's probably best to keep watching Kaspersky's blog as they appear to be further along in analysing Flame (although that can obviously change).

According to this post (http://blog.cuckoobox.org/2012/05/29/cuckoo-in-flame/), the domains/ips are being actively sinkholed, which possibly explains why there's nothing been publicised as of yet.

Update: Looks like Kaspersky have identified information on the C&C servers - http://www.securelist.com/en/blog/208193540/The_Roof_Is_on_Fire_Tackling_Flames_C_C_Servers.


What about Long Router Passwords and WPS Push-Buttons

The short answer is your setup is relatively secure. The longer answer is there will still be vulnerabilities like devices being able to join a few minutes after the WPS push button is pushed. OR any other manufacturer flawed WPS implementation that brings other unknown risks.

So It is really better to disable WPS altogether. You should just use WPA2-PSK. It is hardly inconvenient as you only need to set up the login for each device only once. Even writing the long WPA2-PSK password on a post it and stick it to the router is more secure and almost as convenient as your current setup. Though many infosec guys will disapprove of this method. For me I save a picture of the password in my handphone and also on my desktop computer for easy reference.


Windows GnuPG - GPG - Smart Card Status - Not Detecting Yubikey

I know this is a bit old thread, but since Google brought me here the 1st time I was searching the answer for this error message, I wanted to share a solution which worked for me.

My device has another smart-card reader. In the device manager I had to disable the other reader. Once it was disabled, gpg started to work properly. (You don't need to uninstall the device, and you can re-enable it when you want to use it)

Hope this helps someone.


Storing TOTP secret in database, plaintext or encrypted?

Where have you been reading about 2FA and why do you assume that everyone stores the secret keys in plain text?

As you are talking of TOTP you should probably read RFC4226 and RFC6238.

Yes, e.g. the Google PAM module stores secrets in plain text in the users home directory. But please note: The HOTP algorithm was published in 2005, the iPhone 1 was published in 2007. We can simply deduce that the HOTP algorithm was not ment for smartphones - neither the TOTP algorithm, which was published even later.

The problem with encryption or plain text gets immanent, if you are using HOTP/TOTP to authenticate on a local machine. But the OTP algorithms are designed to be used with a trusted backend system. A local machine of course can not be trusted, as an attacker might sit in front of this very machine.

Take a look at section 7.5 Management of Shared Secrets, RFC4226:

Here it is recommend to encrypt the shared secrets, just like you suggested in #1. And of course if someone gets the encryption key, the authentication is useless. But this is a backend system, you need to protect.
E.g. our (disclaimer!) open source software privacyIDEA actually encrypts the shared secrets and if you want to even with a hardware security module. (Again - this is a backend system)

You might also want to read a bit more about the flaws of the Google Authenticator design: https://netknights.it/en/the-problem-with-the-google-authenticator/


How was my Gmail account hacked from China?

Remote attacks can be from anywhere in the world and are rarely in the same geographic vicinity as the target.

This said there are a LOT of different ways your account could have been compromised and it may have nothing to do with your recent activities. If you use a patterned, or similar format, password on multiple websites your e-mail and password pattern could have been gathered from another site being breached. For example, if you use the following password on Yahoo:

123yahoo

and I know your e-mail address is with Google I might suspect your Gmail password is:

123google or 123gmail

simply from looking at another password you've used and your e-mail address. The timing could be a coincidence.

As another example of where it may have nothing to do with your activities, and I do NOT think your situation is a result of the following, but a while back Google was breached by Chinese Hackers (or at least that's who it's attributed to in the following article):

https://www.washingtonpost.com/world/national-security/chinese-hackers-who-breached-google-gained-access-to-sensitive-data-us-officials-say/2013/05/20/51330428-be34-11e2-89c9-3be8095fe767_story.html?utm_term=.794baab6ca8e

So right off the bat get rid of any thoughts that attackers need to be physically close to you to attack you on-line. Humans evolved to only be concerned about threats in their immediate proximity and it causes us problems when perceiving threats in the correct context on-line.

There isn't enough information in your post to step through all the activities you have done in the past with your account for anyone to really answer exactly how you were attacked but browser attacks, especially if you have used an older browser, and malware on all the systems you've used is certainly a possibility. If you've used any computers that you don't normally use those would also be likely candidates. Again there are thousands of potential possibilities but those are things I think most people would tell you to look at first.


BIOS Password vs. BitLocker Pre-boot PIN

Unless I'm mistaken, I understand that both a BIOS password and the BitLocker pre-boot PIN can help to prevent DMA attacks. I'm also guessing that these features are distinct

The BIOS password does not have any effect on DMA attacks. The BitLocker pre-boot PIN can assist in mitigating a specific type of DMA attack called "early DMA", which is carried out before the IOMMU is initialized and ready to restrict memory access from devices. See here for more detailed information.

  Is either option--using a BIOS password or a BitLocker pre-boot PIN--preferable over the other? Should I be using both? Are there unique (dis)advantages associated with either option?

They have totally different purposes. A BIOS password is a very basic protective measure that is only useful against an attacker with limited physical access (specifically, access only to standard input devices like the keyboard and mouse). It is meant to protect from a casual attacker who wishes to boot the system or change firmware settings. An attacker can easily bypass a BIOS password if they have full access to the physical motherboard and firmware chip. Furthermore, a BIOS password does not prevent someone from removing the hard drive and putting it in another computer to read the entire contents.

It's important to note that not all BIOSes behave the same way. Most BIOSes will store the password in plaintext in non-volatile memory and will refuse to boot or allow configuration changes unless it is entered again by the user. This is, obviously, not particularly secure. However, some might use it to augment a feature called SED (Self-Encrypting Drive), where the storage devices themselves perform hardware encryption using the password that is entered. Some other systems will use a rather obscure ATA security feature that offloads the password storage and verification to the storage drive itself, causing the drive to refuse reads until the password is entered. These are all often referred to as "BIOS password".


Why do capability-based security systems protect against the confused deputy problem?

You are correct in a sense. The root of the problem generally speaking is that the abused subject tends to have broad authority, it's not constrained. If the subject was only permitted to act based on their capabilities, the abuse will be constrained also.


It seems you may have some misunderstanding of Kerberos and/or Windows domains.

First of all, the browser doesn't generate a Kerberos ticket; a domain controller does. At most, the browser will ask the local security authority (LSASS) to do it. To get Kerberos working, you need to understand how authentication and trusts work in an AD environment.

The user in your local AD is completely separate from the user in the cloud AD, and they have no relationship at all to each other. The fact that you could authenticate between Windows machines in the past using the same user/pass is a legacy thing that will not work with Kerberos.

For cross-domain Kerberos authentication, you must establish an Active Directory trust. Whether this is a one-way or two-way trust depends on which resources are being accessed by which users across all applications. You'll need to talk to your AD team to sort that out; trust configurations are domain-wide.

The lack of a Negotiate header suggests that Kerberos isn't even starting. In order for that to happen, your client must be able to construct and validate the service principal name (SPN) of the remote host. Once it does that, it can request a service ticket that it will pass to the remote host for authentication.

Since SPNs are a Kerberos feature, it is impossible to validate the SPN of a host that is not part of your own domain/realm or a domain/realm that you trust. Once the trust is setup, SPN validation should be seamless if (1) DNS is setup properly and (2) the server has correct SPNs published in its Active Directory.


Best practices for securing open APIs from quota theft

If you cannot setup user accounts or any other way of identification, which is best practice for every API, you are left with the following:

Collecting metrics of number of requests per IP, Subnet, AS, Country
Throttling proportionally to the usage while trying best effort not to compromise users who do not abuse the system and providing enough quota to the subnet, AS, country etc. This is because without user identification you will always be unfair when trying to limit by network addresses, as this bit is not identifying any user.

You might need to know what the limits should be by looking at the total number of requests from the country and also on the subnets from the same country, same for AS, subnets etc. This is to provide the best quality service by taking into account these metrics.
However this is bad method.

ps. You should really do this per user account. If the account is stolen, you put the policy on the accounts to make it not happen again. Use encryption and so on.


Policy requirements of Sarbanes-Oxley (SOX)

See Does (J-)SOX Forbid the Use of Open Source Software?. Excerpt from my answer there:

  Fact is that throwing extra unnecessary requirements onto yourself and claiming they're regulatory doesn't earn you any brownie points, it just costs you more.

Overstatement of the bounds of SOX is common and wrong. Now, it may somehow be the case that your code is material to the company's annual financial statement and they don't want to add another system to the realm of audit, but that's probably not the case.

SOX means that root on the machine which houses the company's financials is closely guarded, but it generally doesn't have any connection to most people's workstationns. The reason that there is so much  madness surrounding SOX is because the law doesn't spell it out. The SEC provides "guidance", but interpretation has been pretty scattered.

SEC guidance from 2007 is a good pointer and reminder that if what you're talking about doesn't relate to the internal controls over financial reporting, it's not relevant to SOX.  Thus, changing passwords every 90 days can fall under SOX (e.g., accountants authenticate to the ledger system using domain accounts), but shipping a replacement laptop to home as opposed to having you come in and take it off your desk doesn't matter.

Further, the SEC encourages companies to review controls based on risk

  The Interpretive Guidance reiterates the Commission’s position that
  management should bring its own experience and informed judgment to bear in order to
  design an evaluation process that meets the needs of its company and that provides a
  reasonable basis for its annual assessment of whether ICFR is effective.  This allows
  management sufficient and appropriate flexibility to design such an evaluation process.
  Smaller public companies, which generally have less complex internal control systems
  than larger public companies, can use this guidance to scale and tailor their evaluation
  methods and procedures to fit their own facts and circumstances.  We encourage smaller
  public companies  to take advantage of the flexibility and scalability to conduct an
  evaluation of ICFR that is both efficient and effective at identifying material weaknesses.

Thus, think about the impact your application could have on the company's financial reporting. Not financial growth, profit, or anything else -- just the reporting. If it's not related (an easy test is "does it ever deal with dollars and cents?"), then somebody is leading somebody else astray. Perhaps you can point this out to them, or perhaps somebody is lying because it makes it easier for them to tell you want they want to say and there's nothing they can do about it.


How to prevent users from retrieving the Java source code from a jar/exe file that I am distributing openly?

You should research code obfuscation, because that's what you want.

Obfuscating the code will never prevent it completely and let me tell you that it's impossible to stop a programm from being reverse-engineered. But obfuscating the code will stop most script kiddies and make it at least harder to reverse-engineer your application.

There are a lot of those obfuscators out there and it will become opinion based to tell you which one is best or better.

So here is what you should do:

Research code obfuscation
Implement it in your application

Here is an SO link which could help you to get a start of it.


Is a wired public network more secure than a wireless public network?

It kind of depends on the security used for the wireless access points, and the authentication methods. I would expect WPA2 with 802.1X as this is common for enterprise networks. However there are many EAP variants, some of which are insecure. For the exact details you should find the authentication method used. It doesn't necessarily need to be so, but usually wifi is more vulnerable to attacks


Is it normal to being able to kill a process from outside a container?

Yes it is. Docker processes on Linux are sandboxed such that they can't affect the rest of the system, but the rest of the system is free to mess with them however it wants to. They are still running on the same kernel, same file system (even if they can only see a limited portion of it), etc. Docker is not a VM; the processes running within the container are running on the same OS as those outside the container.

Given that, it would be very weird if you couldn't list and kill contained processes (from outside the container, and assuming you have enough privileges). Just like you can list and kill Chrome sandbox processes from a normal-privilege OS shell even though the Chrome sandbox prevents those processes from doing anything, so too can you list and kill Docker contained processes from a normal-privilege shell. Processes in one container are unable to interact with those outside of it, including those in other containers, but un-contained processes have no problem reaching "into" a container.


Why do scammers use victims' computers to remote-control their own computers?

TeamViewer has noticed that scammers often come from India (or other places where scams often originate), and so when you get an incoming connection from India TeamViewer will give you a warning saying that this could be a scam.  If the scammer can get the victim to connect to the scammer's computer first and then reverse the connection (by clicking a button that says "switch sides with partner"), TeamViewer's warning is skipped and the victim still doesn't know it's a scammer.  The scammers want to use TeamViewer because it has the ability to blacken the victims screen so the victim cannot see what the scammer is doing.

A Youtube reference


Is it possible for page to get your installed extensions through javascript?

If the site can control the extension, yes. Look at chrome.runtime.onMessageExternal.addListener.

If the site can't control the extension, no. Chrome protects the extensions.

But there are ways.

If the extension has web_accessible_resources, the javascript of the website can XHR or whatever to the resource (e.g. chrome-extension://oiplkfaidhjklglajdpfehoagkmlcakh/images/camera.png for Pig Toolbox) and check the reply.
If the extension modifies DOM, the site can detect it using Javascript.

If it is not an extension but an app, the site can just use chrome.app.isInstalled

If the extension wants to check other extension, it can use chrome.runtime.onMessageExternal


Password management: how an administrator should reset password for a user?

This question is rather broad and hard to answer with so few details. It really depends on your organization's setup, but I'll try to give a general answer:

It's always better for a user to type in their own password rather than having an admin create a "temporary password". The main reasons for this (as far as I know) are:

1. The admin could perform actions under the user's name while the temporary password is set. If non-repudiation is a legal concern for your organization, then this matters. Often an admin has the power to impersonate a user anyways, so it doesn't matter.

2. How to get the temporary password to the user? Email is a terrible idea because it it insecure. Out-of-band methods (ie non-digital) are preferable, such as printing it and physically handing it to them, telling them the temp password over the phone, etc. If you have to send the password to them electronically, do you have the infrastructure to encrypt it for them?

For these reasons, it's always better if you can somehow flag the account for "password reset" (depending on which software you use) and let the user type in their own password the next time they log in. So if any of the client software that your users use is Active Directory aware, and has the ability to perform a Password Reset, then this would be preferable to having an admin type a new password.


How does google docs know password for published googledocs document on a public site?

The document is set as public, so anyone who has the link can view the file.

Google Docs doesn't need to know your password in order to transmit the document to the person requesting it.

If you'd like to protect the document so that only certain people have access, view the document, then click File -> Share.


Websocket Authentication at Opening Handshake Sufficient?

WebSockets work by first having an initial HTTP handshake and then establish a message-based communication. Everything is done within a single TCP connection and in case of wss:// within a single TLS connection. Authenticating this connection at the beginning (for example with sending the session cookie inside the initial HTTP handshake) is similar to only authenticating a SSH session at the beginning or only authenticating a normal HTTP/HTTPS request at the beginning and not authenticating every transmitted byte of the request again.

Of course, this single authentication at the beginning is only sufficient if the following data can not be manipulated somehow. In your example wss:// is used which uses TLS and this way protects the data against manipulation by an active man in the middle.

But if for example the attacker manages to compromise the endpoint of the connection (for example using XSS) he might be able to send his own messages over the already authenticated WebSocket. It is likely though that if an attacker can send messages within an established WebSocket he will also be able to establish new WebSockets. And if these are authenticated with a session cookie only the browser will automatically include the cookie when establishing the new WebSocket which means that it will be implicitly authenticated. So the mitigation against this would not be to authenticate every WebSocket message but instead to make sure that an attacker cannot compromise the client side of the web application using XSS or similar in the first place.


Separate third-party cookies for each website

Primarily because it would break things. For example, Facebook Like buttons would stop working because it wouldn't be able to check which Facebook account you are logged into. There are workaround where it shows a pop-up instead, but this is kind of ugly, and it also wouldn't be able to work as a passive page control (e.g. show number of number of likes and display comments).

Also, there is little advantage with additional complexity of maintaining a separate set of cookies depending on what the outer page origin is. I can't imagine a scenario where a 3rd party cookie would just need to keep track of the anonymous user when they are visiting a certain site. If this is required, then the outer site could simply pass a token to the 3rd party object.

If you want the additional privacy this would bring then you should simply disable third party cookies - this would effectively have the same result as you've suggested.


Does TLS-OBC only improve security of Web Browsers? Does it improve the security of SSH?

SSH does not rely on SSL/TLS (see RFC 4253). OpenSSH relies on the OpenSSL library, but that's just because it reuses some of the cryptographic functions, which are common to the two protocols (OpenSSL does far more than SSL/TLS).

Therefore, you wouldn't be able to use TLS-OBS as such with SSH.

Would you want to generate a new key-pair every time you log on to a new SSH server, in a similar way to what's suggested in TLS-OBS? Possibly, but you wouldn't necessarily need a new extension to achieve the same goal. You might as well use the current methods: generate an SSH key-pair and add the public key to the authorized keys in your account the first time you log on.


Try removing the eval when you test it, to see what command is being run:

echo readfile("eval/key.txt");\");// * 5 / 7;

Do you see what went wrong? You're trying to escape the " and close the eval with );, but that's not part of what eval is actually running. eval is only evaluating echo $x * $y / $z;.

If you try readfile("eval/key.txt");// for $x you'll have better luck:

echo readfile("eval/key.txt");// * 5 / 7;


Can I keep large encrypted files in my mailbox on mail provider server?

Pretty much all mail systems have a limit on email size. You can howevr overcome it by splitting your big file in several mails.

As for policy, you should read the terms of use of each provider to figure out. For instance GMail restricts (restricted?) usage of third-party applications to avoid that you use GMail as a virtual drive (there were several programs precisely for doing that).


Why is tinyurl.com returning a phishing warning?

Given the fact that Tinyurl (or other services like bit.ly) allows one to hide another URL by providing a short one, you can easily understand that the service is abused in the context of phishing attempts where the goal is usually to trap a user into clicking on a malicious link.

This means than many Tinyurl URL's have been used to redirect to malicious URL's in the past - therefore the flagging.

A "tinyurl" link looks less dangerous for an uneducated user and has therefore more chances to be clicked on.

To answer the "What authority has deemed this a phishing site?" : if I use Chrome and go on tinyurl.com I have no warning - I suppose that you use a browser add-on or an AV that has "web protection" and that injects some warning-sign html on your pages to warn when you arrive on addresses that are flagged as dangerous.

edit : man your question is not the same anymore.......


What are the vulnerabilities of using a 256 bit encrypted PDF file over email?

Since it is protected by a user password, it is vulnerable to brute force/dictionary attacks unless you choose a really long and complex password. It does not matter whether your are using AES 128 or 256 if your password is the weakest link. Someone who intercepted your email may try to brute force the password to read your PDF file.

If you want your document to be more secure, Adobe supports the use of PKI based encryption and digital signatures to mitigate the issue of using weak passwords. However, this requires the use of certificates.  While encrypting, the publisher’s computer randomly generates a symmetric key (up to AES256), and encrypts that key to each recipient’s asymmetric public key to include in the document with the symmetric key encrypted content.  In return, the recipient computer uses their own private key to decrypt the symmetric key, and then decrypt the document.

The randomly generated key should have a much higher entropy than your password to mitigate brute force attempts.


How can pentest reports contribute to structural solutions for vulnerabilities?

Ultimately the responsibility for implementing the recommendations from a penetration test/security review, lie with the owners of the system.

As a consultant, you can make recommendations, so as with XSS you can recommend that the customer ensure they use a robust combination of input validation and output encoding to properly mitigate the risk and you can point out the weaknesses of blacklist filtering or other naive fixes like getting rid of specific characters.

However at the end of the day, you can't stop customers from taking this approach against your recommendations.

Of course, if you're internal to the organization you have more options in that you can try and get security standards for your development teams that lay out the correct way to avoid/reduce the incidence of security issues.


Exporting data beyond a cryptographic boundary

As armb said, FIPS 140-2 is used for certifying cryptographic modules. A database is not a crypto module but a database may perhaps may make use of a FIPS140-2 module. This does not mean the database is certified.

There are a number of ways to send a document from the database to a different security environment. The main risks you are trying to mitigate against is you don't want anyone else to be able to see the document and you want to prove it came from you and not someone else to the entity that revives it.  The best way to do this is to sign and encrypt the data.

You could do this in a number of ways, its a fairly open question:

send it over a trusted bearer, eg a dedicated link or a USB stick by a person who is trusted.
Over a secure channel that provides the signing and encrypting, eg SSL using mutual certificates or a VPN.
Signing and encrypting the actual data to be sent and then send it over an untrusted bearer, eg the internet.

You can make all these different options as manual or as automated as you want. If its automated, you should probably have some controls to make sure your not accidentally releasing data you don't intend.

I hope this helps.


You should look at the BlackHat talk ARM Exploitation ROPmap.  In short you can find ROP gadgets with any assembler variant,  just the rules are a little different for ARM.

Before tools like mona we used objdump and grep!


Use bettercap to sniff traffic going through a proxy configured in the browser?

You will have to ask yourself how bettercap can get a hold of traffic.

You mention three distinct machines in your scenario:

  User IP: 192.168.1.5/24, G/w 192.168.1.1
  Proxy Server IP: 172.27.0.50
  Kali Linux (running bettercap): 192.168.1.10/24, G/w 192.168.1.1

But in order to better understand what's going on, you need to clear that there is another machine here, so the list would be:

User IP: 192.168.1.5/24,
Kali Linux (running bettercap): 192.168.1.10/24
Gateway-Machine: 192.168.1.1
Proxy Server IP: 172.27.0.50

Obviously, your proxy server sits on an entirely different network segment than your other three machines.

Question: Is that some in-house proxy or is the proxy possibly provided by your ISP?

In case it is an inhouse proxy, it can be reached from the User machine 192.168.1.5 either through the default gateway 192.168.1.1 or there must be a separate route defined to that network.

You are not saying what OS your User machine is running, but try some commands along the lines of

traceroute 172.27.0.50

or

ip route show

to understand which way traffic to your proxy server takes. This will possibly help you understand how or why not you can eavesdrop the traffic.

Another question:

Might it be the case that your User machine is multi-homed, i.e. it has multiple network interfaces, one connected to the 192.168.1.1/24 network and another one connected to the 172.x.x.x network? That would be a perfect explaination.

Otherwise if there are no special routes and all traffic passes through 192.168.1.1 either with or without proxy, there is no good reason why you would see the traffic in once case and not see it in the other. Unless you have any filters set you forgot to tell us about, so make sure you sniff all traffic originating from or going to 192.168.1.5 on all ports!


Why do people say that PHP is inherently insecure?

It is pretty hard for a language to be "inherently insecure" by my definition, since a good programmer can adapt.  But PHP started out leaving a lot of minefields lying around for novices.

The initial versions of PHP paid little attention to security and the design had some big flaws.  Security is hard to retrofit into the core software and into the libraries.  Security training is hard in the best of circumstances, and even more so when a large subset of the developers are inexperienced and started off with bad defaults.

For example, it wasn't until version 4.2.0 that register_globals was disabled by default, so data received over the network was not inserted directly into the global namespace anymore.   This feature is finally slated for complete removal in the next version.

The early release of PHP and the ease of deploying simple PHP applications also attracted many developers with little security awareness, and ensured a large number of applications, a significant number of which had remotely exploitable vulnerabilities.  The size and vulnerability of the deployed base also attracted a lot of interest from the exploit community.

Here are some references and useful links

PHP Insecurity - Technology Review
How secure is PHP? - Stack Overflow
References on "inherently insecure": http://www.sitepoint.com/forums/showthread.php?threadid=112694
PHP Security Consortium
http://en.wikipedia.org/wiki/PHP#Security


How to deny shell execution in all sub-directories?

First of, make sure that you have the mime.types properly setup in your config file (http://wiki.nginx.org/FullExample#mime_types), so a foo.php.jpg is still treated as an image.

Also, use the tilde-asterisk (~*) instead of just the tilde (~), this will make your regex case insensitive (and thus prevent files like blah.pHP and evil.PHp, ...):

location ~* /webroot/uploads/(.+)\.php$ {
  deny all;
}

One approach you could take is to whitelist allowed extensions, and handle others.  Since Nginx doesn't have a syntax for not matching an expression, you could "do nothing" when a match is found, and deny/redirect the rest

location ~* /webroot/uploads/(.+)\.(jpg|gif|png|mp3)$ {
  # empty block
}

# all other requests come here
location / {
  # redirect, deny, ...
}


Help choosing the right virtualization for a CTF

The two top Linux based solutions in my opinion are Xen and KVM. Both offer is slightly different means to a final virtual solution.

If, however, you are looking for an easy, free solution that will VM Linux servers, I'd consider a Windows based "VirtualBox"  solution.  It comes Innately GUI based and offers a simple VM infrastructure without all of the bells and whistles of an expensive VMware setup.


Windows Active Directory: How do endpoints authenticate the Domain Controller?

The DC is not authenticated as a DC, but otherwise as part of the kerberos authentication mechanism both sides require a shared secret (your password). The ephemeral encryption key used to encrypt the as-rep (which has the tgt) in transit is passed using that shared secret. So assuming someone has your password (and your machine account password if you are using windows) he can spoof a dc. Notice that if you want to access any external service the DC needs to know what is the shared secret for that service, so essentially it's being verified on the fact that it needs prior knowledge of everyone's password.


Should I reject a CSR when the host emailed me the private key for SSL certificate request?

Yes, you should absolutely reject the CSR. Additionally, you should change your hosting provider as it looks like they don't know what they are doing.

It is already bad enough that they sent you the private key via e-mail i.e. via an insecure medium. However, they also Cc'ed it to someone else, which is a complete breach of confidentiality.

Furthermore, I wonder why they sent you the private key -- it's supposed to be installed on the server, which is something they can do by themselves.


If I send a plaintext e-mail using Gmail to somebody, including my PGP public key block, is that secure?

As Steffen already said, the Achilles' heel on your security is making sure you are talking to Joe, and Joe being sure he is talking to you. If the initial key exchange is compromised, the third party will be able to read your messages, reencrypt and send to Joe, and vice versa.

The crypto does not matter unless you solve this issue. That's why on the HTTPS world, there's a special entity named CA (Certificate Authority). The CA is to make sure Google cannot obtain a certificate for Facebook, and so on. So unless a rogue CA issued the certificate, you can navigate to Google, and be sure you are on Google.

The initial key transfer is the critical one, and this can be done in a couple ways:

in person
by out-of-band message (tweet, Instagram post, snail-mail)
referral by a friend in common (you know Bill, have his key saved, and Bill knows both of you, and shares both keys)

After this exchange, your setup is pretty solid.


Path traversal filter bypass techniques?

There are various encodings you can try to enable you to bypass a filter:

Try / and \ at the start of the folder name to try and reach the root directory.
Try %2f and %5c (percent encoded versions of the above).
Try using 16-bit Unicode encoding (. = %u002e, / = %u2215, \ = %u2216).
Try double URL encoding (. = %252e, / = %252f, \ = %255c).
Try overlong UTF-8 Unicode encoding (. can be %c0%2e, %e0%40%ae, %c0ae, / can be %c0%af, %e0%80%af, %c0%2f, etc, \ can be %c0%5c, %c0%80%5c).

If you get a different response trying one of the above then you have managed to change either the execution path or the file system path that is being accessed. This may indicate that the particular sequence used may be worthy of additional investigation.


Are jailbroken iPhones an enterprise security risk?

In terms of the second part of your question about the privacy trade-off, that's very dependent on the organisation in question and their priorities.

Unfortunately a lot of companies would place their security concerns much higher on an agenda than privacy concerns for their employees (unless regulatory requirements dictate otherwise).

On the first part, there's a couple of potential risks from jailbroken iPhones that I'm aware of.

First would be restrictions on applying updates.  There will likely be a delay in being able to apply Apple security updates as the jailbreak won't always be available instantly for that version.

Second would be the concern that the jailbreak or software installed afterwards could compromise the security of the iPhone (eg, the default password on the SSH daemon from jailbroken devices).  There can be an assumption of quality and security control for iOS apps installed from the official Apple store that isn't there for apps from other sources.

Also having a jailbroken device may allow the user to disable security software installed by the company, which I'd guess is another reason that they're not keen on it.


Google approach to device security (BeyondCorp): managed devices and inference engine

One of the goals we have with the research papers is to save other companies time and effort in moving to a BeyondCorp model, especially because as we've grown the model internally we've opened up many of the elements to others to use. On Google Cloud this is collected under the umbrella of Context-Aware Access.

The best way to stop malware is binary authorization, allowing only trusted, safe executables on each managed device. Every system gets tricked, even this one, but it's by far the most reliable way to protect yourself, especially from zero-day vulnerabilities.

In "Building a Healthy Fleet" we dig into ways to manage a fleet of machines, including monitoring and maintaining their health. That paper links to a bunch of tools, and lays out best practices across many methods.

OS Query and Santa are two open source tools to help with controlling what software is allowed to run on machines you manage. They give you both control and visibility, and can scale to a large number of machines.

Google also provides Endpoint Verification for Chrome and Chrome OS, allowing you to then feed machine metadata directly into access decisions made by other BeyondCorp tools to control which devices can access Google Cloud resources or Cloud-backed web-apps.

I don't think any of the tools I've listed will prevent data leakage from individual devices, but you can see other discussions here.