Does Windows have a built-in password store? What passwords are stored in Microsoft Windows? How can I know what password are saved in computer?

Windows Credentials

Yes, they are stored hashed within files in the c:\Windows\System32\Config\ directory. You will need the SAM and system files. However, a backup of these files may be stored in the Windows repair folder at c:\Windows\Repair\. SAM contains the hashed passwords, however they are encrypted using the boot key within the system file.

If Windows is running and you need access to the locked files in the Config folder (for example you know the files in Repair are out of date), you can extract these files using regedit.

C:\>reg.exe save HKLM\SAM sam
The operation completed successfully
C:\>reg.exe save HKLM\SYSTEM sys
The operation completed successfully

An alternative is to use a tools such as Pwdump which can extract the hashes stored within the SAM/system files directly without the need to use regedit or manual decryption of the SAM using the boot key.

Windows passwords may also be cached in memory. Windows Credentials Editor can extract these values in plain text from the Windows Digest Authentication package.

C:\>wce -w
WCE v1.3beta (Windows Credentials Editor) - (c) 2010,2011,2012 Amplia Security - by Hernan Ochoa (hernan@ampliasecurity com)
Use -h for help.

test\MYDOMAIN:mypass1234
NETWORK SERVICE\WORKGROUP:test

You will need local administrator access to do all of the above, unless you can mount the partition from another machine to directly access the files in the first case.

Network Credentials

Network passwords are stored inside Windows Vault/Credential Manager:

Tools such as Windows Vault Password Decryptor can extract and decrypt these.


How easily are keyloggers foiled? I was wondering exactly how powerful can keyloggers be?

For example someone wanted to access his bank account (which of course is through HTTPS), he will "enter" his password using a combination of

type
delete
highlight delete
highlight-drag-drop
cut (from another program etc)
copy (from another program etc)

and basically you know, funny ways to foil keyloggers. I'm not very adept with this technology on keyloggers and I was wondering are these attempts sufficiently strong enough?

Or rather, how many % of keyloggers would be foiled by these attempts in masking the password?

Of course I understand it is more critical that we do Methods of mitigating threats from keyloggers but I mean in this case we assume that the user has not managed to block the tunnel that sends the attacker the password.

Malicious software that only logs keyboard strokes rarely exists in the wild. Most key loggers for graphical interfaces (e.g. Windows) are more sophisticated and log all user interaction including mouse, copy and paste events by hooking into the operating system.

Key loggers are normally a small subset of a rootkit that may also include the ability to act as a man-in-the-middle (MITM) and capture your credentials or session information without logging any key strokes.

The best way to foil key loggers is not to have them.

Ninefingers answer on Methods of mitigating threats from keyloggers has good recommendations. E.g. Monitor network traffic, use an intrusion prevention system (IPS) or intrusion detection system (IDS).

In addition I would add:

Avoid logging into websites/accounts using computers that you don’t have control over. E.g. At work, at a friend or parent’s house.
Avoid installing software that is not from a reputable source. Use digital signatures and file hashes.
Be aware of what applications and services run on your computer. While rootkits do stealth themselves making them hard to detect, knowing what should be running is definitely an advantage.
Use two factor specifically one-time-password (OTP) authentication to websites where possible. In the specific scenario of Internet banking, financial intuitions often offer a token or SMS based service that provides a password or number that can only be used once.
Use protected mode browsing that disabled browser plugins or scripts.
Use low security accounts for normal activities.
Apply security updates.
Change password regularly.

And while this does not prevent key loggers, backup you files regularly. I say this because if you suspect that you have a rootkit then you should wipe your installation and restore only the data you need.


How can Chromium access my Firefox history? I have 3 Firefox profiles set up ("home", "work", and "tmp") and one Chromium profile. I currently have Firefox open in the "home" profile and Chromium open. When I started another instance of Chromium with chromium --temp-profile, I noticed that the new instance's history matched the history in my Firefox "work" profile. The history sharing seems to be only one way (from Firefox to Chromium).

How is this possible?

I'm running GNU/Linux just in case that makes a difference.

Your data is stored in files under your user profile. Programs running under your user account (or as root) can read any file in your user profile. The data formats differ between browsers, but all major browsers have code to import profiles from all other major browsers as part of their "make it easy for users to switch to using us" strategies. The only way you could prevent such cross-application data sharing would be to use some kind of sandboxing (run each browser in a different chroot, or a different VM, or as different users), or for the browser developers to make it possible to do things like encrypt the data files with a user-supplied password, and then you could just not supply Chromium the password for Firefox's data.

Of course, all of that only answers the "How" portion of the question. There's still a "Why" question, since usually such data import requires explicit user action and I would not expect it at all when launched with a --temp-profile parameter, but there we couled only speculate (or ask the developers).


A question regarding DNS attacks When would a DNS attack actually happen?

Is it already possible when i connect my pc to the router which is connected to my isp's modem and has received their DNS servers, or later when i am trying to reach a website?
If the second possibility is true i guess using tor browser or whonix would be an adequate protection if one only wishes to browse the web safely.
I heard about DNS leaks in some instant messaging programs.

