Security of starbucks gift card redemption feature Someone sent me a Starbucks gift card.  The email contained a redemption link, and that redemption link ended in a long secure hash, much like those on github secret gists.

Clicking the redemption link took me to a page with a single form field, asking me to enter the email address the link was sent to.  After entering my email, I was taken to a page showing the image equivalent of a gift card with the protective coating scratched off -- a credit-card-like number which, when entered or scanned into the starbucks app, credits your account with money.  That number, I believe, could have been entered by anyone to claim the cash.

My question is: Why ask me to confirm the email address?  Does that provide any additional security beyond the hashed link itself?  It seems to me the security is provided by the hash link, and if that link was compromised then in all cases my email address would be compromised too (eg, if someone had hacked into my email account, or read the email in transit).

Of course, in theory it is preventing a brute force attack from someone randomly guessing hashes, but the search space is so massive that it seems like an unnecessary precaution assuming the hash has been generated securely.

As far as I can tell, the idea is that even if the URL is leaked to somebody who's not you, your gift card is still protected.

Sure, it's fairly rudimentary especially since email addresses are by no means private, but generally theft of Starbucks gift cards isn't something a lot of people who could easily bypass the email validation would take part in.

And it probably makes people who aren't very security minded feel more secure.


BeagleBoneBlack, TPM and uBoot I'm using BBB in my project. I need to prevent any changes to the software running on it. I've been reading about uBoot and TPM. But if I understand everything correctly, this can't be implemented correctly, that is, in a really secure manner. I understand that during boot, each boot stage passes "something" to TPM, TPM hashes it with the previous value and stores the result in the proper register. But for it to work as expected, at least the first stage must be engraved in stone (or at least unchangeable by third party). This is not the case if the first stage (uBoot in my case) can be easily replaced and changed in such a way that what is passed to TPM is not what is executed later. This means that later stages can be changed (logic, data, anything) without TPM noticing them.

I believe there is a flaw in my logic or I failed to grasp some crucial detail, because AFAIK BIOS (first stage in aforementioned chain) can be overwritten with a new image, which means that an attacker with physical access to the machine could circumvent any security measures taken by the machine owner.

Where is the flaw in my thinking?

EDIT:
I read about BBB, uBoot and TPM here.
Also this question seems to corroborate my way of thinking

I understand that during boot, each boot stage passes "something" to TPM

That "something" is the SHA-1 hash of the component being measured. The first thing sent is the hash of the BIOS. Subsequent hashes cause a register to "update" its hash. The TPM only unseals if the final hash matches what it expects. That final hash will only match if all hashes sent to it prior were correct.

This is typically how it goes for a traditional x86 system with a TPM. A BeagleBone is similar.

The CRTM, which is read-only, sends the hash of the BIOS itself to the TPM.
The BIOS sends the hash of the option ROMs, MBR, and bootloader to the TPM.
The bootloader sends a hash of the kernel and boot parameters to the TPM.

If all the hashes were correct, then the final hash will match what the TPM expects. The TPM is then free to unseal, which means decrypt an arbitrary blob of data passed to it. This blob of data, when decrypted, proves to the sysadmin that nothing in the boot chain has been compromised. As long as the attacker does not know the contents of the decrypted blob, they cannot spoof it, even if they have tampered with the BIOS and have full control over how the system is to behave. This decrypted blob can either be used as a disk encryption key, or displayed to the sysadmin, indicating that it is safe to trust the firmware.

  I believe there is a flaw in my logic or I failed to grasp some crucial detail, because AFAIK BIOS (first stage in aforementioned chain) can be overwritten with new image, which means that attacker with physical access to the machine could circumvent any security measures taken by machine owner.

There is a part of the BIOS called the boot block, or CRTM (Core Root-of-Trust for Measurement), which is not writable by software. An attacker would need to have physical access to replace the chip which holds the firmware. The CRTM is in charge of sending a hash of the rest of the BIOS to the TPM. This prevents a privileged local (not physical) attacker from bypassing the root of trust by writing the BIOS.

See also How does the TPM perform integrity measurements on a system?.


Does Windows 10's telemetry include sending *.doc files if Word crashed? I'm reading through the extensive description on which data is acquired by Microsoft's telemetry 1 including the following paragraph:

  User generated files -- files that are indicated as a potential cause for a crash or hang. For example, .doc, .ppt, .csv files

I was wondering whether Microsoft actually gathers data from a Word document, in case word crashes (hope on being wrong on this one).

Is Microsoft getting the 'whole' file, only a paragraph or am I misreading that part of the documentation?

Here is what they spy on, finally officially admitted after being proved again and again by different independent sources. That should make a pretty good idea on what actually is transmitted.

To actually see what's being reported you can give yourself permissions for
%ProgramData%\Microsoft\Diagnosis directory and look what's in there, but the file are encrypted which is a very suspicious thing.

What you can look at in the newer version is the Diagnostic Data Viewer. But that does NOT guarantee or prove that there is documents privacy in any way.

At this point my guess is that they will transmit parts of files that generated crashes, or if they consider proper to do so and definitely can transmit any type of document via the encrypted content in \Diagnosis and https as the transmission way.

Their EULA states:

  Finally, we will access, disclose and preserve personal data,
  including your content (such as the content of your emails, other
  private communications or files in private folders), when we have a
  good faith belief that doing so is necessary to: comply with
  applicable law or respond to valid legal process, including from law
  enforcement or other government agencies;
  2. protect our customers, for example to prevent spam or attempts to defraud users of the services, or to help prevent the loss of life or
  serious injury of anyone; 3. operate and maintain the security of our
  services, including to prevent or stop an attack on our computer
  systems or networks; or
  4. protect the rights or property of Microsoft, including enforcing the terms governing the use of the services - however, if we receive
  information indicating that someone is using our services to traffic
  in stolen intellectual or physical property of Microsoft, we will not
  inspect a customer's private content ourselves, but we may refer the
  matter to law enforcement.

Conclusion: they can and will do it at will.


RDP violation without credentials On a Windows Server 2003 machine seems like someone has logged in through RDP without using credentials: there is a logged access, but there are nor userid nor password.
I am wondering how is this possible, and I can't figure out a valid scenario, so I'm asking here.
This has been made by an attacker who then created an administrator account and re-logged in through his brand-new own-created account.

EDIT: ok, I now got the logs: in the Windows Event Logs there are some actions performed by a user that use a SID instead of a username. Those actions leads to a successfull login as sadmin, the renamed Administrator account, and that is the violation.
So he doesn't created a new account but he exploited the administrator one.

As Chris already mentioned, an exploit could be run against the RDP server, or another gained access via another service (Telnet, SSH, Apache Server, etc...). Whether this was via a zero-day exploit or a brute force attack, is another matter.

Two exploits come to mind though, CVE-2008-4250 and CVE-2012-0002. However, without logs, I cannot know for certain. Furthermore, my answer is restricted to remote access attack vectors. Physical attack vectors have not been considered.


Cardholder data segmentation for PCI compliance (3.2) We are currently collecting card holder data in a segmented way. Our system is used by call center agants which I will refer to as channel B

Over channel A (mobile carrier) we collect the first 8 digits of the credit card followed by the cvv. Now we are not in control of logging over this channel and they might log this in clear text.

Over channel B, agent collects the rest of PAN and expiry date.

We then reconstruct it to switch.

My Question is this, point 3.2 of PCI compliancy states you are not allowed to store cvv, but does this apply with segmented PAN? My argument is that you cant do anything with CVV without the full pan.

Here are the basic do's and dont's for PCI-DSS:

Regardless of segmentation you are not allowed to store the CVV data. The effectiveness of this code is limited to the ability to keep it out of the hands of criminals, which is why it is prohibited by PCI Standards from being stored. For merchants who charge customers on a recurring basis, the CVV code can be used with the initial transaction but cannot be stored for future transactions.

Now you have an argument, but consider there is a breach in your company and the CVV numbers are obtained and used together with card numbers collected in a breach from company B, then guess who will be held accountable as they did not adhere to the PCI-DSS standard.

The rules for PCI-DSS are not only there to give you guidance on how to store information but also serve as a way of off-loading risk from the card acquirers to the merchants.  Maybe you might think that it's not fair, but in case of PCI-DSS: "The rules are the rules". The only way you would be able to avoid this risk is  by having a QSA sign off on your implementation and explicitly have your architecture where you store the CVV as part of the audit report (to be fair I highly doubt any QSA will sign off on that).


Should I change the default SSH port on linux servers? Is there any advantage in changing the SSH port, I've seen people do that, but I can't seem to find the reason why.

If you have a strong password and/or a certificate, is it useful for anything?

Edit:

I should also mention that I am using iptables rules to limit brute forcing attacks, only 5 login attempts are allowed per minute per IP address.

The Internet is a wild and scary place, full of malcontents whose motives range from curiosity all the way to criminal enterprise. These unsavories are constantly scanning for computers running services they hope to exploit; usually the more common services such as SSH, HTTP, FTP, etc. The scans typically fall into one of two categories:

Recon scans to see what IP address have those services open.
Exploit scans against IP addresses who have been found to be running a specific service.

Considering how large the Internet is it is typically infeasible to look on every port of every IP address to find what's listening everywhere. This is the crux of the advice to change your default port. If these disaffected individuals want to find SSH servers they will start probing each IP address on port 22 (they may also add some common alternates such as 222 or 2222). Then, once they have their list of IP addresses with port 22 open, they will start their password brute force to guess usernames/passwords or launch their exploit kit of choice and start testing known (at least to them) vulnerabilities on the target system.

This means that if you change your SSH port to 34887 then that sweep will pass you on by, likely resulting in you not being targeted by the followup break-in.

Seems rosy right? There are some disadvantages though.

Client Support: Everybody who connects to your server will need to know and use the changed port. If you are in a heavily managed environment, this configuration can be pushed down to the clients, or if you have few enough users it should be easy to communicate.
Documentation Exceptions: Most network devices, such as firewalls and IDSes, are pre-setup for common services to be run on common ports. Any firewall rules related to this service on this device will need to be inspected and possibly modified. Similarly, IDS signatures will be tweaked so as to only perform SSH inspection on port 22. You will need to modify every signature, every time they are updated, with your new port. (As a data point there are currently 136 VRT and ET snort signatures involving SSH).
System Protections: Modern Linuxes often ship with an kernel layer MAC and/or RBAC systems (e.g. SELinux on RedHat based or AppAmor on Debian based) and that are designed to only allow applications to do exactly what they're intended to do. That could range from accessing the /etc/hosts file, to writing to a specific file, or sending a packet out on the network. Depending on how this system is configured it may, by default, forbid sshd from binding to a non-standard port. You would need to maintain a local policy that would allow it.
Other Party Monitoring: If you have an external Information Security division, or outsource monitoring, then they will need to be made aware of the change. When performing a security assessment, or analyzing logs looking for security threats, if I see an SSH server running on a non-standard port (or an SSH server on a non-UNIX/Linux for that matter) I treat it as a potential backdoor and invoke the compromised system part of incident handling procedure. Sometimes it is resolved in 5 minutes after making a call to the administrator and being told it's legitimate, at which point I update documentation, other times it really is badness that gets taken care of. In any event, this can result in down-time for you or, at the least, a nerve racking call when you answer your phone and hear, "Hi, this is Bob from the Information Security Office. I have a few questions for you."

Before changing your port you need to take all of this into account so you know you're making the best decision. Some of those disadvantages may not apply, but some certainly will. Also consider what you're trying to protect yourself against. Often times it is simply easier to just configure your firewall to only allow access to 22 from specific hosts, as opposed to the whole Internet.


Is array injection a vulnerability and what is the proper term for it? When I'm penetration testing I sometimes notice undesirable behaviour of a PHP script when I inject a single or multidimensional array using the HTTP GET parameters.

Possible availability risk

This can cause an availability risk, especially in case of a multidimensional array injection when a PHP script is recursively looping through a (deep) multidimensional array and there is no or a high limit on execution time. Because this can cause resource exhaustion. Practically this can be the case when the whole $_GET array is looped through to apply some kind of filtering or validation.

Questions regarding this behaviour

What would be the proper term for such a vulnerability? "Array injection"?
In what vulnerability category does this belong (for example in the OWASP Top 10 or CWE list)?
Is this, other than the availability risk, considered to be a vulnerability?
What is a good scenario wherein this can be exploited?

Example of behaviour

Input: (expect string as parameter)

/search.php?query=test