A DNS attack happens when an attacker can influence how your computer will resolve host/domain names.

That can happen if an attacker is able to:

Change the DNS server IP address in the network settings on your computer
Change the DNS server IP address in the network settings on your router
Change the hosts file on your computer
Intercept and change DNS responses that are going to your computer
Poison the DNS cache of the DNS server you are using, or the cache of your router or your PC
There are also other ways...

If that happens, the attacker can easily redirect you to sites you did not intend to visit. For example if you type in www.google.com in your browser, your browser will try to first resolve that host/domain name to an IP address. And if the attacker is controlling the way your PC does that, he can send you any IP he wants that you will then visit instead of the IP of www.google.com.

When using the ToR browser, your PC is not resolving the host/domain name to an IP address, but the ToR exit node does that. If the ToR exit node is attacked, you could again be redirected to wrong destinations.


Can a CN-only certificate bypass a name constraint if the CA goes rogue? I am trying to cross-certify an internal issuer certificate, adding a name constraint for our domain.

However, it seems that an attacker could bypass this protection by putting the desired host name in a CN attribute of the subject, and not adding a subject alternative name extension. The scenario is an operator for our internal CA goes rogue, and creates illegitimate certificates to execute MITM attacks.

In short, it seems like the name constraint is useless, unless it contains a directory name constraint all the way down to a CN for a specific host (in which case, it's secure, but still worthless).

Would this attack work in practice? Do browsers take measures to prevent it?

The "official" X.509 stance on rogue CA is that rogue CA are out of scope of X.509. It takes some effort to accept that... The idea is that all the CA structure is not really about preventing attacks, but rather being able to point fingers at the culprits. If a CA goes rogue, then the fraudulent certificate chain will allow to pinpoint which CA got it wrong, and thus direct blame where it is due.

Most browsers deal with the issue about name constraints by not supporting name constraints at all, which means that trying to restrict a sub-CA to a specific domain is, for now, a fool's quest.

IF the support of name constraints was wide-spread, then you could restrict a sub-CA to issuing SSL/TLS for a specific domain by adding a name constraints that forces the subject DN to a prefix that defines the CN to a value that cannot be a FQDN for a machine. Thus, any "SSL aware" certificate would necessarily need a SAN extension, thereby avoiding the problem you allude to. But this still makes assumptions on the behaviour of implementations that encounter a certificate whose subject DN contains multiple "CN" fields; if the SAN constrains the DN to "CN=INVALID FOR DOMAIN", and the rogue sub-CA issues a cert with, as DN: "CN=INVALID FOR DOMAIN,CN=www.google.com", how will client software react ?

To sum up, name constraints don't work well or at all in practice, for lack of widespread support, but even if they were supported, whether they actually work would remain a hit-and-miss game.


self-signed certs that aren't the final certificates in the path The X.509 spec makes frequent statements like this:

  (b)  If certificate i is self-issued and it is not the final
       certificate in the path, skip this step for certificate i.

How can you have a cert that is self-issued and not be the final cert in the path?  Is the issuer and the subject are the same how are you supposed to find parent cert?

Self-signed and self-issued are two different things. Thus, the self-issued certificate has the same subject as issuer, but is not signed by the same key. This means there is another certificate which binds the public key used to signed the self-issued certificate.

This can be used for key rollover, e.g. an organization starts using a new key, creates a new self-signed certificate and creates a self-issued certificate for the old key.


Is there any risk related to allow user to give an URL as their image profile? Building a website, I'd like to allow users to specify an url that point to an image that will be used as a profile picture (included in the HTML DOM as a ).

But before doing anything stupid, I was wondering if it was possible for an malicious person to use this for other purposes.

From what I know, it can possible to specify a .php file (for example), that will read the cookie session, and then display the image. But I don't have anything risky stored in the cookie.

What else can be done and is this a very (very very) bad choice or can I go with it?

I found that IE6 had a problem with this that could lead to an XSS exploit, but well, it's IE6, written in 1874 right? (spoiler: I don't target IE6 users at all ;) )

Thanks for your help.

There's actually quite a few issues with the approach:

You need to worry about CSRF attacks (someone could use http://somesite.com/?q=deleteallmydata and anyone visiting the site will have their data on somesite.com deleted), and depending on your code, you're more vulnerable to XSS attacks.
This can be sophisticated - for example, they could show an image to begin with, then switch it with a redirect.

If your site is busy, it can be used to stage an effective DDOS attack - someone could enter a URL for some site they dislike, probably in a way that runs up server resources (a search page or similar).

Attacks on a user's image host are now attacks on your users.

If you don't want to handle images - you may want to consider a trusted host, like http://imgur.com/ (StackExchange does something like this) to direct your users to, and limit your URLs to that site only.


What is the difference between `extendedKeyUsage` and an application policy? In some Microsoft articles like http://technet.microsoft.com/en-us/library/cc731792%28v=ws.10%29.aspx, I find some confusing statements like

  Application policies are sometimes called extended key usage or enhanced key usage. Because some implementations of public key infrastructure (PKI) applications cannot interpret application policies, both application policies and enhanced key usage sections appear in certificates issued by a Windows Server–based certification authority (CA).

While the first sentence seems to suggest they are actually the same thing called different, the latter one suggest they are different things that may both appear in a CA certificate. The only difference seems to be using Microsoft specific OIDs though (more of them can be found here, mostly  1.3.6.1.4.1.311.10.3.*).

So, in how far are they different things, should I bother, and if so how can I treat them correctly in openssl?

In Microsoft terminology, "application policies" appears to be a custom extension with OID 1.3.6.1.4.1.311.21.10, which seems to be roughly similar in contents and goals to the standard Extended Key Usage. I see in an MS-produced certificate an "Extended Key Usage" extension which contains two OID, and an "application policies" extension which contains the two same OID, albeit each within an extra SEQUENCE layer, which probably means that the Microsoft-specific extension allows for some optional qualifiers. I could not find a public description of the extension. (Edit: this page says that the extension uses the "same encoding as szOID_CERT_POLICIES", which is 2.5.29.32, i.e. the standard Certificate Policies extension from RFC 5280.)

Given the lack of information on this extension, the best way to handle it is probably to ignore it altogether. The extension is not marked "critical" so you are allowed to ignore it if you do not understand it, as per X.509, section 4.2:

  A non-critical
     extension MAY be ignored if it is not recognized, but MUST be
     processed if it is recognized.


How valid is this statement "SSL sit between application layer and network layer" taken from http://searchsecurity.techtarget.com/answer/How-does-SSL-sit-between-the-network-layer-and-application-layer

  The SSL protocol is quite unusual, as it doesn't just operate at one layer. SSL is neither a network layer protocol nor an application layer protocol. It is one that "sits" between both layers.

If this is correct then can we say that https works on layer6 and below.

The OSI model which describes networks as a set of rigid layers has never been a good match for TCP/IP networks. It is a remnant of an old terminology war between the world of elegant, abstract, intellectual constructions, and the world of the Internet, aka the network which exists and works.

SSL is built on top of a medium which, in the OSI model, would be "transport" (layer 4): SSL uses a bidirectional channel for untyped bytes; SSL needs that this channel, under non-hostile condition, is reliable (bytes are unaltered and eventually show up at the receiving end in the right order). On the other hand, SSL provides a transport medium (there again, a bidirectional channel for untyped bytes, this times with confidentiality and guaranteed integrity). So, in OSI model terminology, SSL sits between layer 4 and layer 4. Yes, not between two "distinct" layers, but right "in the middle" of a layer.

All of this just shows that the OSI model does not apply to the real world. Why this model is universally taught in all network courses is beyond me.


why gmail's phone verification code not encrypted while using google's phone verification code system, i have noticed that google phone verification code is always 6 digits

cant it be brute forced for randomly generating the 6 digits?is it there any security design implemented over there while passing through second factor?

Google Authenticator is based on the Time-based One-time Password Algorithm (TOTP).

http://en.m.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm

The reason that it would be difficult to brute-force is because the tokens change every 30 seconds. So after every 30 seconds of trying to brute-force, the target moves, and suddenly the token can by any 6 digit number again. This also means that it might change to a value you have already tried, so its possible to exhaust the entire key space without finding a valid one.

However, this in no way means that its impossible or even infeasible if no protection against brute-force is present. For example, if you were somehow able to send 1,000,000 authentication attempts in 30 secs. Even trying 1000 random numbers every 30 seconds, you might slowly get there (re: @domen's comment). However, even a simple 1 second delay on re-authentication attempts per user would render this impractical. As such, some kind of brute-force control that prevents this many authentication tries within 30 seconds is imperative.

At the very least I think Google's own login process introduces a CAPTCHA after unsuccessful attempts which would slow the process down too much and render the attack infeasible.


Problems with using a non-reserved top-level domain for local DNS resolution A network administrator at my organization (let's call him "Bill") wants to configure an internal DNS with the live top-level domain (TLD) .int for internal IP address resolution (for Active Directory, internal websites, etc.). For example, the domain exampleinternalsite.int would resolve to the some internal site that isn't visible to the public. Our organization has not registered these domain names with a registrar. Now I know that this is bad practice, but Bill remains unconvinced that this shouldn't be done.
What are the problems with using a live top-level domain for internal name resolution? Specifically, what are the security implications? In addition, does this somehow conflict with some fundamental way on how DNS and name resolution is supposed to work?
Note: I originally asked this question on Network Engineering SE and was kindly referred over to this site as a better place for this question.

What are the problems with using a live top-level domain for internal name resolution?

You may find yourself unable to reach real hosts belonging to the real organization registering that domain in the future, because your DNS queries will be short circuiting that access.  You may also leak queries reflecting internal organization (server names) in some circumstances (e.g., a laptop "off the network" querying public DNS instead of corporate DNS).

Specifically, what are the security implications?

If you have systems somehow querying "real" DNS, they'll either leak dns names and/or be potentially redirected to hosts they didn't intend to go to.  That could lead to credential leakage as a worst-case scenario.

In addition, does this somehow conflict with some fundamental way on
how DNS and name resolution is supposed to work?

Well, it's bad manners, and any breakage that resulted would be well-deserved.
See this answer for a list of TLDs that are safe for private use.


Recommended Cipher Suites for TLS 1.0, 1.1 and 1.2 There are a lot of cipher suites defined in the in the specifications itself of TLS 1.0, 1.1 and 1.2. And furthermore, there exist RFCs which add even more cipher suites to a specific version (e.g. RFC 4492 for ECC or RFC 4132 for Camelia).

Is there an official organization like for example NIST or BSI Germany that has a list which cipher suites are considered to be safe? Or are all cipher suites offered by a specific TLS version safe to use?

NIST maintains "Special Publication SP 800-52" for guidance with regards to TLS usage. On April 2014 was published SP 800-52 Revision 1.

There are a lot of combinations of options, which cannot be readily shortened into an answer; you have to read the document to see what NIST really wants. See sections 3.9 (for servers) and 4.9 (for clients) for summaries of the NIST recommendations. Some highlights:

NIST requires TLS 1.1 support, with TLS 1.2 being warmly recommended. SSL 2.0 and 3.0 are explicitly forbidden. TLS servers for "government-only applications" are required NOT to support TLS 1.0 either (so they really want to force usage of recent versions). Sysadmins are expected to "develop migration plans" for a general support of TLS 1.2 no later than January 1st, 2015 (so NIST is even in kind of a hurry)(I don't believe it will really happen so soon, though).
They drop static Diffie-Hellman (nobody supports that anyway) and they finally embrace RSA. 2048-bit or longer keys, of course. ECDSA is also acceptable, using the P-256 or P-384 standard NIST curves.
They recommend ECDHE cipher suites (and they much prefer ECDHE over DHE).
Encryption shall be 3DES or AES. 3DES support MUST still be maintained (they insist on it, "for interoperability reasons"; one must assume that there still are a lot of deployed systems which do not support AES cipher suites).
When using TLS 1.2, use of AES-GCM is, of course, recommended.
They include an appendix which talks about Certificate Transparency, DANE (DNSSEC), Convergence... but they don't emit specific recommendations.
There is not a single word, good or bad, about SRP. They do talk a bit about PSK cipher suites (and they recommend not using them).


Is it more secure to install an application in .exe form from official website or in UWP form from Microsoft store? Many programs are available both in .exe form and in UWP form from Microsfot Store.
From a security point of view, shoud I prefer to download from official website .exe,checksum it, check for https connection etc. or just install it via MS?

If it's a huge website, well known, then they probably have good enough security, even a hash maybe, and you won't download a compromised version. If it's a not so well known website, then you are at risk.
From what I recall, when you upload an application to Microsoft Store, they check it for malware and only the owner could upload a new version (scanned as well). IMO Microsoft has a pretty good security. This is the way I would choose.


Guest wireless network is directly connected to internal LAN. How bad is this? At my work, there is a wireless network that is on the same subnet as the servers, printers and user machines. This wireless network allows users to have access to shared network drives as if the users were on the LAN. The wireless network is given out to guests that come to the company for any period of time.

What type of impact can this have on the company's IT? I already know the security aspect, as anyone can bring in their infected laptop and connect to the environment then from there it could spread to the servers as they are all on the same subnet. What other impacts can this cause?

Can someone not on the domain get the wireless access and get access to the network drives or access the server itself? If so how would they go about doing this?

That is for sure an insecure way to proceed. As I think you know, the wireless network should be separated from the wired domain network. And of course the wireless guest network should be an isolated different one only with internet access (it depends of what your guests need but usually is only internet access).

You can be victim of many different attacks. You can be victim of "layer 2" based attacks like ARP spoofing or starvation attacks. Do you have good network switches with port security or similar? I guess no, so your network is a very good "practice field" for some skilled hacker.

Another tipical attack for Active Directory is a pass the hash attack. It can be easily done if a NTLM hash was previously sniffed and that seems very easy on your network. Using that attack, somebody can easily access to the network shares. The same for the pass the ticket attacks which is he same but for Kerberos authentication.

Definitely, that is a bad design network regarding security but for sure is a very cheap option. I guess is a small company with a limited resources. Anyway could be a good practice to warn then about this and then the company should evaluate the risk in order to proceed (or not) with some changes.

In may opinion (but this is absolutelly personal) the security is one of the most important elements for a company even if is a small one.


Software Icons safe? I recently heard about these Adobe Icons that someone made for some of the best free and open-source applications on a Ubuntu based news site.

"http://www.omgubuntu.co.uk/2016/04/adobe-style-icons-for-gimp-and-inkscape"

They are .svg file icons.

I've read up some on how different images can be malicious and was wondering if this is possible with these icons.

The directions give the following steps:

Step 1: Copy the SVGs to any directory you like. I recommend placing them
in a directory which you're unlikely to mess with. Never rename, move or
delete the icons.

Step 2: Go to Computer/usr/share/applications.

Step 3: Right-click on 'GIMP Image Editor' in the directory (or any of the apps
we support for that matter) and select 'Copy'.

Step 4: Open the Terminal and type this:
sudo gedit "Paste the thing that you copied in Step 3"
(without the inverted commas)
Hit Enter and type in your password.

Step 5: The .desktop file of the app will open in Gedit (a simple text editor).
Just find the line that begins with 'Icon=...'

Step 6: Minimize Gedit and go to the directory where you pasted the SVGs.
Right-click on the respective file and select "Copy".

Step 7: Return to Gedit. Remember the line I mentioned in Step 5? Just go
that line, delete whatever is written in front of "Icon=" and hit 'Paste' there. The
address of your SVG should get pasted there.

Step 8: Just hit 'Save' in Gedit and you're done!

I went to virustotal and uploaded the file.

Not a single one of them detected anything.

I want to hear what you guys have to say. Should I do what the directions state?

And as always thanks! :)

I've read up some on how different images can be malicious and was wondering if this is possible with these icons.

Theoretically. But the instructions you quote are for replacing the displayed icon with the one in the SVG, which is harmless. At most you can mark the Gimp with a Calculator icon and mess with people that way; hardly a "vulnerability" if you ask me.

My desktop manager does not interpret Javascript in the SVG, which could (and has been) a vulnerability, nor does it attempt to open the referring schemas (which could be used for clickverting campaigns or even DDoS, if one succeeded in distributing bazillions of forged SVGs and induce people to adopt them).

The reason why VirusTotal did not classify your SVG as harmful is because it isn't:

<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   [...other namespaces...]
   width="64px" height="64px" id="svg3765" version="1.1"
   inkscape:version="0.48.4 r9939" sodipodi:docname="gimp.svg">
  <defs id="defs3767" />
  <sodipodi:namedview id="base" [...sodipodi properties...] />
  <metadata id="metadata3770">[...metadata in RDF format...]</metadata>
  <g id="layer1"
     inkscape:label="Layer 1" inkscape:groupmode="layer">
    <rect id="rect3773"
       style="fill:#00222b;fill-opacity:1;stroke:#00ccff;stroke-width:3;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
       width="61" height="61"
       x="1.5" y="1.5" />
    <g id="text4283"
       style="font-size:144px;font-style:normal;font-weight:bold;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#00ccff;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Myriad Pro Bold Italic">
      <path id="path3064"
         d="m [...graphic path...]"
         style="font-size:61px;font-variant:normal;font-stretch:normal;fill:#00ccff;font-family:Myriad Pro;-inkscape-font-specification:Myriad Pro Bold Italic" />
      <path id="path3066"
         d="m [...graphic path...]"
         style="font-size:61px;font-variant:normal;font-stretch:normal;fill:#00ccff;font-family:Myriad Pro;-inkscape-font-specification:Myriad Pro Bold Italic" />
    </g>
  </g>
</svg>


How can releasing the text of an SQL query compromise security? I have asked a government agency, under Freedom of Information legislation, to release two SQL queries they ran to produce a table which they published in a report.

That is, the agency published these two tables of figures showing, for each year, the number of cases completed under various categories and some aggregated statistics for each category. I want to see the query used to generate each table, in order to see how the data was filtered and precisely how the agency defined each category.

The agency has refused my request on the basis that releasing any SQL queries will prejudice their information security.

Under the relevant legislation, I now have the opportunity to apply for a review of this decision, in which I would have to explain why the agency's reasoning is flawed.

To my mind, the only way this could possibly be a security risk is where an attacker uses the information about table and column names to launch an SQL injection attack. However, the database in question is an internal data warehouse with no publicly-accessible web applications accessing it and, in any case, the agency has strict coding standards and penetration testing, etc, for preventing things like SQL injection vulnerabilities.

I can also imagine that if the agency was, say, the US National Security Agency, and the database was called 'overseas_phone_taps_by_country', then the table/column names would themselves be sensitive information. In this case, however, we are talking about an accounting database held by a pretty boring regulatory agency.

Again if the query was one used to generate lists of cases, then I could see the issue, since the query would contain things like the threhold at which a case will be considered for enforcement action, etc. However, that is not the case here.

How could releasing the text of an SQL query be a security risk?

EDIT: The agency provided the following explanation in their refusal letter:

  SQL queries contain information about the agency's information systems
  (information related to the content, location and storage of sensitive
  information), which, if released, could reasonably be expected to
  increase the risk of compromise to the agency's information systems.

  As such, I consider that disclosure of the SQL queries represents a
  potential security risk to the agency.

The advice from the agency's security expert reads:

  I am of the opinion that the release of the SQL queries, even in a
  redacted form, would provide information about the programmable
  interfaces and logic flow within our systems, and give information
  about identifiers, pointers and references that would compromise the
  security and safety of the agency's systems.

They probably have a DBA who has been told that you shouldn't let people know the structure of the database due to SQL injection risks.  As you mention though that doesn't make a ton of sense for an internal database.

There's no obvious risks to releasing a query from a security standpoint.  What was their exact wording of the reason they refused it?


Buzzfeed just downloaded a binary file to my PC, unasked The file is binary, named '96748', and it's 12.8kb in size. Ubuntu thinks it's an swf. Thank god I was in a Linux VM and not Windows. It doesn't seem to have done anything, and it's just sitting there in my downloads folder.

This is the URL (don't visit in Windows) h**p://www.buzzfeed.com/elliewoodward/orlando-bloom-tried-to-punch-justin-bieber-after-a-scuffle-i

Does anybody know what this could be? Is it malicious?

How can I investigate further into it to see what it may be? I already cat'd it to look for strings and there was nothing.

You could try (if you haven't already done so) Virustotal, which provides a service for scanning URLs or files for threats.


Store password securely but being able to check separate characters in that password I am writing a system where the user must log in with two passwords: a normal password (salted and hashed, stored in database), and a special password where the user needs to type only some letters, e.g. "please type the second, third and last letter of your password".

How can one design that system to support the second password?

Idea 1: store the password in plaintext. Of course not.

Idea 2: Store each character separately, salted and hashed. Bad because if the attacker knows the salt, it only takes a few dozen guesses to bruteforce the character.

Is there any other way?

Clarifications:

The two passwords have to be typed at the same time, like so:

The purposes of the second password are:

Defeat the attacker who looks over your shoulder while you type the password, or a keylogger.
Defeat the password manager in your browser, when someone like your family member can log in to your account if you chose to save your password in the browser.
Provide a simple alternative to 2FA when the user is not accessing extremely sensitive information, so we don't bother them to retrieve their hardware one-time password generator (which they also have).

You can't - at least not in software, for reasons given by Matthew.

If you have a five character password with a-z, that's 26*26*26*26*26, or 11881376 possibilities. However, if you can probe one character at a time, it's 26+26+26+26+26, or 130 possibilities.

Even for long, complex, passwords this reduces the amount of work that has to be done to trivial levels.

In addition it's bad security. People should use password managers, to have unique passwords everywhere. Password managers do not support this kind of queries. And even if it's a typed password, it's difficult, as many people rely on muscle memory to enter passwords. I wouldn't be able to give you the third character of my password without typing it out and checking.


What does %APPDATA%\GnuPG\secring.gpg contain after invoking "gpg --card-edit generate"? For a new smartcard (crypto stick), I've invoked gpg --card-edit, performed the generate command and selected to not create any backup of the generated keys. After key generation has finished, a %APPDATA%\GnuPG\secring.gpg file has been created and gpg --list-secret-keys gives me following output, no matter whether the smartcard is attached or not:

C:/Users/myaccount/AppData/Roaming/gnupg/secring.gpg
-----------------------------------------------
sec>  2048R/A076E602 2017-03-16
      Card serial no. = 0005 00003547
uid                  My Name <my.email@mydomain>
ssb>  2048R/94D78957 2017-03-16
ssb>  2048R/8C953787 2017-03-16

When removing this file, restarting gpg-agent.exe, reattaching the smartcard without entering the pin, and performing gpg --card-status the same file is recreated.

To me this looks like the secret key is copied over to my harddisk again and again?

GnuPG stores a key stub, when you interface smart cards. OpenPGP smart cards only contain the raw key data (and key ID), but no user IDs, certifications, settings and other attributes which must be stored locally or fetched from the key server network. Furthermore, this key stub makes GnuPG aware of the card even if it is not plugged in, so it can inquire you to provide it if necessary.

This key stub contains everything but the private keys, which will never leave the card (private key operations are performed by the card instead).

If your keyring is still in the old keyring format (not the new keybox format introduced in GnuPG 2.1 for newly generated keyrings), you can also peak into the keyring using gpg --list-packets C:/Users/myaccount/AppData/Roaming/gnupg/secring.gpg or pgpdump, which provides more flags to specify the output verbosity and can also print the raw key data. Both tools are very technical and require rather intense knowledge of RFC 4880, OpenPGP for understanding the data.


Best practice to encrypt data in an Android application I'm writing an application which recovers statistical data about a user. I'm still pondering about what would be the best way to encrypt the data. I haven't got any experience with mobile applications. But I was thinking of hardcoding an RSA public key and encrypting it in that way before sending it over the net.

Another guy working on the project suggested AES and hardcoding the pass phrase, but that seems to be a bad approach to me as a hardcoded password might be found through decompilation of the program. (I doubt someone would do it but just in case).

Are there any other approaches which would be better suited (setting up a ssl connection is not an option unfortunately) ?

I'm also still thinking about how I could provide integrity, I was thinking of hashing the file and then zip the whole package of message + hash into one file before encrypting it. If you have a better solution please feel free to share.

I'd just use SSL with a hardcoded public key of the server. Nobody on the way can manipulate or read what you sent. No need to invent your own protocol.

But of course the user himself can manipulate and read the data this way, but solving that is a DRM problem and not a security problem.

I believe BouncyCastle can be used for that Android. I prefer TLS 1.2 with a DHE AES128 based ciphersuite, but depending on what your server supports, you might need to downgrade to a lesser suite.


Is it possible to "read" secure (using SSL or TLS) messages if you know the message? If I am communicating over a secure line (secured using SSL or TLS) and I send the server a message.

Could someone eavesdropping tell what that message was if they knew before hand a list of messages I am likely to send.

E.g. I send a message saying "Execute order 66" over a secure line. Someone was eavesdropping and suspected that I was going to send this order. Could they verify that I just sent that specific message by comparing the sent message with the same message encrypted with the same public key.

No, SSL uses a symmetric key so an attacker is unable to decrypt the message he has just captured.

However, SSL is vulnerable to a traffic analysis attack. E.g. If you have 2 messages of very different lengths like

"Execute order 66"
"This is a very very very very very very very very very very very very very very very very very very very very long message".

If the attacker knows that the message has to be one of the 2. Based on the length of the encrypted message, he will know which message you sent out.

More info on traffic analysis attack:
http://webcache.googleusercontent.com/search?q=cache:KKy5MbfirYkJ:https://www.cs.berkeley.edu/~daw/teaching/cs261-f98/projects/final-reports/ronathan-heyning.ps+&cd=4&hl=en&ct=clnk&gl=us


Detecting if an agent is listening to specific messages Is there a way to detect if an agent Z is listening to (and acting on) messages from Y? I can observe the messages that Y sends and the actions that Z takes, but I know Z is also listening (and acting on) other messages that I do not observe. I do not need to know how Z takes its actions, just that if sometimes it listens and acts on the messages received from Y or not.

For example say that Y can send either a 1 or a 0. Z can do one of four things say a,b,c,d. I can observe, the messages sent by Y and the actions taken by Z. But I have no information about what else is being sent to Z which effects the action of Z.

To my mind this has some similarities to steganography detection. Is Y sending messages with hidden instructions to Z? Zs actions are a function of the messages and other unknown factors.

You could run a statistical analysis.

If messages from Y and behaviour observed in Z are uncorrelated, then the frequency of behaviours by Z conditioned by message Y0, Y1, etc. will be the same.

You would also need to run correlations on time-delayed and message-delayed hypotheses, as well as multiple-message correlation, i.e. Z(Y(n), Y(n-1), Y(n-2)).

For example, the pair of messages ("SIMON SAYS", "(something)") and ("(whatever)", "(something)") will see, in the first case, a strong correlation on the second message, in the second, no correlation at all. Overall correlation on just (something) will be weak. Correlation on message pairs will be strong, leading to the conclusion that "SIMON SAYS" primes Y to obey the next message.


What credentials does this hardware device steal? I was reading about this device the author made, however he did not specify WHAT he was able to steal from a locked computer.

What credentials does this steal?

https://room362.com/post/2016/snagging-creds-from-locked-machines/

The article mentions that Responder is used, which is a tool for grabbing NTLM hashes from a variety of Windows protocols using LLMNR/NBT-NS/mDNS poisoning.

Basically, it takes advantage of the fact that many background connections are made by Windows, most of which rely on an identification/resolution protocol that has no guarantee you are talking to a legitimate server.

The same can also be done with a $10 Raspberry Pi Zero (or similar). Take a look at PoisonTap as well.


Why return successfully to non-allowed origins As I understand it, with CORS, on cross-origin requests, the browser will send an Origin header, and if the origin isn't allowed, the server will still send back a 200 response with a non-matching Access-Control-Allow-Origin header (or a response that simply lacks that header), and leaves it to the web browser to block the response from the page.

My question is, why wouldn't the server be responsible for detecting the non-allowed origin and return a 403 response instead? Wouldn't you want to block the content from being provided further upstream?

As an example,

var xhr = new XMLHttpRequest() ;
xhr.open( 'GET' , 'https://www.bing.com' ) ;
xhr.send() ;

CORS does not work like you describe. It does not transfer data to the client which can not be transferred without Javascript. Every request which can not be achieved without Javascript is subject to the policy and the browser will check the CORS policy before doing such requests. In detail:

For simple requests any cross origin access is allowed. Simple requests are the ones which could also be triggered without Javascript by including image cross-site, submitting a form etc, i.e. these are XHR requests without special headers or methods.
For any other requests (like XHR with custom header, methods different from GET, HEAD and POST) a preflight request is done to get the CORS policy from the server. And only if this policy would allow the intended requests it is actually executed.

For more details see Mozilla: Cross-Origin Resource Sharing (CORS).

Sure, one might argue that a modified browser might simply ignore the CORS policy and request the content anyway. But, a modified browser might also send a faked Origin header to trick the server into providing the data. In other words: CORS is not a replacement for authentication. It is instead intended to allow cross-site requests using Javascript  without adding additional vectors for CSRF attacks. Before CORS cross-site Javascript XHR was forbidden and insecure ways like JSONP were used.


Username Enumeration as a Threat I have found a Username Enumeration Vulnerability through which I am able to determine whether a particular user is registered with that site. While trying to brute force, after 5 attempts it asks for a CAPTCHA code. I have tried several methods to bypass the CAPTCHA but I'm not able to bypass it. So, now the situation is, I can find a particular username but cannot brute-force it. So,my question is, is this is considered a bug?

Yes this is a legitimate security issue, but less severe than most. Consider these circumstances:

Any users with the top 5 most common passwords are toast. For example, Password1! from a lazy user may be the most likely password to meet this company's password strength requirements.
Additional data could be associated with known usernames.

For example, if my username is examplesmith, and you find examplesmith@gmail.com, there's a good chance this is the same person.

Additionally, you can search online and quite possibly find this person's Full Name, or even Cell Phone and Mailing Address.

With additional information associated (advanced), you can send some rather convincing Phishing emails. At the very least you can include the username (simple) in the Phishing email to make it more convincing.

Even unsuccessful Phishing attacks can reduce user confidence in the company's system.

So as you can see, knowing which Usernames are valid is not serious by itself, but can be helpful to perform other types of attacks on the system.

As @Marcel states, OWASP recognizes this as a legitimate issue.

Whether or not this particular issue is acceptable depends on the nature of this company's services.  (i.e. ok for simple gaming sites, but never for online banking)


dm-crypt/LUKS: one-time password I've setup arch using dm-crypt / luks, with a passphrase and a key, lost one of them will fail to login.

But I feel I need more secure of passphrase, how to setup dm-crypt / luks that has one-time passphrase mechanism?

Setting up a OTP is probably not something you can easily and securely do. There are other options to solve your problem -

LUKS supports up to 8 simultaneous passphrases. You can fairly easily set one of these to something different,long, complex and obscure (or a key file) and put it in an offsite secure location.

Similarly, if you take a copy of the LUKS header (which has other benefits) you can set the header with a different initial key to the regular keys, and then restore that - this would alloe the key and header coy to be stored in different locations to make it harder to compromise. See https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/ on how to save the header and use multiple passphrases/keys


Should stored XSS prevention be client or server-side? What is the best way to prevent stored XSS?

should every text field (even plain text) be sanitized server-side using something like OWASP Java HTML Sanitizer Project?
or should the client protect itself from XSS bugs by applying XSS prevention rules?

The problem with the first solution is that data may be modified (character encoding, partial or total deletion...), which can alter the behavior of the application, especially for display concerns.

Normally for XSS prevention we use html escape character in order the validate the input character or input. According to OWASP here are some of the things that you must follow:

For client side and server side:

Escape character before processing the given input.
Better use security encoding library.
Do not enter untrusted data except in allowed location.
HTML Escape Before Inserting Untrusted Data into HTML Element Content
Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
HTML escape JSON values in an HTML context and read the data with JSON.parse
CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values
URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
Sanitize HTML Markup with a Library Designed for the Job
Prevent DOM-based XSS

For server side:

Use HTTPOnly cookie flag
Implement Content Security Policy
Implement and configure WAF like Mod security.
Use the X-XSS-Protection Response Header

There are other prevention measures. You can check this link to get more detailed information.

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet


Is hacking Wi-Fi THAT easy? (just spoof, and it's hacked?) Suppose I have a Wi-Fi with WPA and strong password. Some articles say, that if an attacker will create a Wi-Fi with my SSID and it's signal is stronger than my, then my computer will connect to his Wi-Fi. Do I understand it right, that after it my computer will send Wi-Fi password to attacker, and he also will be able to do MiTM attack?

Is it really that easy?

Why there isn't something like certificate check in WPA protocol?

How can I protect from it?

No, it is not that easy. But it depends on the network.

First, most Wi-Fi devices will remember all Wi-Fi networks they connect to, and also whether that network is encrypted or not and using which method. When your device comes near a network it "knows" (by its name, i.e. its SSID), it will try to reconnect, if that network's security method matches the saved one. What happens next will depend on the kind of Wi-Fi network.

Open, unencrypted Wi-Fi networks

When a Wi-Fi network is unencrypted (like most "Free Wi-Fi" networks in cafés, bars or hotels) and you have already been connected to that network once before, your device will automatically reconnect to a network with the same name. Anyone can spoof a well-known "Some Coffeemaker Free WiFi" and your device will happily connect to it when encountered. The rogue access point (AP) will then see all traffic your device sends or receives over this network (but cannot look into HTTPS or VPN encrypted traffic, of course).

WPA2 networks with pre-shared keys (WPA-PSK)

When using WPA2 authentication with pre-shared keys (PSK), both the station and the AP have to prove that they know the PSK in the four-way handshake. Thus, a rogue WPA2-AP cannot give access to a client by just having the right SSID and accepting any password from the client. Your device will not associate with that AP unless it uses the same PSK.

AFAIR, this is also valid for authentication with WPA version 1 and even WEP, but those protocols have other weaknesses which make them non-recommendable or even useless.

On the other hand, everyone who knows the PSK could fake a WPA2-AP. A weak PSK could also be guessed in a brute-force attack, e.g. by repeated authentication attempts. Hence, a long, not-guessable PSK is necessary.

(There is also an attack called Hole 196 that can be used by already authenticated attackers to break the session key of other authenticated hosts with the AP, but this is not relevant here.)

WPA2 Enterprise networks

WPA2 Enterprise works similar to WPA2-PSK, but uses a dedicated authentication server. In addition to passphrases, it can use certificates on client and AP. Client certificates are like long, authority-signed passphrases which are different for every client device. This way, when a host is compromised (e.g. stolen), that particular client certificate can be blocked on the authentication server, instead of changing the PSK on all devices.

For your device it makes no difference if WPA2-PSK or WPA2 Enterprise is used, in both cases it will not connect to an AP that cannot prove to have the necessary secret.