Result: (in PHP's $_GET)

[query] => test

Input: (injected array)

/search.php?query[]=test

Result: (in PHP's $_GET)

[query] => Array
(
    [0] => test
)

Input: (injected multidimensional array)

/search.php?query[][][][]=test

Result: (in PHP's $_GET)

[query] => Array
(
    [0] => Array
        (
            [0] => Array
                (
                    [0] => Array
                        (
                            [0] => test
                        )
                )
        )
)

I think the term HTTP parameter pollution would be the best fit. This type of pollution usually submits the same parameter multiple times with different values in the same request. This results in the parameter being treated as an array of values with the parameter name as the array name as described in this article. The way the web server and programming language handles these arrays compared to the single value is what this bug class exploits.

Your examples similarly cause an array with the same name, although through a different method to repeating the parameter, but it seems like a better fit compared to other terms like fault injection or type confusion.

While this type of pollution usually exploits undefined behaviour, the examples you have provided would not. They would cause defined behaviour for handling an array. This may still trigger exceptions which could be used to alter the flow of an application, such as erroring out before a authorisation check changed your session resulting in a privilege escalation.


Is an 8 characters long password reset token strong enough? I am testing a website with a password reset functionality that provides a link with a token like most websites. I asked for multiple password reset links to see any pattern in the tokens. All the tokens had 8 characters, all alphabetes capital and small, no numbers or special characters.

Would you consider it a weak token? If so, how long would it take to brute force such a token considering you have a good computer and internet?

Also, with each account it appears that a password reset token is attached. It never changes no matter how many times I ask for password reset link - it always comes with the same token for that particular account. Wouldn't you consider that a vulnerability?

all the tokens had 8 characters, all alphabetes capital and small, no numbers or special characters

This is on the edge of acceptable.

It isn't easy to compromise an account this way. In an online brute-force attempt you can typically try between 10 and 100 tries per second. A random eight character password like you describe has 53459728531456 possibilities. Brute-forcing all the possible passwords would take 16951 years. So this isn't really a feasible attack.

But it could be improved. If the token is sent in an email and the user doesn't have to type it in, there is no reason not to make it a little bit longer.

  it never changes no matter how many times i ask for password reset link

This is suspicious. Normally, a password reset token expires after some time, or after it has been used. In your case, it doesn't seem to expire at all. This means that once a token or account has been compromised, it is not possible to recover from this: the attacker can keep resetting the password if he knows the token.


JSON Web Token Security I've been working with JSON Web Tokens and reading up on how to make an app more secure. When a user is a authorized, the token is signed, and a token will be placed in the Authorization Header. This token can then be placed in localStorage, sessionStorage, or cookieStorage. The last option came out top to be the most secure option, but I was wondering if any features of a JSON web token, or any middleware, or perhaps JSON Web Encryption (not really sure how this works) that would prevent a malicious attacker from intercepting/grabbing that token, and using it for future requests to the app's APIs, since all that's needed is a request with that token for a dumb server to respond for the information requested.

Send the token over TLS.
Sign the token with a couple of private/public keys (i.e. RSA, ECDSA) to prevent tampering (You don't use a secret shared!).
If your token gets stolen, the attacker can only use it for a short period of time. You can set the expiration time to 15min.
JSON Web Encryption (JWE) provides confidentiality of content. You can use asymmetric cryptography to send confidential content. See this example.


Does Perl's unpack function have format vulnerabilities? I'm using Perl for the first time for production software and I have some trust issues with it. When I use the unpack() function, is it safe to use user input in the TEMPLATE string? I'm using a TEMPLATE like "Z$user_controlled" to read a string value to a variable. The constant $user_controlled is defined external source that the user can control. Am I taking a risk? Can an attacker do something bad if he changes the TEMPLATE string into something weird?

EDIT: Changed the wording to be more generic.

The "p" template parameter will interpret its part of the input string as a memory address (available to the Perl interpreter's process), and copy all characters from that address, up to the next null character, into the returned string. This might also cause a segfault/access violation if memory at this address is not readable.

The "P" template parameter is similar, but the length of the copied string is fixed, and provided in the template.

These parameters exist to allow access to data outside of the input string, so you should probably check into how they could be abused on your platform.


What are the security features of JRE 8? I was tasked with finding the security features of JRE 1.8 and compare it to JRE 1.7 update 51.  When I try to look for new security though, it only shows ">JDK< Security Enhancements" (ie. Not ">JRE< Security Enhancements") for 1.8.  Is that what I'm looking for?  If not, is it ever documented?

So, I'm just looking for the Java Runtime Environment, since I'm not developing any programs in Java.  So, are those JDK Security Enhancements the "security features of JRE 8" that I am looking for?

I ask here because "security features" felt so broad that I did not know what to start looking for.  I don't even know what to search in google.  I'm not that knowledgeable on Java at all.  Your help is appreciated.

JRE = Java Runtime Environment (meaning java.)
this will help you understand the differences between the different "versions", if you will, that java is listed/talked about.
https://stackoverflow.com/questions/250517/java-se-6-vs-jre-1-6-vs-jdk-1-6-what-do-these-mean

these should help you answer your questions:

http://www.oracle.com/technetwork/java/javase/8train-relnotes-latest-2153846.html

and

http://www.oracle.com/technetwork/java/javase/jre-8-readme-2095710.html


Risk of connecting found pendrives to USB ports At work we mostly use Windows 10, but some co-workers doing design work use Macs. Pen-drives lie around and the only way of knowing what's inside, is to stick it into a PC and read the content?

How high is the risk of getting viruses, backdoors, malware, etc into our computers?

What can be done to mitigate the risk, if high?

TLDR: The risk is very real.  It's the equivalent of giving someone with malicious a keyboard, a network interface, storage, etc... but not showing them the screen.

I think @eckes' comment sums it up nicely.  True, a USB-kill dongle is of course a real thing, but has indeed limited "damaging" aspects.

If properly setup, USB Dongles can mimic anything USB related (keyboards, NIC's, etc) or a combination thereof.  Tools such as the Hak5 rubberducky or Samy Kamkar's PoisoinTap show the possibilities.  It can siphon out information, implant malware, etc; which is a significant concern (data, operations-wise), wa more than physical damage.


Odd searches returned at the end of homepage url; possible to exploit? I'm penetration testing a website right now (they have a policy and a system for it), and I noticed that the search feature filters brackets.

After some messing around, I also noticed if you search this: <%20> it returns to the home url (example.com/home).

However, if you use this specific combination of characters: <&#anynumberorletterhere it will return the text after the ampersand in that home url. For example, if you search <&#hi it will go to the homepage with the url example.com/home#hi. It also returns special characters, such as !@#$%^&*() completely unfiltered.

I'm sorry if this isn't enough detail, but I don't want to expose any information leading to what website it is in particular. If you need more info, please just ask below.

Essentially I'm wondering if there's any reason to report this. Also, if you have a payload you would like me to test, I'd be happy to do so and tell you the results.

Based on the information in your original post there is a low likelihood this would lead to something useful in an attack. The hash fragment is not sent to the server.

However, the hash fragment can be used to direct to a named anchor or may be read by client side code. This is very common in single page application by using [location.hash][3] call. So it might be possible to exploit this with DOM-based / client side XSS. For example: maybe there is some logic based upon the hash or a script makes an AJAX calls based upon the hash.

In your example, when given example.com/home#hi does hi show up anywhere on the page or in the source (is the input reflected back in the page returned)? If so then there may be the possibility of structuring an XSS which will not be filtered.

However, the fact that it is returning the hash an appending it at all could indicate a bug in the backend and you may want to try other odd character fuzzing as you continue your testing. Since you mentioned other special characters are also not being filtered in the expected way this may be enough to get credit through this company's bug bounty depending on their rules.


Can auditd track events that occured over NFS I have multiple servers mounting a NFS shared called /opt/WHATEVER from Server X.

Server X has auditd enables with rule:
sudo /sbin/auditctl -w /opt/WHATEVER -p rwxa

When events occur on Server X on that folder, it works great. However, when any other machines accesses or change anything nothing is reported. Server X and others have the same path. i.e /opt/WHATEVER

How can you enable auditd to track events from NFS?

Much like recursion, in order to understand auditd you must first understand auditd. Auditd is the front-end to a kernel module that intercepts/monitors system calls and reports on them. That is to say, the -w option doesn't continuously perform an ls, md5sum, or similar on the target, it instructs the kernel module to report on attempts to perform file access calls, such as open() or creat(), on the target. Translating this information back to your question, this means that auditd can't detect changes being made by remote hosts in this way. Those system calls are occurring on the remote system.

To do the kind of monitoring you want you'll need to configure auditd on the remote hosts to monitor the nfs mount locally. What you should do then is log all the hosts running auditd to a central log host, using something like audisp-remote. Then the logs can be more easily searched and correlated.


What could be the scope of ISO 27000 standards? If a company wants to certify against some of ISO 27000-series standards (let's say ISO 27001 and ISO 27005), what could possibly be certified? I mean, is it IT processes in general in the organisation as a whole? Or is it more likely that only one/several system(s) used in that company is/are certified? OR does it depend on particular standard (let's say I am interested in the ones above)?

If a company has chosen some particular standard, can it be broken down somehow so that only a part of the standard is certified?

Of the ISO 27000 range of documents, only 27001 is a certifiable standard. The others in the range are guidance and advisory documents.

The first step of ISO 27001 implementation is defining the scope. In my experience it would be unusual to have "IT Processes" as a scope - it's usually defined by business area. So for example the Operations part of the business (excluding supporting business units, such as HR).

You can't be certified to part of ISO 27001. It's all or nothing.


Is it correct to consider Task Based Access Control as a type of RBAC? I'm studying for CISSP certification and one of the video lectures I viewed (CBT Nuggets) really confused me.  Here are some excerpts from the lecture:

"Role Based Access Control doesn't
always use the role for the basis for
how it's going to divide information
and access the information"
"Now let's get into, I guess the
easiest way to define it is the 'types
of RBAC' that you might see out there.
The first one is role based and that
one is the one that's naturally the
idea here because we're talking about
role based access control.  But what
I'm also going to say is that there's
also what's known as Task Based Access
Control, also called RBAC.  In other
words, the way we're going to divide
our groups or our containers is either
going to be by role or by task.

Is it correct to consider Task Based Access Control as a type of RBAC? That doesn't seem right and other resources seem to discuss it as an entirely separate access control framework (e.g. http://books.google.com/books?id=qf_h9ixAx70C&lpg=PA61&dq=RBAC%20TBAC&pg=PA61#v=onepage&q=RBAC%20TBAC&f=false)

There are some non-canonical (or non-"standard") access control models (besides the well-known MAC, DAC, RBAC...), that are simply not well defined.
As in, anyone can define or redefine them as they want, as long as the model makes sense.

E.g. this post was the first time I heard that model called "Task based access control", though I use/employ/review it a lot. Strangely, that book you linked to was the second time, in a different meaning...

I will point out that in many/most cases that use the model you called TBAC, it is aggregated back up into roles.
That is, the access is granted based on a task, but the access check then compares this task to roles that contain that task, and users that are part of one of those roles.
In other words, tasks can be seen as "sub-roles" - or if its easier, roles become role-containers, and the tasks are the real roles...
See e.g. Microsoft's AzMan tool.

Clearly, this is a huge improvement on straight RBAC, since it gives you some granularity and dynamics to play with, but it's still a form of (extended) RBAC.
Btw, I've also seen this called "Hierarchical RBAC", so...


Storing Credit Card Numbers I'll be making a website with a membership type of option for the website, and I'll be most likely using Authorize.Net to make the transactions, however, I need to know what kind of encryption I can use to store credit card numbers in a MySQL database?

Why even store it in a MySQL database when you can be using Authorize.Net's Customer Information Manager API and taking PCI compliance and security issues right out of your hands completely and letting them do all of the heaving lifting for you? CIM let's you create customer payment profiles by storing the customer's credit card information on their end and then charging against that profile at a future date whenever you need to simply by referring to the payment profile ID at the time of the transaction.


How do "certificates" hold "keys"? I am new to the realm of security and keep hearing about "certificates" containing "keys". But no one has been able to actually explain to me what is actually meant by this.

I assume that the cryptographic key is really just a numeric/alpha-numeric identifier that can be represented in plaintext. Yes?

Furthermore, I assume that a certificate is nothing more than a plaintext file literally containing 1+ of these keys. Yes?

If my assumptions are correct, can someone just please confirm them (I think that would be enormously helpful for future newcomers who are really trying to understand the fundamentals)? And if my assumptions are incorrect or mislead, can someone please correct them for me?

Yes they can be represented in plain text. both your assumptions can be true.

Most certificates usually follow the x509 standard based on RFC5280

A x509 Certificate can be represented in a PEM format - which is plaintext. It can include an entire certificate chain including public key, private key, and root certificates.

there are also other formats that exist like PKCS12 which may require a password as they can hold the private key.

If you are a newcomer, then the Link suggested by @BadSkillz is the best place to start.


What exactly is endpoint security? Would someone explain what endpoint security is, exactly? What do companies like McAfee and Symantec sell with their endpoint security suites?

I also would like to learn if endpoint security involves a hardware appliance which handles typical endpoint security. If both of these companies do sell a hardware appliance which runs AV and firewall applications, then does it use a MCU or SoC or is it just a single CPU processor core?

Endpoint security refers to the security controls of laptops or desktops to apply below controls:

Detect malicious activity
Application controls: example; Block malicious applications from running user from running
Privilege management: Remove local admin rights from users, Elevate privilege on-demand for authorized applications
Credentials theft protection: example Contain attacker to the endpoint limit lateral movement
Anti virus: run periodic scans on machines
Apply the latest Patches to OS and applications
Collect user logs

Some endpoint detection tools provide centralized management tool which allows the admin to monitor and manage all the users in one place.

A few examples on Endpoint security tool provider are: Forcepoint, Cyberark, Kaspersky


Does this strange string of letters indicate that my Outlook account has been hacked? After I sign in to my Outlook account, I am seeing a strange string of letters and numbers below my profile ID, for example (see also attached screenshot):

My account name:
Default-54914b26-XXXX-XXXX-XXXXXX@SCT-15-1-485-9-msonline-outlook-3c171.templateTenant

With regard to this issue, my questions are:

What is the meaning of this script/string? Is it some kind of certificate or encryption key to my account?
Is it indication that my account has been hacked?

Also, if you look closer at the screenshot I attached, you will note that my Outlook account no longer displays the green-lock icon (at top left of the screen), which normally signal a secure connection.

I have very strong feeling that this account has been hacked.

I contacted MS support team and multiple security experts, but no one has an explanation for what this is.

This does appear strange. It is something that the technical support people should know how to fix. (maybe they don't know, but they should)

It is possible that it was a setting in your account with this string. If that is the case you can change it back, and that is a clue your account was hacked.
It is possible this is due to a bug in their software, in which case this does not raise a direct security concern.

The icon change on the top left corner is not a serious issue, but obviously a completely green icon is preferable.

Have you tried from a different browser, or from a different computer?
Have you tried accessing from your smartphone on a completely separated connection?

These might raise helpful clues. Sometimes a plugin can alter the page contents, but still this seems very strange. It does seem more likely to be a bug at Microsoft.

If you suspect the account was compromised, (i.e. your password got out or something is logging all your actions and passwords) then you should:

Change your password.
If you think a virus has caused the password to get out, then a professional machine wipe is the safest option. However, sometimes a password is accidentally leaked by phishing (entering your Microsoft password on a Microsoft-look-alike-fake-site), in which case you would not need a machine wipe.
Using 2-factor authentication is a real boost in your security, but not a silver bullet.


Why Same origin policy is based on host-name and not on IP? Same origin policy is to restrict one page to access another document from accessing data. Because they have different origin where SOP define an origin as follows.

  An origin is defineed as protocol, host-name and port. If page or document is there then the SOP does apply to it if it matches these three.

I as wondering

  Why the SOP is based on a Host-name and not on IP address ??

If SOP is based on IP address what issues we will have. Currently SOP can be attacked using DNS where rebinding Attacker wants to gain access to network behind a firewall and abuse Time-To-Live of DNS to bypass SOP.

It is very common to have multiple domain on the same IP address and often these domains are controlled by different parties. This is both typical for cheap hosting and for CDN like Cloudflare. Having the same origin policy based on IP address only would make cross-domain attacks possible. This would still allow using both IP address and hostname combined as restriction.

Additionally the same domain could be hosted by multiple IP addresses, for example with geo-specific IP addresses or with DNS based load balancing (i.e. round-robin DNS). Restricting the SOP to a specific IP address for the same hostname would lead to unexpected behavior, i.e. sometimes requests within the same hostname work and sometimes not. Thus, restricting the SOP additionally to the IP causes reliability problems.

This only leaves the SOP like it currently is, i.e. restricted to hostname but not IP address. Unfortunately this leaves it open to DNS rebinding attacks. But, assuming that the hacker does not control the DNS for the original hostname of a site, bypassing SOP with DNS rebinding only works if the target host does not properly check the Host header in the request, i.e. allows an attacker controlled hostname inside the request. Thus, this risk can be mitigated by properly checking the Host header at the server. It can also be mitigated by using HTTPS since the server does not have a certificate matching the attacker controlled hostname and the browser will thus refuse the connection.


Account identified only by name, surname and date of birth I am working in QA field and we have a project about a famous booking website.

I have discovered that if I create an account with the same name, surname and date of birth of an already registered account, I am able to see the personal page of the latter. This means that I can see his phone number, address and bookings.

Moreover, if I modify these fields also the settings of the original account will be modified. This means that I can also block another account by registering mine on a different market, because this will change its Country field and prevents him from logging from its market.

I have pointed out this behavior but I only got a "works as intended" answer.

Is this a severe security issue or it is just me? Thank you.

Given that name, surname and birth date are easily to obtain information for a single person or even in bulk there is (based on your description) an obvious risk that personal information can be viewed and changed (which might result in charges to this person) and also for en-masse denial of service.

Given that this "works as intended" the ones who designed this system either did not understand these risks or they've knowingly accepted the risk in favor of improved usability of this site - which can be a valid decision for this specific use case (although it sounds unlikely based on what you write).  If I understand you correctly you are working in QA of this site. In this case it should hopefully be possible to discuss the design decisions with the developers and software architects to find out if they are aware of the risks and consider these acceptable.


SSL certificates for a mixture of subdomains and top level domains In order to provide https-enabled access to several (e.g. around 5) subdomains and several top level domains on different IPs.

Which of the following approaches is technically feasible?

a one-use SSL certificate for each subdomain and domain
a multi-domain certificate
a mixture of wildcard and single domain
a mixture of wildcard and multi-domain certificates?

All of these approaches are technically feasible, i.e. they can be generated and browsers will accept these. But while you can create such certificates using your own CA it does not mean that every CA will support issuing all of these variations.

In case of using a single certificate for each different name you have to make sure that either each of these names points to a different IP address or that your server and client both support Server Name Indication (SNI). While this is true for all modern browsers and web servers you might get problems with older browser or applications or with protocols outside HTTP.


Secure password reset before authentication? I have recently been considering the password reset flow for a site I'm working on. A request came up that before authentication, a user should have an option to change their password by providing:

Username
Current Password
New Password (matching complexity requirements)
Confirm New Password

Ignoring user experience for the moment, is there anything insecure about this flow IF:

An identical generic error message is displayed if any of
the fields above are invalid on submission
Password lockouts are enforced after valid username and invalid password are submitted X times.

Is this any more or less secure than the login page itself, and therefore, no additional risk?

I can't think of any additional attack surface that this user flow would be exposed to. The messiest part is if 2FA is ever enabled for your site you'd have to make this password reset flow multistep as well.

You're not changing the required information to submit a password change or the order of operations to achieve one, so if this page as secured as your normal login page there's no problem with it.


Buffer overflow, real life scenario I've started my PWK Course, and now I'm on Buffer Overflow topic, which contains SLMail 5.5.0 exploitation.

Buffer Overflow is so great interesting for me, but I can't imagine how would look real life buffer overflow exploitation of SLMail 5.5.0.

In the course, most of the time is used debugger to investigate EIP value etc.
But in real life we don't have access to debugger on victim machine to debug application and investigate EIP value.

So, how this type of exploitation looks in real life?

Absent certain exploit mitigations that intentionally randomize the process address space to defeat memory corruption attacks, a program's addresses will be highly predictable every time it runs. In other words, once you find a working exploit, it should work on every machine running the exact same version of the software (assuming there's no address space layout randomization). It does need to be an exact match - different architectures (like x86 vs. amd64 vs. ARM) won't match, nor will builds from the same source code but targeting different operating systems or compiled with different compiler flags. However, in practice, most software is distributed as a pre-built binary, so everybody on a given platform is in fact running the same version.

In some cases, the memory layout that you're targeting will be different depending on how the program was used prior to your exploit occurring. This isn't a problem in software where you control how it launches, but for many long-running servers it can be difficult to anticipate the software's current state when you attack it. One option is to just corrupt memory anyhow; the program will almost certainly crash (itself an exploitable issue, for denial of service) but often a watchdog will launch it again. Then, you attack the newly-launched process. Another option is to make your exploit robust against slightly missing the start of the shellcode/ROP chain. One way to do this is what's called a "NOP sled", where you put as many NOP (no-op) instructions as possible before your payload; when you do that, you only need to get the instruction pointer to land somewhere in the NOPs (or at the first part of the actual shellcode), and then the processor just "sleds" down the NOPs into your payload.

Defeating ASLR and other mitigations is a different topic, and potentially quite difficult.


How secure are credit card readers? Can the data be easily intercepted when (or after) the card is swiped? My main concern is at a trusted vendor. There are two possibly different situations:

1) a typical point of sale scanner with a land line or internet connection

2) a standard reader on a smart phone, using the supplied software

Does the typical system usually store the credit card number or does it merely transmit it to the verification center? Are these transmissions encrypted?

edit:
I am only concerned with mag strip readers and client side security (server security is a whole different issue). I didn't mention camera or shoulder surfing as concerns because those threats are always a possiblity. How secure is my card number and PIN after they are entered into the device?

It depends, but where there's a will, there's a way.

You're asking a few different questions here:

Do POS terminals always encrypt the data they send? (No; as per DSS 4, data must be encrypted across public networks, so if the POS terminals are dead-ending to a server within the store, they may not need to encrypt.  This has been shown as a real-world security concern in multiple cases.  Isn't this how Home Depot got slammed a few years ago?)
Does a reader attached to a smart device always encrypt? (I don't believe that's a requirement, although the PCI guidance on "Accepting mobile payments with a smartphone or tablet" implies that any Council-approved device will, and if you choose to use unapproved devices you just bought into a whole lot of scope you need to vet.  Have fun proving the smartphone never, ever sends data unencrypted if the scanner hasn't already guaranteed it!)
Is a POS terminal at a trusted merchant trustworthy?  (No.  Consider what happened to Barnes & Noble.  Bear in mind that POS terminals are programmable devices - I have heard legends of one sales guy for a card processor who went around "updating" terminals at local businesses - to point to his processor instead of the processor the business was contracted with!  Also consider the problems banks have with ATM skimmers.)

To quote Mad-Eye, this stuff requires "constant vigilance!"  I don't know what a typical system does; there's a lot of systems out there.  A good system would encrypt before transmission and be resistant to various forms of tampering, but no system is perfect.


Is the following javascript code vulnerable to DOM XSS? I have the following javaScript code in an application, which BURP flags as being possibly vulnerable. However, i have had no luck trying to get it to execute.

  var hash = window.location.hash;
  if(hash){
                $('a[href="'+ hash +'"]')[0].click(); }

Is the above code vulnerable and if so, what sort of URL fragment can execute it?

Assuming that the only relevant code is what has been highlighted above, then as Burp notes at the end, you need to determine what version of jQuery is being used. If the page uses a version of jQuery below 1.6.3, then you can exploit this sink in Edge with #"]<img src=x onerror=alert(1)>.


How to write an email regarding IT Security that will be read, and not ignored by the end user? I've observed that several of our users are ignoring messages sent from IT Security managers, and also the system generated "You just sent a virus" notifications.

The problem seems to be among people who are not computer savvy, who are in no way hostile to IT SEC.  They are simply not "computer" people.

What guidance is there to ensure that the IT Managers and System Notifications are understood, and acted upon?  I'd like to craft a single message for the entire user base, and not take on responsibility for hand-holding the "special" folks.

My hope is that I can develop a set of email best practices that are used when communicating with all end users, for the purpose of sending IT Security user notifications through email.

How should I lay out the thoughts behind the message?
Are HTML messages more effective?  How so?
Are there any cut-and-paste samples?
Does the "From" address matter?
What should the subject say?

Examples of notifications include (but not limited to):

Automatic Email Messages from Antigen or Forefront AV systems
Revisions to IT security policy
General notifications that are simply informative

"Maintenance will be performed at 11pm-6am.  Expect a disruption in service"

General notifications that are meant to be read and acted upon.  They do apply to the end user.

"Close all applications and log off for patching"

Other notifications that may or may not apply to the end user.

SPAM Quarantine Summary Emails: "Enclosed is a list of quarantined messages..."
"A security patch for an old version of software that might not be installed"

  This question was IT Security Question of the Week.
  Read the Aug 26, 2011 blog entry for more details or submit your own Question of the Week.

A small trick I learned years ago - lay your email out like this:

  Short Version

  Small number of very short succinct points
  If X, then you need to do this
  Else, then you need to do that (or don't need to do anything)

  Long Version or Full Details

  ...and here you lay out whatever full version you want.

97% of your users will never read the long version, so make the short version count. However, the key here is that most users will read the short version if they're given a choice between that and the long version.  When you put that "Short Version" section header in, you're enticing them to read that because they feel like they can "get away" with just reading the short version.  It's, like, psychology or something.

Many of your users still won't read messages no matter what you do.  I've gotten better hit rates with this method than not, though.


Authorize the access ability to a user in Oauth 2.0? As far as i known, the protocal OAuth2.0 will bring the access ability from the resources owner(A) to the client. But in the scenario here, I wonder if it is possible to authorize the access ability to another user(B) (After login the user B will access the resources which belong to resource owner A)?

The answer is yes. Why? Because it is what OAuth is intended to fulfill: delegation of (a secure) access to a user (B) for a resource on behalf of a resource owner (A).

I think the description in this draft will be quite straightforward to you:

  (A)  The client requests authorization from the resource owner.
  The authorization request can be made directly to the resource owner
          (as shown), or preferably indirectly via an intermediary such as
          an authorization server.

  (B)  The client receives an authorization grant which represents the
          authorization provided by the resource owner.  The authorization
          grant type depends on the method used by the client and
          supported by the authorization server to obtain it.

  (C)  The client requests an access token by authenticating with the
          authorization server and presenting the authorization grant.

  (D)  The authorization server authenticates the client and validates
          the authorization grant, and if valid issues an access token.

  (E)  The client requests the protected resource from the resource
          server and authenticates by presenting the access token.

  (F)  The resource server validates the access token, and if valid,
          serves the request.


How to know if mail is for tracking our IP Consider if I have got a mail from a colleague on my GMail, and it has got some images or attachments in it. Gmail asks for "Show Images" option to explore images.

My query is that how can we get to know that these images or attachments are not for tracking our IP from websites like ReadNotify.
Is something to be noticed in email header ?
What all other products are their like ReadNotify ?

You have no way to know. The IP tracking is performed by the server that serves you the image. The server necessarily knows that it served some image file, but you have no way -- as a client -- to know whether the server does anything meaningful with that information, or whether the image load could be traced back to you personally.

If it's a mass email, the image URL would probably have your email address in it (or, more likely, some randomly-generated unique ID that maps to your email in a server-side database). That's so the server knows whose IP they're getting with each image load. (e.g., "Okay, 11.22.33.44 just loaded the URL /images/35fd76a74/track.png... from our records, we sent that URL to foobar@example.com.) However, if an information gathering effort is focused on only you (or the service is very clever in how it encodes unique IDs in their URL), the URL could look perfectly mundane.

In order to decide if an image is used to track your IP address, you'd have to decide whether the server associates the loaded image uniquely back to your email address. Since you don't run the server, this is generally not possible. If some image is known to be widely used (e.g., just a /static/img/header.png that the sender puts in every single one of their emails to many recipients, without any kind of unique ID in the URL) then it's unlikely that that image could be used for tracking: too many people load that same image for the originating IPs of its requests to be uniquely linked back to a particular recipients.

If you fetch the images through an anonymizing proxy, you can hide your IP address. However, a proxy cannot hide the fact that the image was requested at all. The server would still know that /images/35fd76a74/track.png was loaded (and that that unique ID links back to your email address), but they simply don't know what your real IP is.


Spoofed DNS-Address in Spam mail header There is a recent rise in Spam mails sent from seemingly legit german email-addresses according to the mail headers:
Received: from mx1.aok.de ([91.199.166.49])
But when I nslookup mx1.aok.de, I get another addresss:
Name:    mx1.aok.de
Address:  217.110.254.8

When I reverse lookup 91.199.166.49, I get mngw.ungstabled.com which won't budge since the domain seems to have an spf record and my email provider should check it.
My question is how spam actors managed to spoof the reverse lookup of the domain or if I missunderstood any of the concepts involved?
There are several other seemingly compromised domains constantly sending spam about bitcoin.

There is no DNS spoofing involved. The name given in the Received header is the name claimed by the sending MTA in the EHLO command during the SMTP dialog. From RFC 5321 section 4.4:

4.4.  Trace Information
... insert trace ("time stamp" or "Received")
information at the beginning of the message content ...
This line MUST be structured as follows:
o  The FROM clause, which MUST be supplied in an SMTP environment,
SHOULD contain both (1) the name of the source host as presented
in the EHLO command and (2) an address literal containing the IP
address of the source, determined from the TCP connection.


Is it a good idea to upload your gnupg files to github? I have a GNUPG file that i use to store all my passwords locally(Dont know if it is a good idea). The question is, is it safe to push the GNUPG file to github so i can access it from anywhere?

It's encrypted, so in theory it's safe, provided your encryption key/password is of sufficient quality.

But if you're making your database public, that's pretty much an invitation for people to try cracking it. If your key is not as strong as you think, or if you slip up in some other way (falling for a phishing attack for example), then you are at risk. I think posting your database publicly is a bad idea. Just because something shouldn't be at risk if it's in the hands of attackers, doesn't mean you should volunteer to be a target. Just like a website keeps its password hashes private as a first line of defense, your first line of defense should be keeping your password file out of the hands of attackers. They can't even try to attack what they don't have yet.

I suggest using an online storage service that offers private access (such as: Dropbox, Google Drive, OneDrive, etc.) to store your encrypted passwords for convenient multi-device access but still keep them hidden from most attackers.

Off-topic: have you considered a password manager designed for the purpose? If you want a local-only tool, KeePass, PasswordSafe, and other options exist. I think you'll find the convenience increases quite a bit with the same level of security (or better, as you you don't need to worry about temporary files created on decryption).


How to speed up brute forcing of finding a WEP key from a captured file? I have been working on decrypting a WEP .cap file using crunch. It has 1268 IVs. I am wondering:

Can I get a clue from the captured file to speed the process of brute-forcing?
If not, what other ways I can try to decrypt the packet?

It is a captured 802.11 file; consisting of data transmission and a part of de-authentication (not an attack). Needless to say, it has a large part of acknowledgment packets as well. I have used aircrack-ng without a dictionary and what it said was this: "Failed. Next, try with 5000 IVs." Since I do not have access to the source transmitter (it is just a .cap file), all I have is the captured file.

You don't have enough IVs
Plain and simple. Cracking WEP works by statistical analysis, and in order to do that reliably, you will need lots of data.
The aircrack-ng FAQ says:

How many IVs are required to crack WEP?
WEP cracking is not an exact science. The number of required IVs depends on the WEP key length, and it also depends on your luck. Usually, 40-bit WEP (64 bit key) can be cracked with 300,000 IVs, and 104-bit WEP (128 bit key) can be cracked with 1,500,000 IVs; if you're out of luck you may need two million IVs, or more.

What does that mean?
Aircrack actually gave you the correct message. It said that with just barely over 1000 IVs, it can't deduct any information about the WEP key, so it'll try again once you have 5000 IVs, then again when you have 10000 IVs, and so on.
How can I successfully crack the key?
One thing you can do is to generate a lot of traffic. Tools such as aireplay-ng are designed to do just that.
The tool has a number of different attacks, some very specialized, some generally useful. For cracking WEP, the ARP Request Replay Attack and the Cafe Latte Attack are quite useful. Both attacks aim to generate more IVs.
Keep in mind you can have aircrack-ng, airodump-ng and aireplay-ng running all at the same time.


Are there any known Python pickle viruses? I have recently read a post about vulnerability of Python pickle module which allows to execute arbitrary Python code on unpickling: https://intoli.com/blog/dangerous-pickles/
The docs are suggesting to "never unpickle data received from an untrusted or unauthenticated source" but I can think of a hazard coming from supposedly trusted (but compromised) source.

As Python is a flexible, dynamic language it does not require a wizard to create an old-school computer virus infecting pickles.

Are there any known cases of such viruses?

[EDIT]

By "a virus" I mean literally old good "computer virus": a program that proliferates by adding itself to other programs.

If by "virus" you mean "exploit", then you can easily find those even on StackOverflow.

There's probably no widespread malware based on that, partly because there's only little number of applications for popular desktop platforms like Windows that are written in Python, and it's unlikely that any of them indeed uses pickle for the remote data (un-)serialization. However, a Python developer should better avoid a false sense of security here, because it's too simple to write such a malware, as is demonstrated above.


How to detect social engineering attack? How can I understand if I am being targeted by a grey hat social engineer?

And if I fail, what approaches exist to detect social engineering attacks being in progress  within an organisation?

The reason that social engineering is as successful and popular as it is, is because there is no "catch all" approach to identifying a social engineer attack.

Approaches to identify social engineering attacks within an organization, typically (in my experience) involve getting the attacker to try to identify things that only a legitimate caller would know (security questions). It's debatable how secure this approach is, however it's still widely employed and used by many companies. Technologies like two factor authentication can help as well, but again these technologies rely on not having a "weak" human that can over-ride their processes.

Social Engineers will attempt to play off your emotions as a human. Most humans have a distinct nature in wanting to help those who need help, so it's common for social engineer experts to create a scenario whereby you pity them and may circumvent proper security procedures to help them. Another tactic is to get very angry and irate at someone in hopes that they'll provide the attacker what they want because most humans don't like being yelled at, and many don't like any sort of confrontation.

Perhaps the worst part is, if an attacker has done their research and knows their lingo and security questions of their would-be victim, you'd probably have no idea you had been socially engineered. Many companies have staff follow security procedures but if an attacker knows those procedures and has figured out a way to circumvent them, you'll likely find yourself out of luck


Is faulty RAM a security risk? If the RAM is only slightly faulty, so that the machine boots apparently normally, but sometimes crashes. Can the fault be leveraged somehow?

Possible? Yes. Probable? Hardly. It's way more a reliability (or availability) issue than a security one.

A faulty RAM can lead to data corruption, and that corruption almost always will lead to a Segmentation Fault and crash the process. If the process is the kernel, or a critical process (like init on Linux systems), the entire computer crashes.

A less common effect is basically a hardware-induced RowHammer Attack. In this attack, a cell have its value changed intentionally. If you RAM banks are defective, there's an infinitesimal (but bigger than zero) chance that the byte changed will not crash the application and give it super powers. A bash shell with UID 0 or a cmd.exe instance with admin privileges are possible, but so improbable that you cannot count on it.

But leveraging a fault memory chip to actually attack the computer is almost out of question. An attacker that can execute code on the computer could employ countless privilege escalation attacks to gain more access, and an attacker with physical access can just take the disk, image it, and leave.


How do I run a security check on my WordPress server? I have a cloud-based server running with CentOS 6.0 and CSF installed. Today I got a message from my host that one of my WordPress installations is hacked and used for phishing.

But I don't know how this has happened. I do not know where it is happening. What the best practice here? How can I check what has happened and stop it?

EDIT: My host said now that he wasn't sure it was wordpress, but was suspecting it. Do I really need to delete everything and reinstall. This is over 10 sites, and it will be a lot of work.

Here are some guides:

General WordPress hardening: http://codex.wordpress.org/Hardening_WordPress

More in depth including some server stuff: http://wpsecure.net/secure-wordpress/

If your server itself is secure, most problems are user related, meaning your plugin or theme has malware.

You can run a malware checker: http://wordpress.org/extend/plugins/wordfence/

It's very advisable that you remove plugins, revert to default theme , back-up and clean the DB and do a fresh install.


Will this system stop scalping and only let users by a maximum of 25 tickets per person? I'm building a ticketing system which is mobile-first. Which means that people will need to download and register (using phone authentication like WhatsApp) in my app before they can buy tickets either on the web or through the app. The web-platform will be like WhatsApp Web wherein the user has to scan a QR code on the web-browser with his mobile phone before he can buy a ticket.

For the web-platform:

User arrives on the webpage to buy a ticket. He'll have to sign-in by scanning a QR code on the login page with the mobile app. After this, when he decides to buy a certain number of tickets for a concert/event, my Firebase backend will make sure that he cannot buy a large number of tickets(greater than 25) with a simple check on the cloud-side when he requests a ticket block. After successfully specifying the number of tickets, before he's taken to a payment page, he's asked to scan another QR code on the browser to proceed and finally, the payment is done successfully and the respective tickets are added.

For the mobile-devices:

Nothing special here. Just that he'll have to register with his OTP and won't have a 'Sign-out' feature (Much like Whatsapp) in his app. One account also can't hold more than 25 tickets. So, 25 tickets per mobile phone for 1 event will be the check.

Can you think of a way to beat this system and buy more than 25 tickets?

Virtually everything you've described is susceptible to a smurf attack.  Cell phones are too cheap relative to the profit to be made.

A burner phone costs $40 cash. If tickets cost an average of $100 and I can scalp them for an average of $200, I stand to make $2460 on that $40 investment.  For $400 I can buy 10 phones, and make $24,600.  (I might have to hire 9 people to help me, but I can do that by offering $100 each for 30 minutes of work.)  Plus, I can reuse the phones for the next hot ticket.

If you really want to limit scalping, you can do it the old fashioned way:  open a box office, have people stand in line to buy tickets, and don't sell them online.  Attackers will ignore you and go for the easy online targets they already know how to exploit.  Of course, so will your customers.

EDIT:  I'm not saying that there is no way to protect an online environment from attacks; what this is concluding is that cell phones are inadequate sources of unique identities for this problem.  I also am not saying there is an easy or even a possible solution.  Approaches might include:

Find a more effective way to identify your users so you can better enforce the limits.
Reduce the per-purchase ticket limit to increase the cost-per-user to the attackers.
Raise ticket prices to the point where scalping is too risky to be profitable.

Something else to do is accept that scalping will exist no matter what you do, and explore other ways to offset the problems scalping causes:

Offer additional value to official ticket buyers by way of purchase-time-only perks, like access to an exclusive music videos that can only be downloaded from your site within one hour of the ticket purchase.  (Think of download/access codes to a site like Vudu or Netflix.)
Offer unrelated additional perks with rapidly expiring real-time value, such as a code redeemable for a restaurant meal that has to be used within 24 hours of purchase.

Be ever aware that scalpers will simply hire more smurfs when there is profit to be made.  They'll probably resell the restaurant codes, for example, but advertising this would help build resentment against buying scalped tickets, reducing their appeal.


What is the use of cross signing certificates in X.509? In X.509 architecture what are the uses of cross signing certificates from other hierarchy?

Does it just expand trust?

So from the answer I am assuming that if CA3 is cross signed by CA2 (from another hierarchy) and CA1 (a parent in its own hierarchy) whose private key is used to encrypt the authentication hash in the certificate of CA3?

It's about expanding trust, yes. If you trust both CA1 and CA2, and a cert is signed by both, you've got a very high level of trust because two seaparate entities that you trust have verified the cert.

It has the added bonus of increasing the ease of verification of trust, such as situations where you've got clients that trust CA1 or CA2 (but not both). In such a case, you can cross-sign a cert to be trusted by both. This allows more clients to verify trust without having to distribute separate certs for different CAs.

Another bonus is in situations where a CA's private key is leaked. Let's say CA1's key leaks and your cert is signed by CA1 and CA2. In the wake of the leak, CA1 issues a revokation for its public key and you can no longer trust anything issued by CA1. However, since your cert is cross-signed to CA2 as well, any client that trusts CA2 can still maintain a level of trust in your cert.


External network pentest and Application pentest. The same? I'm trying to create a pentesting process to test the network and applications of a company. I'm using for this the OWASP Testing Guide 4.0, because i do not have experience about pentesting and I do not know nothing better.

The most of steps described on this guide are related with application testing. I understood that this is because the most used way for try to acces to the systems of the company is the application hacking and then the corresponding elevation of privileges.

So, can we say the external pentest and application pentest are the same or have the same objetive?

Thank you for all.

In short, no, they are not the same.

OWASP stands for open web application security project, which is why its guide is focused on the application side of things. You might find what you're looking for here:

http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines

However, conducting pentests is best left for professionals - they will be more efficient and will be able to interpret the results correctly.


The impact of 'hacking insurance' on the information security industry I recently attended a general IT conference and saw some interesting vendors of various products and services. One of them was a company providing hacking insurance, and they said that there were two business models that they operate on:

Liability insurance model: this is where they insure the providers of services such as penetration testing or data security against their clients suing them when there is a security breach. Apparently this is the main business in the US.
Loss of data/asset model: this is where they insure small to medium businesses against loss of company productivity, assets or client information when there is a security breach.

I was wondering what the impact of these services on the information security industry. Is this going to make people more aware of information security, will it make people less vigilant because there is some insurance against bad events, or perhaps it won't change anything at all?

The interesting thing about the business model is that for the loss of data/asset model they don't assess the client for their level of security infrastructure and process, which is rather interesting because it means that they are happy to insure people regardless of the risk of having to make a pay-out (presumably because they are trying to attract customers and they are not going after large enterprise or corporate clients). I suppose once they get enough clients and lots of claims come through then they might have to have an internal assessment team or outsource this capability to other firms.

If you have a car insurance you will pay more if you have a more expensive car. Also young and inexperienced drivers will pay more because the risk with them is higher.

The same is with such hacking insurance: this price depends on what needs to be covered and how much the risk of hacking is. The risk of hacking or at least the costs associated with a hack can be reduced by using established security strategies, i.e. backups, training, firewalls, breach detection, audits .... Thus if you invest more for security you pay less for the insurance. In fact most insurances will probably do not offer you a hacking insurance at all if you do not already have adequate security measures in place because in this case the risk would simply be to incalculable. And they will reduce payment in case of hacking attacks if you failed to keep your security up-to-date.

This means that  I consider such insurances will be a good thing which will help to improve the security.


How to crack forgotton KeePass password when knowing most of the password A few days ago I changed my KeePass password and forgot it unfortunately. It isn't that much different from the previous one, but I kept trying and trying and it says it's incorrect
I found https://www.rubydevices.com.au/blog/how-to-hack-keepass

I want to make my own wordlist so I can attact it using the dictionary attack.

My password is something like " FaceAndBook123xxx#@xxxxxx "

--> the xxx after the 123 are 45678.. (it can also be just "123" but also "123456" I know it's max 6)

--> after "@" the xxxxx can be other things but I'm not sure, it's either "Book" , "Book" + 123 (or 1234, 12345 or 123456)

--> So I know it starts with "FaceAndBook" and contains "123" "#@" and "Book"

--> Min of 20 char, max 30

I tried Cruncher to generate a wordlist but it gave me 1844444444444444444444444 lines to generate (I don't know if it supports words instead of characters)

Anyone that can help me?

Sounds like a combinator attack would be a good place to start.  It takes two input wordlists and tries all combinations of the two.  In your case, the "left" list would be the beginning of your known password and the "right" list would be the unknown portions.

However, Hashcat only allows two input files to a combinator attack, but you can use the standalone combinator utility to pre-process multiple files down to one.  For example:

combinator part1  part2 > part12
combinator part12 part3 > part123
...

In your case, the files would probably be split into the following chunks:

The known prefix of your password
Sequential numbers of varying lengths (1, 12, 123, ...)
The word that may or may not be included, plus one blank line

The blank line is required, otherwise all output candidates will contain the word.  Including the blank line means that half will include it and half wont.

Another sequential number section, just like the previous


What are methods to protecting an android phone from law enforcement From what I hear, android uses the standard linux dm-crypt for encryption. Obviously you should have:

A pin/password for your phone
That pin/password should at least be 8 characters

The question is how much that already does to protecting the data on the phone. Let's just assume that the password you picked is "safe" and cannot be brute forced in any reasonable time.

1: Assuming the device does not use full disk encryption, law enforcement will still have access to everything, since they can still just read the data right from the sd card because it's not encrypted. Is that correct?

2: Even if you do have full disk encryption, it will only protect you as long as the device is turned off, since law enforcement can otherwise just read the data from ram. Is that correct?

3: Is there any benefit to disabling USB debugging?

4: Are there any security implications connected to rooting a device and/or using a custom recovery?

edit: law enforcement here is referring to normal police. Obviously you're gonna be screwed when NSA and the like are after you.

edit 2: When I'm talking about SDcard, I mean the internal card, I'm not talking about any external cards you might use.

You should encrypt the SD card as well. This is optional in Android, so be careful and don't forget this.
With good enough equipment they can freeze your phone (or laptop), and specifically the RAM chips inside. Then they can take them out, connect them to another computer, and read them out.

With good enough equipment... "Law enforcement" (what is that? NSA?) can probably read out the encrypted data from disk (without freezing anything), then run it in a VM and try all PIN codes. It won't take long to find the right PIN, even with 8 digits. A password will be a lot more difficult when long enough, but have you ever tried a long password in daily use? For me it's too much trouble and I'm not a good enough typer wth those crappy onscreen keyboards.


Why did Chrome show my connection to Youtube as not secure? I was browsing on Youtube a while ago, when I noticed that Chrome showed it as an insecure connection even though it was over HTTPS.

I'm using Ghostery and Adblock to block trackers but nothing more, I don't think it's the reason because I always blocked trackers and this never happened to me before. I don't know if it is a bug or something. I tried to inspect the page with the dev tools in Chrome, but I didn't see anything strange, just that it's a valid certificate but no HTTPS connection:

It didn't matter if went back to the main page, Chrome was still showing it as an non secure connection. Of course when I closed and re-opened Youtube the problem was gone.
Is this something insecure for cookies or they can never be sent in this case if they have an HTTPS-only flag?

HTTPS not secure can be caused for multiple reasons but usually has to do with the certificate being used. In chrome you'll want to view the certificate details and see if anything is awry such as ...
- untrusted issuer
- name mismatch
- date is expired
- date is the future

It could also be that your PCs systems clock is way behind or way ahead causing chrome to think the certificate is bad when it really isn't.

Sites like YouTube are load balanced too so perhaps 1 of its 100 servers are hosting up an invalid certificate and you just happen to get that one.

Perhaps could also be related to ad advertisement or script being served up insecurely on HTTP.

This blog explains a bit
https://www.rankya.com/how-to/how-to-fix-the-https-not-secure-message-in-google-chrome/


Is it secure to use only the access token? I'm using JWTs for authenticating users for my mobile and web applications in the same API.Both access_token and refresh_token have same expiration

 Passport::tokensExpireIn(now()->addHours(1));
 Passport::refreshTokensExpireIn(now()->addHours(1));

When a user logs in

authenticate (username and password) store access token (client-side) while for the refresh_token (I don’t use it at all)
If the access_token is expired then it will go directly in signing
in again (#1 repeat)

  My Question: Since the expiration will last an hour and thinking the
  process is secured enough. Is there something I'm missing?

I do understand using the refresh_token.

If the access_token is expired then it will use the refresh token to
get a new access token + new refresh token.  (requires the client id
and secret)
The presence of the refresh token means that the access token will
expire and you’ll be able to get a new one even without the user’s
interaction
is intended to automatically detect and prevent attempts to use the
the same refresh token in parallel from different apps/devices.
mitigates the risk of a long-lived access_token leaking (which in my
case not applied)
Once the new access token + refresh token generate in using the
refresh_token Those previous access_token and refresh_token will be
useless or revoked

  My Question: Should I use the refresh_token?  I am thinking of saving
  it back-end or server. Setting the expiration lasts longer than the
  access_token, which is still 1 hour but for the refresh_token making
  it 1 year unless revoked. Once authenticated then it will generate
  using the refresh_token sending the new access_token in the client_side then saving the new refresh_token again in the server and so on. This will do everytime he/she logs in or register. Do you think it's okay to save the
  refresh_token in the back-end?

It sounds to me like you might be mixing up the use-case for access tokens. They are not designed to authenticate users for your application; they are meant to authorize a client application to work with a resource server API on behalf of the user.

If you are simply looking to authenticate a user for your apps, you should instead use the id_token provided by OpenID Connect. The id_token is designed to provide your applications with the details (in the form of JWT claims) that they need about the authenticated user; this is intended to allow each of your applications to initiate their own sessions, based on those claim details. As such, your session can be as long or as short as you need - it is independent of the session of the user in the AS (or OpenID Provider/"OP", as it is known in OIDC vernacular).


SSL Session resumption and IDs Some sites, as seen in the report for www.mbank.com.pl [ssllabs.com] or report for aliorbank.pl [ssllabs.com] do not support "Session resumption", either because IDs are assigned but not accepted (first case) or because IDs are empty (second case).

It's not related to secure renegotiation, as visible in report for poczta.interia.pl [ssllabs.com] where the session resumption is unavailable while renegotiation is performed in secure manner.

Question:
Why it's in red? Is it a security vulnerability?

Not supporting session resumption is not a security vulnerability; but it implies a new handshake per connection, which can increase latency (a full handshake implies more roundtrips than a resumed session) and CPU cost (mostly on the server, with the common RSA key exchange).

The first server is somewhat discourteous, in that it returns a non-empty session ID that it will refuse anyway; what the second server does (returning an empty ID) is what the SSL/TLS standard recommends. Yet returning a non-empty session ID for an unresumable session is not a true bug.

Presumably, ssllabs.com uses the red color here because it is relatively uncommon to deactivate session resumption -- and thus this may be a "configuration bug" worth reporting (although the red might veer a bit too much on the scary).


How to "Pass the hash" when LM hash is disabled? I ran the NTLM_stealer metasploit module and ended up with the following results:

LMHASH:Disabled
NTHASH:008940f335e9b2ddc182bb5b960a0c5bad0b125cbee3cf84

I was wondering if there is way to successfully use the pass the hash technique with just the NT Hash. Every tool and blog seem to outline techniques that require both LM and NT hash.

You need either of the hashes in order to 'pass the hash'. Here is some further reading for you if you're interested in learning more about it.

https://www.sans.org/reading-room/whitepapers/testing/crack-pass-hash-33219


Is this vault-less password manager/generator design safe? Counter

The counter is appended to the site name and incremented if you need to get a new password for a site or if the generated password is insecure because it randomly matches something like "password1" (see Quality Assurance)

Base 89

Where Base 89 is like Hex just with an alphabet of 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"$%&/{}()[]=\+*~'#-_.:,;| rather than 0123456789abcdef.

Quality Assurance

Quality Assurance would use something like zxcvbn to rate the security of the password.
If it doesn't pass the test, the counter is incremented and the whole process is repeated.

Ask for clarification anytime.

Edit

This is my new design but @Gilles stated good arguments against a vaultless password manager.

The master key must be a sufficiently long, randomly-generated key. It must be at least 16 bytes generated uniformly at random (not 16 random printable ASCII characters and definitely not a human-chosen password or passphrase). Otherwise it would be possible to find the master key from any of the derived passwords.

This means that the master key is not realistically memorable by a human, so this scheme is not really vaultless.

If you use HMAC as the hash, then it's ok if the master key is not generated uniformly at random, but it still needs to have sufficient entropy to make a brute force search infeasible. For example, with Diceware, you need 10 words to reach 128 bits of entropy. Given that you'd have to change all your passwords if the key is ever compromised, don't settle for less.

Generating different keys from a master key is called key derivation. You're using a MAC as a key derivation function. This is probably ok with MAC that are used in practice, but it's dodgy. Any MAC guarantees that there's no way to find the master key from any number of (input, output) pairs, except for a brute force search over the set of permitted master keys. A MAC also guarantees that there's no way to find the output for a particular input without knowing the master key, even knowing the output for some other inputs. What a MAC does not guarantee is that there's no way to find the truncated output, and password length limits may require you to truncate the output. Rather than using a MAC, use a recognized KDF, such as HKDF (which is very easy to implement on top of HMAC, if your crypto library doesn't have it).

You could replace the MAC-should-be-KDF step by a password-based key derivation function such as scrypt or Argon2. This would let you use a master key with less entropy. Password-based key derivation functions are designed to take a password as the secret input and compensate for a smaller input space (less entropy than a normal-sized key) by being intrinsically slower to compute. For example, if the stretching factor makes it 1 billion times slower than HKDF (so it takes about 1 second on a PC) then it's enough to have 7 Diceware words (giving you 120 bits of entropy). Keep in mind that in this scheme, you won't be able to upgrade the stretching factor without changing all your passwords, so choose it conservatively.

The “quality assurance” step is badly named since it (slightly) decreases the security. It doesn't separate “weak” from “strong” outputs: all outputs have exactly the same strength. The strength if the output comes from how the output was generated, not from what it is. Call it an “output constraints” step, with outcomes “acceptable” and “not acceptable”. Note that you'll need different acceptability rules for every site (for example some sites insist on the presence of a punctuation character while others reject all punctuation characters).

Remember that you'll sometimes need to change your password on a site. So you need an additional public input “version” in addition to the site name. Make sure that the site name, the version and the counter are combined unambiguously. For example, plain string concatenation would not be ok since example.com123 could be version 1 with counter 23 or version 12 with counter 3. If you use printable strings for the site name, version and counter then you can concatenate them with a null byte as separator. You may also want to include a user name in there to support multiple accounts on the same site.

A practical limitation of this scheme is that you must only ever input the master key/passphrase on a system that you trust. This means only your own PC, only in circumstances where nobody might be spying on you (for example, not in view of security cameras). In particular, there's no way to create a password in a low-security environment and later upload it to your keyring. Every password must be generated in a high-security environment.

Since you need to carry your own PC to use this scheme, it is of limited benefit compared to a password vault. The only benefit is that if your PC is stolen while it doesn't have the master key in memory, you haven't leaked any secret. Balance that with the risk that if the master key is ever compromised, you've instantly compromised all of your passwords.

This scheme, if implemented correctly, is theoretically safe, but doesn't work well in the real world. It's well-protected against cryptographic attacks, but poorly protected against “out-of-band” attacks such as a physical keylogger, a keylogger malware or a security camera, or against revealing the master key through coercion or by accidentally typing it in the wrong field.

Your scheme is basically a single-factor authentication (only the master key) where a password vault is two-factor authentication (the vault content and the vault unlocking key). Two factors are more robust than one. A vault protected by a strong password is just as resistant to all the same attacks as your scheme, and additionally resists attacks such as shoulder surfing.

In terms of usability, both schemes require you to use your own trusted PC. Your scheme has the advantage that you can buy a new PC, retrieve your software from a trusted source, obtain an offline copy of the master key, and get access to your passwords. A vault requires the extra step of downloading the encrypted vault, but this is hardly ever a problem in practice: when would you need passwords but no have Internet access? As mentioned above, a vault has the advantage that it works in a common scenario where you want to create a password in circumstances where you don't have access to your PC, for example to create a password for shared work/personal use (e.g. a password for a travel-related site if you travel for work) on a work machine and then copy it to your personal vault.

I would strongly recommend a password vault over this scheme. It's more robust in real-world use cases.


Securing live Ubuntu USB drive Live Ubuntu USB drives are used for the purposes of secure transactions e.g. banking, payments,etc in the absence of live CDs since the devices do not include CD or DVD-ROMs.

Since there are regular patches being published and the USB drives have limited storage, what is the best way to ensure the applications being used e.g. browser, shell, etc are updated without attempting to update the entire base?

Is there another way to perform similar tasks to reduce the attack vectors as opposed to using live Ubuntu USB drives

The value of a Live USB or Live CD for secure transactions comes from the fact that they create a non-persisting in memory system based on a read only ISO image.  That prevents all malware attacks to the local file system from being effective beyond the single session of the attack.

Upon reboot nothing from any previous session exists as it is all recreated again from that same read only ISO image that started previous session in memory.  That fact also prevents patching of a Live USB stick.  While the system might act as if it were taking a patch during the session there would be no persistent change in the media thus no updated behavior on the next boot.

You are right to want the latest browser etc. for your session so you are faced with two choices.  You could update your browser every time you boot knowing it would not persist or you could periodically update your ISO image by creating a custom Ubuntu Live USB using their tools and instructions.


Able to access other user information using valid session So, I'ma login to the website using my valid account. But there is Web API (GET) using "application/x-www-form-urlencoded" or "parameter" that we can access without login. Some page needs to login to access it.

This is the case

Login using:

Username
Password

Available Page:

Page A => We should log in to access it
Page B => Common information page no need to log in

When I logged into the website, then I can access Page A but when I try to access that Page B (Web API) using the parameter:
example:
http://www.websiteurl.com/?name=another_username

Then I can access like common information (gender, last_login, etc of common information), after accessing that when I try to go back to Page A it shows another_user information not my information again.

I checked into cookie only have:

PHPSESID: randomCookieValues12345678

Questions:

Why did it happen? and how to avoid this problem too?
Is this against cyber rules? although this happened because of the programmer

Capturing your own traffic would likely show what's going on, however see caution below.

Given your description, it sounds like the site is applying a binary authentication for the site and not a user level authentication. In short, once you are authenticated as a valid user, no other checks apply.

Sadly, this kind of mistake still happens even in places you would think would know better.

I'll caution you on how you may go about reporting this security problem.

  Look, I can get anyone's information by doing this!

May result in them coming after you for hacking

  Hey, my data was wrong when I went back?

A clueless question demonstrating ignorance and confusion over your own information is more likely to be received well and looked into.

It's an unfortunate reality that "Kill the Messenger" is still quite common.

If it's a viable option, I'd simply avoid the site.


Is automated and digitized ballot processing inherently more dangerous than manual pencil and paper? This is on a somewhat layman's level.  I'm not a security guru.
Looking at this in very, very broad and general terms:
Election fraud is definitely a serious issue that needs to guarded against pretty heavily, ideally by many third-party officials and monitors.  If you have random people working at the polling stations, some may be tempted to throw away ballots or to fill out extras.  You have a lot of random people, each being a potential, partisan security risk.
Therefore to reduce the risk, as well as to speed up counting, a given jurisdiction makes everything completely digitized (no paper ballots), and they fully automate the vote counting.
Just looking at this vaguely, some issues I see are:

Genuine bugs in the software.  Not all issues are malevolent.
The organization that produced the software was indeed malevolent.
Even if they weren't malevolent, completely outside hackers can still try to get in and interfere.
Hackers from within the jurisdiction's staff and officials can also try to get in and interfere.  Or even if they don't hack in the most literal terms, they can still find other ways to revise the final results after they've been produced, but before they've been presented to another party or the general public.
The whole entire system works as an opaque, black box.  This means trying to monitor the ballot collection, as well as the counting itself, has the same issues as trying to debug a software defect in a black box, third-party item.  Logging information helps, but it is not the same as having a clear/white box.

Even if the software were developed by the jurisdiction itself internally, it's still just a small subset of that jurisdiction (which can still be corrupt) that would be immediately familiar with the code and how to analyze it for potential issues.  The corruption issues and black box issue are still somewhat at play.
On the other hand, imagine another jurisdiction chooses to avoid computers entirely for the purposes of collecting ballots and counting the votes.  This other jurisdiction still uses computers for things like verifying someone hasn't already voted or sending internal communications between staff, for obvious reasons.  However the ballots are all paper ballots, they are all collected manually by hand, and the votes are counted - and aggregated together - by hand.
That means there is no hacking, and it also means that we are now dealing with something at least somewhat closer to a clear/white box.  If you have corrupt individuals collecting the ballots and counting them by hand, you can also have security and monitors, both from within the jurisdiction and from third parties, watching them.  And if they miss something in real time, video cameras can sometimes provide footage of an incident.  And if both of those fail, you still have A set of physical ballots, envelopes, and anything else.  It may not be The set that is genuine (ballots missing or added corruptly - or by innocent mistake), but having A set, heavily derived from the genuine set of votes cast, is often better than having none at all.
Altogether it is potentially much easier to monitor.
Now that said, the first jurisdiction may still very well be much more secure in its election process than the second, but this would depend on things like the resources invested in security, and more importantly, how well they each manage things.
However is the first jurisdiction inherently running an extra risk by relying on computers to collect the votes and/or to tally the votes?  Is the first jurisdiction, compared with the second, doing the equivalent of using HTTP instead of HTTPS, writing data access code that blatantly omits SQL parameters, or leaving the car defrosting and unlocked for 10 minutes while they're getting ready in the morning?
UPDATE:  A lot of good answers here.  I think there were at least a couple that more or less tied for 1st place, so I would've liked to accept at least a couple of different ones.

Great answers already about supply-chain attacks, complexity, transparency. I'll give an answer in a different direction: accountability and auditability (basically; how easy is it to do a from-the-ground-up recount?).
With a paper-based system, in the case of disputes, as long as boxes aren't physically lost or destroyed you can always go back to the paper source-of-truth and do a recount. For example, if the voting machines physically screwed up, you can go to the supreme court to get a ruling on whether "hanging or dimpled chads" count, and then go back to the paper and do a recount.
With a computerized system, if something goes wrong and the votes are recorded incorrectly in the database (either by accident or malevolently), there is a much greater risk that that data is just lost and it's impossible to reconstruct voter's original intent compared to a paper system.

TL;DR given the amount of value we place on free and fair elections, and the amount of effort we assume attackers might be going to to try and subvert them, our tolerance for risk here is very low. Paper has fewer things to go wrong, and is easier to go back to the source-of-truth and do a recount.